devopsy.kinsta.cloud

Tag: devops chat

DevOps Chat: Cognitive DevOps w/ Hayden Lindsey, Enterprise Systems and DevOps IBM

I recently had a chance to catch up with Hayden Lindsey, distinguished engineer and VP of Enterprise Systems and DevOps at IBM. I have spoken with Hayden several times as well as seeing him present at various conferences. Hayden truly understands how DevOps and related practices are changing the game for Enterprise Systems. Hayden and I caught up on Cognitive DevOps, as well as new developments in the enterprise systems.

His leadership of the Enterprise Systems team at IBM has really seen them make tremendous progress in keeping “big iron” relevant and up to date with the latest technologies. This includes acquisitions of new technologies which Hayden speaks to me about that are bringing next generation DevOps to market.

Have a listen to our conversation and if you like follow along with the transcript below.

Alan Shimel:                Hey, everyone. Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. This DevOps Chat we’re very happy to be joined by an old friend of devopsy.kinsta.cloud, Hayden Lindsey, VP and distinguished engineer for DevOps and enterprise systems at IBM. Hayden, welcome.

Hayden Lindsey:         Thanks a lot, Alan. Good to talk with you again.

Alan Shimel:                Always a pleasure, Hayden. Hayden, we’ll get right down to it. Lots going on in the world of DevOps, but also lots going on over at enterprise systems in IBM, so let’s jump in. First of all, Hayden, you know – I know, I don’t know if our audience knows, but they will now, you are relatively hands on in going out there and speaking to real live people and hearing what their challenges are in, you know, everything, not just DevOps, but this whole kind of digital reinvention, digital transformation that companies are undergoing. In a bigger picture, how is DevOps helping them with that, and then specifically, how are you and your team at IBM helping them with this?

Hayden Lindsey:         Yeah, so I do very much enjoy getting out from the lab. I mean, I like visiting the lab, love visiting the lab _____, but like getting out, meeting with clients. And so I do a good bit of travel around the world, meeting with them, either individually or at conferences, such as Edge, that we had in Vegas last week. And in general, I’m talking to them about how to modernize or transform, and of course, a lot of focus these days is on digital transformation. You know, just like some years ago, everything was about service orientation and so and all that.

Now, I think intellectually, most clients understand that they need to modernize, and of course, the ones I’m talking to are clients that have mainframes, but every single one of those clients have distributed systems and they have – most of them now have some form of mobile app, and of course, they’ve got web apps, so they have all different types of platforms. Now, they may all intellectually understand that they need to do a better job of leveraging the investments they’ve made in their back end systems over the years, and so that we’re talking to them now about is, you know, hybrid cloud topology, API management or the API economy, which is, you know, the latest and greatest way of exposing systems for use by applications on other platforms and the other technologies. And the way DevOps fits, that’s how you go about doing it. If you want to be modifying systems and you need to do it at a rapid pace and yet in a low risk, high quality manner, DevOps is the answer. And now getting people to – you know, getting them from intellectual understanding to action, sometimes that’s the challenge, so that’s why we get out and talk to them.

Alan Shimel:                Absolutely. So Hayden, big news, or at least in our world, and specifically in your division, was a couple of months ago, you guys announced an exciting acquisition. You want to share that with our audience?

Hayden Lindsey:         I would love to, yes. Took quite a while to get this announcement out the door, but on June 24th of this year, we announced acquisition of a company called Easy Source. They – and I’ve been aware of them for quite some time, been familiar with the former CEO and all that for quite some time. They have a very strong offering in the area of what we call application discovery and understanding. And basically what it does is it looks at source code, looks at schedulers, looks at JCL, looks at all different sources of information on mainframe systems, but also distributed systems, and then helps you do what if analysis, impact analysis. It helps you understand – the reason we talk about understanding, it helps you understand these very large and complex systems by visualizing linkages, control flow, data flow, many things like that.

So it’s a very, very powerful tool, supports IBM technologies, but many, many non-IBM technologies as well. So we view this as an essential first sort of step one, if you’re going to go about modernizing for purposes of a digital transformation or any other purpose, you need to understand what you have. And so we’re very excited to be able to offer this to our clients. And just by the way, it’s called Easy Source now, but as of October 4th, we will rebrand it IBM Application Discovery, and we’re combining that with some other solutions that we have around application delivery intelligence, or what we like to call Cognitive DevOps, to give a very comprehensive understanding and improvement offering.

Alan Shimel:                Got it. So that triggered something with me, Hayden. You know, last year at InterConnect, cognitive was such an overriding, overarching theme of InterConnect, so much so that, you know, you guys are kind of breaking out – I don’t know if it’s called Watson World or whatever, but a conference just dedicated to Watson and I guess things cognitive. And now we’re using the term Cognitive DevOps. Why don’t you share with our audience, if you don’t mind, a little bit about what you mean by Cognitive DevOps?

Hayden Lindsey:         Yeah, and in fact, from InterConnect last year, we introduced that term associated with a new offering that we had called IBM Application Delivery Intelligence, and I’ll explain in a minute what it’s about. But the more we started thinking about it, the more we realized DevOps is, of course, important, but how do you improve day after day, week after week, month after month, you know, after you have maybe automated all your tests, or you actually do have an automated delivery pipeline? How do you continue to improve? And that’s where we thought we would be able to look at different types of data that is owned by – owned or created by various tools in the overall development and delivery life cycle. And by combining these different sources of information, we believe, and I’ll give you an example, but we believe we can actually make recommendations to our clients about how to be much more efficient in what they’re doing to reduce risk, to improve quality, to improve productivity.

So our MVP, and it really is an MVP, we’re trying to take that concept seriously, was focusing on testing, because in the mainframe space, but also in a lot of other spaces, there is still a lot of manual testing that goes on. And so that’s obviously – the DevOps parlance, that’s waste and that’s error prone, because it’s being done by humans and they’re gonna make mistakes and it’s slow. And so we combined the information around test coverage, code coverage, tied to test cases, and then mapped that to change sets that we can observe that you change, you know, these three lines of code from when you open it in the editor and from when you save it and check it back in to a source code management system. And then we can tell you of, let’s just say, 10,000 test cases, that you only need to run 12 of them. And, you know, this would save time if the tests were automated, but it saves phenomenal amount of time if you’re doing this manually. So that’s one example of the type of insight, you know, pulling information from a variety of sources, to help people do DevOps better. And so therefore, I claim that equals cognitive.

Alan Shimel:                Absolutely. So Hayden, you kind of opened a little bit of a genie’s bottle with MVP. You know, one of the – I guess one of the issues, and you probably know this from running around and speaking to them, is this whole how do you get customers comfortable, right? Especially big companies that are doing, you know, once a year updates to their app, and say, hey, guess what, guys? We’re gonna do an MVP release, you know, weekly, or even monthly to start with. You know, how do you – I mean, that’s – you want to talk about a shock to the system. How are you getting – and especially we’re talking enterprise systems with mainframes and Z systems and so forth. How do you get them comfortable around that?

Hayden Lindsey:         It takes time. [Laughs]

Alan Shimel:                Has to be more than time, more than time, right?

Hayden Lindsey:         What you need to do is you need to get small wins, and you need to gain confidence by getting small wins and progressing – if you think about what it takes to get a truly integrated, continuous integration, continuous delivery pipeline, it takes many, many, many different efforts. You have to do test automation, you need to do deployment and configuration automation, you need to have powerful tools, maybe for test case generation, on and on. There’s many things to do. You can’t do it all at once.

So what we do is we actually offer DevOps assessments for our clients, to go in, talk to their SMEs, figure out where the low hanging fruit is, where are their biggest pain points, and then put together a roadmap to say, all right, we recommend you start here, and don’t – and start with something where there’s gonna be real value if they’re successful. But also, don’t try to get them changing six or eight things in their overall development life cycle at once, because in all likelihood, you change that many things at the same time, you’re gonna fail. So it’s about getting small wins, to help them become comfortable that what people are saying in the DevOps community, what we’re recommending to them, can actually be done even if they’ve been doing things a different way for the last 30 years, because that is, in fact, the reality. I like to tell people my biggest competitor, not to slam any other folks out there, but my biggest competitor is inertia. People are comfortable doing things the way they’ve been doing them, and we have to come up with an argument about why it really makes a lot of sense to change.

Alan Shimel:                And you know what, Hayden, unfortunately, it’s almost a law of physics. The bigger the organization, the more the inertia.

Hayden Lindsey:         Absolutely.

Alan Shimel:                And the more it takes to push it down. And, you know, in doing that, I do think you’re right, it is small wins, it is little things, building up momentum, breaking down these silos, if you will, between DevOps and even QA and security and a bunch of other stuff.

Hayden Lindsey:         Another thing, Alan, that I’ll just say is that, you know, it’s not just a vendor, like IBM or any other vendors out there saying it. There are many clients, and you hear these folks talk, for example, at Gene Kim’s DevOps enterprise summit, which is coming up here in San Francisco in a few weeks or a month or so. The stories are amazing, and so the DevOps success stories are not by any means limited to the born on the web companies. There are many, many enterprise companies, like Nationwide, like Fidelity Investments, many others that embraced this, even before we were using the term DevOps.

And they’re very, very mature, but they are – they’re leading the way. But if you are in the insurance industry and you’re not at the forefront, and you say, oh, Nationwide is doing that? Maybe I better pay attention. So it’s good to have some role model companies out there that are also willing to share their story, so I think that’s great.

Alan Shimel:                Absolutely. You know, speaking of share your story, I just wanted to mention, Hayden, as long as we have you on, that coming up on October 25th, later this month, we’re gonna have a great webinar with our friends at IBM, on breaking down the barriers or the silos between Dev and Ops. And I don’t know if you want to talk about a little bit, but – our friend Rosalind, and –

Hayden Lindsey:         Rosalind, Rosalind is one of our distinguished engineer, and she and I have been working together for a number of years now. She and Dave Willoughby, who is from the cloud architecture and emerging technologies area, are gonna talk about this – you know, how – the types of things that you can do and we need to be doing. Instead of just using this term DevOps and thinking it’s, you know, more about automating that handoff from DevOps, but what about the Ops back to Dev, and how can we more effectively utilize systems management and monitoring information to then provide – so this is just another example, providing improved insight back to the development community, so that they can do things better.

And it turns out this is actually an area that we are actively working on for that application discovery intelligence offering that I mentioned previously. You know, there is a wealth of information in the what you think of as the system administrator’s realm or the ops realm, that could be combined with development information to get some really interesting insight. So this is what we’re exploring. It’s also an area where we’re trying to find sponsor users in the client community to help us. You know, let them tell us, okay, I wish I could know or get some insight about this area, and then that can get us thinking about what type of data we would need in order to provide those types of recommendations. But so Rosalind and Dave will discuss some of their thinking around that area.

Alan Shimel:                Got it. Lastly, you know what, Hayden, we’re probably way over time, I’m just gonna ask you one more question, if it’s okay. And that is we were talking, you know, offline before we got on about both of our schedules, spending way too much time on the road. What events are on your plate coming up, that people might catch you at or might be of interest?

Hayden Lindsey:         Well, one that I have been to, and I spoke at the inaugural one, was this one I mentioned just a moment ago, Gene Kim’s DevOps summit. It’s here in San Francisco, which is where I live now, and so it’s extraordinarily convenient. [Laughs] And so that’s November 7th through the 9th, and I think it’s just amazing the stories that you hear there, so I intend to be there for the three days. And then I’m sure there will be others that will come up, but our big annual one is InterConnect, which this year, instead of being in February, is gonna be March 19th through the 23rd, yet again in Vegas. And there may be many more, but those are the two that are on the calendar at the moment.

Alan Shimel:                Got it. I’m looking forward to it. I’m looking forward to both of those. I will be, of course, at Gene Kim’s event filming again and doing interviews, and we’re making some big plans for InterConnect this year, Hayden. I can’t announce them right now, but it’s gonna be a lot of fun. Anyway, Hayden, we’ve gone way over time, I apologize, but I want to thank you for joining us today on DevOps Chat. Continued success with the enterprise and DevOps team, or the DevOps and Enterprise team at IBM, and let’s have you on again soon and let’s catch up.

Hayden Lindsey:         Sounds good, Alan. Take care, now.

Alan Shimel:                Always a pleasure. Hayden Lindsey, VP and distinguished engineer, IBM DevOps Enterprise Systems. Thanks for being this episode’s guest on the DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud, and see you again on our next DevOps Chat.

— Alan Shimel

October 18, 2016
DevOps Chat: Steve Hazel, Sauce Labs

I recently had the chance to sit down and speak with Steve Hazel, CTO and co-founder of Sauce Labs. With so much being written and talked about the role of quality assurance (QA) and testing in a continuous integration/continuous delivery (CI/CD) world, it is good to hear from someone like Steve who is an actual thought leader in the space. Steve tells us what he thinks the limits of automated testing are, the future of QA and more. Have a listen for yourself to find out, or follow along with the printed transcript below!

Alan Shimel: Hi, everyone. Alan Shimel, devopsy.kinsta.cloud here, for another DevOps Chat. Today’s DevOps Chat’s guest—that was a tough one—is Steven Hazel, co-founder, CTO at Sauce Labs. Steven, welcome to DevOps chat.

Steve Hazel: Hi, Alan. Glad to be here.

Shimel: Thank you. Glad to have you here, actually. So Steven, there might be some people listening who maybe aren’t familiar with Sauce Labs. So, before we start, why don’t we, if you don’t mind, give our listeners a quick overview? Tell us about Sauce Labs.

Hazel: Yes. At Sauce Labs, we do automated testing for both web and mobile apps. We run a cloud service that gives our customers access to a wide range of platforms, whether that’s operating systems and browsers for web testing, or mobile devices and emulators and simulators for mobile testing. You can get access to all the different platforms you need to test on, and you can get access to a lot of platforms at once to run your tests in parallel to get through a large test suite rapidly, which is really what people need for today’s continuous integration and continuous delivery workflows.

Shimel: Got it. Of course, Steven, Sauce Labs was closely linked with around Selenium and some of the open-source testing tools that are out there today, right?

Hazel: That’s right. Selenium is the dominant web-testing technology. In mobile testing, there’s a variety of technologies, but we support Appium, which also uses the web driver protocol that underlies Selenium. We really think that fitting in with those open-source tools is the smart way to go. It fits with what people are doing.

It gives people a lot of choices about how they want to do their testing, what kind of languages and frameworks they want to use on their end. So, we just plug right into Selenium tests, if you’ve already got Selenium tests, or Appium tests. You can just change the config and point them at Sauce Labs, and they’ll run unmodified on our systems.

Shimel: Got it. Steven, we were talking before we started recording today, I was telling you about a recent article we had over on devopsy.kinsta.cloud. The gist of it was basically that DevOps was the death knell for QA. I told you I didn’t agree with that and you agreed with me. You said you didn’t agree with it, either. But for our audience—they’ll respect you a lot more than they respect me—why don’t you agree with that, Steven?

Hazel: Yeah. I think that to suggest that there’s no longer a role for manual QA when you take on a DevOps process is just not in line with the facts. If you look at what we see large organizations doing, they’re not dropping manual QA for automation. They’re changing the mixture of what they have manual testers doing by quite a lot, but they still have manual testing teams. You still need a manual testing team.

So, what I see happening, as you start to take on automation, your testing coverage improves dramatically because you can afford to do a lot more testing when you’re automating than was ever possible with a manual testing team. But automated testing, the classic example is exploratory testing. You’re just not gonna get the kind of creative, exploratory walk-through of your app with an automated test that a manual tester can do. I think there’s still a role for QA organizations, beyond just manual testing, in being the other side of the conversation, right?

A lot of people have the concern that if developers are writing tests, it’s the inmates running the asylum. The exact developers writing the software are the ones deciding whether it’s high quality, and you want another perspective in there. You want a perspective that’s maybe closer to your end user. So, I think that the other side, beyond just manual testing, that you see with QA teams continuing to have a role is in deciding what cases should be tested, whether you have good test coverage, encouraging good testing practices, even when you are automating your tests.

Shimel: Absolutely. Really, Steven, I guess the boogeyman in the room around the friction with DevOps and QA is automation. There’s some schools of thought that says, “Well, we can automate everything. The more we automate, the better we are.” There’s another school of thought that says, “Well, you can automate as much as you can and automation’s not a bad thing, but there are just gonna be some things that are not automatable, if that’s a word now, or may never be automated. Where do you go in on that continuum?

Hazel: Well, being someone who’s pushing forward automated testing, I want to see automation go as far as we possibly can. I think that that’s very far. That said, I think that the way the mixture of tests changes as you adopt automation is maybe a little bit counterintuitive. You might imagine, well, we’ll automate some percentage of our manual test cases, maybe 80 percent or 90 percent. Maybe we could get to 100 percent if you’re a zealot for automation.

But actually, what you see is, it’s not that you’re automating a percentage of what was there in manual testing. You’ll actually have more automated test cases than you were able to do with manual testing. So, if you just looked at the number of test cases, your automated cases are gonna way outnumber the original count of manual test cases just because you can, right? You can now cover a lot more edge cases, a lot more scenarios because of the power of test automation. So, that’s a real advantage to test automation.

Shimel: Sure.

Hazel: At the same time, certainly there are things, visual testing, there’s some interesting approaches out there, but I don’t think we’ve yet seen a way of making sure that the app looks right, especially as it changes. You really need a human being involved when there are deliberate visual changes to make sure that they came out right. I think it’s those things where automation really can’t give you an answer about, does it look right? Does it act in a way that’s gonna be acceptable to somebody?

I think you still need a human being in there at some point, checking those things, but it’s a different process. It’s no longer this phase gate before every change is released that you used to have. It’s now a process that can be made asynchronous from the bulk of your development and release process.

Shimel: Absolutely. If you don’t mind, Steven, a little bit of time on, you mentioned a little bit, but what do you think of the kinds of tests that lend themselves well to automation? Certainly, a visual test of an interface, different arts. What are the sweet spots for automated testing?

Hazel: I think certainly at the bottom of the testing pyramid, unit testing brings tremendous value. It’s something that’s very easy to automate in a way that’s completely deterministic, very fast. Gives you really quick feedback as a developer as you’re making changes to the code on whether you’ve broken something. But the coverage with unit testing, the coverage of functionality that may be important to your end users, it’s really hard to achieve. It’s really hard to achieve good, solid feedback from your unit tests that you haven’t broken anything anywhere.

Functional testing, the next layer up, which is what really we focus on, gives you that complete end-to-end check. You’re actually testing the features of your product and you’re making sure that end to end, with all the various components involved, they work properly. That’s more of a challenge for automation, but we’re seeing, I think, a majority of development organizations out there seeing success automating functional tests and real value from having that be something where you can run through hundreds of test cases in minutes and get feedback to your team. So, that works quite well for automation.

I think it’s that next level up, as you start to get into the types of tests where you’re looking at, what’s an acceptable experience for the end user? User acceptance testing as distinguished from functional testing, where you’re really starting to look for, does it look right? Does it act right? Is the response time throughout the entire process acceptable?

You can zoom in and measure a lot of these things very specifically, but getting the answer to, “Overall, though, was it a good experience?” That’s the kind of thing where it’s really tough to cover that with automation.

Shimel: Yeah, agreed. Steven, if you don’t mind, I’m an old security guy prior to DevOps. One of the things within the security community that we’ve really pushed around is the idea of automated security testing shifting left in a DevOps environment and allowing security testing to be done in an automated fashion at a CI/CD-type of level. Where do you see that in this whole discussion?

Hazel: Security testing isn’t what we focus on at Sauce Labs, so –

Shimel: Right, I know.

Hazel: I’m not an expert in this, but it is something that I follow and care a lot about. I think I see a lot going on with static analysis, with some of these tools that can help to constrain the types of mistakes that you could have in a program, type systems and things along those lines. I think really that’s very badly needed in making code secure. Some of the issues we’ve seen come up over the last few years, things like Heartbleed, the Glibc bug, really those kinds of things aren’t acceptable, aren’t something that we can continue to have happen, and I think the solution really is fully automated tools, like static analysis tools and type systems, that can lock down the code and just constrain the types of mistakes that could possibly happen.

Shimel: Sure. You know, Steven, I see it as very analogous to the QA situation, which is I think a lot of security people get very territorial around job security because they’re afraid somehow that doing automated security testing earlier in the process—shifting left, so to speak—is somehow gonna affect their livelihoods, or make them obsolete.

Hazel: I can see that. We see that among QA folks, for sure. To me, that’s a shortsighted view. If the world is getting more intense security problems, more intense quality problems, we’re shipping more software, you just can’t solve it 100 percent by throwing bodies at the problem. I think that what’s gonna happen is not that those people’s careers are in jeopardy; instead, as a society, we’re just gonna do more and better security and quality testing than we’ve been able to do in the past.

Shimel: Yeah, agreed. Steven, we’re running a little low on time, so let me get just one or two more questions. Sauce Labs has been, in my opinion anyway, for what it’s worth, somewhat of a DevOps darling in terms of really encompassing—you’re living the DevOps model. You’re working with open-source tools, testing and automation, enabling automation. Sauce Labs is a player in the DevOps ecosystem. Where do you see it going?

Hazel: Well, toward the enterprise is one big trend we’re seeing. Earlier on in the history of Sauce Labs, a lot of our customers were essentially software companies, companies that their primary focus is technology. Now, a lot of our customers are retailers, financial institutions—companies that you don’t think of as primarily a software company, but all of these companies have apps, they have complex web experiences. They’re really adopting DevOps in a big way. They’re moving to what is, for them, a very different process than what they’ve been doing and allows them to ship better software faster, with more complexity than they were able to handle before.

Shimel: Absolutely. Steven, we are low on time. I’m gonna ask you the final question, which I ask most all of my guests here on DevOps Chats. That is, if you had to recommend one book to our audience that they should read, a must-read for them, over the next six months or a year, what would that book be?

Hazel: Oh, wow. A book recommendation. I think the obvious choice in a conversation about DevOps is “The Phoenix Project.” If you haven’t read it, you’ve got to read it. It’s a quick, enjoyable read, but it really gets the concept across better than probably anything else is going to. It’s an obvious recommendation, but I still think it’s worth it.

Shimel: Sometimes the obvious is good. I will just add to that, if you already have read “The Phoenix Project,” Gene Kim’s next book, I think co-written with John Willis and Jez Humble and someone else that I’m blanking on – oh, darn it, the guy who started DevOps, who coined the phrase. Patrick. Patrick Debois. Their new book, I think it’s called “The DevOps Handbook,” will be out, I want to say, in the fall. Not a sequel to “The Phoenix Project,” but another good book to look at.

Anyway, Steven Hazel, CTO, co-founder of Sauce Labs, thanks for being this episode’s guest on DevOps Chat, and continued success with Sauce Labs.

Hazel: Thanks a bunch. Thanks for having me.

July 25, 2016
DevOps Chat: GitHub Enterprise as a Hosted Service, with Jean-Louis Vignaud

I recently sat down with Jean-Louis Vignaud, program manager at IBM, about the new GitHub Enterprise as a hosted service that recently was rolled out on Bluemix. The GitHub Enterprise as a hosted service is a great option for enterprises that, due to compliance or other security requirements, cannot used a shared, public GitHub service.

This GitHub Enterprise as a hosted service is the first of its type available and is hosted on the Bluemix service as both on-premises and hybrid environments. You can get more info on this at:

1. Blog : Introducing the first-ever GitHub Enterprise as a hosted service

2. Video : Benefits of GitHub Enterprise with IBM Bluemix Dedicated

3. SlideShare: IBM Bluemix Dedicated – GitHub Enterprise

Also, we will have a webinar that goes into greater detail on this. More info is at: http://webinars.devopsy.kinsta.cloud/scaling-devops-github/

In the meantime, here is the streaming audio file of this chat, followed below by the transcript of our conversation to follow along.

Alan Shimel: Hi, this is Alan Shimel, devopsy.kinsta.cloud, and I’m here with another DevOps Chat. Today’s guest on DevOps Chat is Jean-Louis Vignaud, Program Manager from IBM. Jean-Louis, I hope I didn’t mess up that name too bad.

Jean-Louis Vignaud: No, that’s fine. Thank you, Alan.

Shimel: Okay. Welcome to DevOps Chat, Jean-Louis, and as I mentioned, you are a Program Manager at IBM, and right now anyway, you’re very involved in working on the GitHub Enterprise as a hosted service offering, and we wanted to talk to you specifically about that.

Vignaud: Okay.

Shimel: So, Jean-Louis, I think everyone listening out here is familiar with Git and GitHub, but they may not be familiar with the concept of GitHub Enterprise as a service, so why don’t we start there, if you can explain to our audience a little bit about what that is.

Vignaud: Okay, so maybe we can start with GitHub first.

Shimel: Okay.

Vignaud: GitHub is very well-known, it has probably 15,000,000 users as of today, it’s a very well-known user experience. It’s a collaboration platform, and it’s based on Git, so it’s running on top of Git, but it has many other services on top of Git. And the purpose of GitHub is to provide this collaboration platform that enables people from all around the world to collaborate on a business project, or even a private project.

And that very well-known collaboration platform is very attractive for enterprises that want to provide the same level of collaboration within their own organization. And so what was introduced by GitHub the end of 2011, early 2012 was GitHub Enterprise. GitHub Enterprise is an on-premises version of GitHub. So, same set of capabilities, but you can install it when it’s on-premises in your—on-premises in your environment, and get it working within your firewall. So that enables teams to—you know, to enable organizations and different teams to collaborate among each other in a safe way.

So that’s the background, and where we were standing before we introduced our offering.

Shimel: Mm-hmm, and [Cross talk]—I’m sorry. I didn’t mean to interrupt.

Vignaud: Yeah, so what I was going to say is that, as usual, inside an organization, as soon as you have to install your product, you have to run it, you have to manage it, you have to provision your infrastructure, you have to have the people set up and standing to manage the GitHub Enterprise offering, meaning doing the backup, doing the upgrade, monitoring its running and doing everything that needs to be done in order to comply with the enterprise security requirements.

And that requires time, and most of an inside organization, you know, people are looking to move to the cloud, benefit of the cloud facilities, which they could find in GitHub today, but it’s a public cloud that does not meet the security requirements of an organization, and they would want the same GitHub experience, but within their organization. And this is where we come with our service offering around GitHub Enterprise—providing the user experience of GitHub within the organization while still managed by IBM.

Shimel: Got it. And just to make clear, Jean-Louis, as far as I know, IBM is the only one actually offering this GitHub Enterprise as a hosted service, correct?

Vignaud: Yes, this is a first-of-its-kind offering. I know if you look into what GitHub provides, GitHub provides GitHub Enterprise so you can run it on premise. You also can install it on infrastructure as a service, so you can run it inside AWS, you can run it inside Azure, but there was no one providing a service offering around GitHub Enterprise. So, with IBM, it’s hosted and managed by IBM so the “and managed” is unique.

Shimel: Got it. And another thing I just want to emphasize, because as we were speaking about before we started today’s broadcast was, you know, this is in partnership with Git, right?

Vignaud: Yes, that’s a partnership with GitHub, yes. We announced the partnership at InterConnect early this year in February, and so since the announcement, we have been working and creating this offering. So it took us 12 months to build it and to release it.

Shimel: Understood. And I think that’s important, because you know, it’s one thing to just take some open-source project and offer it as a hosted service, right? Anyone could do that, it’s open source.

Vignaud: Yes.

Shimel: But to really have the cooperation with Git behind this really gives, I think, the best chance for enterprises to have their own Git environment really, truly as a hosted service.

Jean-Louis, I wanted to talk about another aspect of this offering, and that is, as it’s part of an Integrated Bluemix Dedicated offering as well, right?

Vignaud: Yes.

Shimel: So let’s start off with, what is Bluemix Dedicated?

Vignaud: Okay, so IBM platform-as-a-service offering is Bluemix. So, Bluemix, it consists of a huge set of services, for mobile application, for cognitive applications, so about more than 150 APIs organizations can use to build a cloud-native application, to integrate these applications with a back-end system. And so Bluemix is available in the public cloud, but as well, it’s available as a single-tenant dedicated cloud for the customer.

So that’s Bluemix Dedicated. So, meaning, it’s a Bluemix for our customer with all this API, all these platforms that enable you to build and run your application. It’s based on Cloud Foundry, it supports containers, Dockers and so on. So it provides a very extensive set of technology that enables organizations to quickly build applications.

As part of Bluemix, there are a set of DevOps services, so tools we provide to help organizations build those Bluemix applications. And this is where our GitHub Enterprise offering sits. It’s a DevOps offering, part of Bluemix Dedicated.

Shimel: Got it. So, Jean-Louis, this is—I mean, unfortunately, we only have 12 to 15 minutes here, but there’s a lot of layers that we can peel back it of what one can do with this GitHub Enterprise offering, you know? And especially, in my mind—look, if you’re developing applications and you just want to have your whole platform as a service with best-of-breed stuff such as a Git, such as a Cloud Foundry, all of these elements that give you a best-of-breed application development in platform as a service forum, it seems that all the pieces are here to come together. And it’s a great time to be alive. It’s a great time to have to—you know, if you wanna develop applications, to have that at your fingertips.

Vignaud: Yes, and in the context of Bluemix Dedicated, single-tenant, completely integrated with your enterprise network, so it enables you to safely integrate with your back-end system. So you really have a very advanced platform enabling you to develop in a safe way; you know, very innovative applications.

Shimel: Yeah. So, Jean-Louis, two questions for you. No. 1, in terms of advantages of using the GitHub Enterprise hosted versus the public Git, that GitHub that so many of us, I think 50 million is the number of people use—the obvious advantage is, this is a more secure environment, it’s yours only. But are there any downsides? Is there any kind of features not available in the hosted service that would be available in the public service?

Vignaud: No, not really. You know, the GitHub Enterprise has been designed to provide the same user experience as GitHub. I would say that the value of GitHub Enterprise, it’s the user experience of GitHub, but you can run it for you, so it’s a single-tenant for you as a customer, leveraging the cloud infrastructure from IBM, you can run it in a data center where you want to, geographically you can localize it in the country where you belong. So if you have compliance requirements requiring you to host your source code in-country, you can do that.

So, I would say, no limitation and much more flexibility when it comes to the deployment of the offering.

Shimel: Excellent. Next question, I just wanna make sure—is this publicly available today? Because I remember—

Vignaud: It is, yes. It is available today. We announced it on the 17th of June. We officially announced it on the 17th of June, so yes, it is available today, and any Bluemix Dedicated customers can use it as part of the offering.

Shimel: Oh, excellent. And I should also mention, Jean-Louis, that in the near future, actually—I think we’re finalizing scheduling right now—we’re actually gonna do a full webinar with GitHub and IBM, where we’re gonna explore a little deeper into this offering and for those of you listening who may be interested, I strongly, strongly encourage you to attend that webinar.

But Jean-Louis, if people don’t want to wait for the webinar, I know IBM has put up several content pieces where people can get more information from this. One is a blog introducing the GitHub Enterprises service, there’s a video that shows the benefits, and I think there’s also something up on SlideShare about IBM Bluemix Dedicated and GitHub Enterprise. I will try to—

Vignaud: Yes.

Shimel: — yes, I will try to include the links to those when we publish this chat, but again, I strongly—if you have questions about his, if you’re a Git user and thinking you’d like your own GitHub Enterprise dedicated service, I’ll try to put those in there.

You know what, Jean-Louis, unfortunately we’re just about out of time. Is there anything you want to add?

Vignaud: I think this is fine. Thank you very much, Alan, for the interview here.

Shimel: Thank you.

Vignaud: I really look forward to have many customers for this offering.

Shimel: You know, I think it’s something the market needs. It’s good to have that. As I said, it’s a great time to be a developer today, right? So many tools, so easy to use.

Vignaud: Yes.

Shimel: Anyway, Jean-Louis Vignaud, Program Manager at IBM, thanks so much for joining us today, and we look forward to hearing more about GitHub Enterprise as a service.

This is Alan for devopsy.kinsta.cloud. Thank you for listening in, and we’ll see you on the next DevOps Chat.

Vignaud: Thank you.

July 21, 2016
DevOps Chat: Rosalind Radcliffe, Mobile to Mainframe DevOps for Dummies

I recently had a chance to sit down with IBM Distinguished Engineer Rosalind Radcliffe about her new book, Mobile to Mainframe DevOps for Dummies. The book is actually quite a bit deeper than your usual “for Dummies” book and an excellent read. Of course you would expect as much coming from Rosalind who has quite a list of well deserved accomplishments and accolades on her CV.

Saleem Padani of IBM has a good post up on LinkedIn announcing the book as well that you may want to check out.

FYI, we will be doing more DevOps Chats in the future. If you would like to be a guest on a future episode please contact editor@devops.com

Above is an embedded audio player to listen to the interview of Rosalind. Below that is the transcript if you would like to follow along or just skip the audio and read the interview. You can download the free e-book copy now by visiting https://ibm.biz/m2mdevops

Audio Transcript

Alan: Hi, everyone, this is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud, and we’re kicking off a new feature here at devopsy.kinsta.cloud—DevOps Chats. Each episode will feature me speaking with a thought leader around a particular topic of devops.

Kicking off our series today with a very special guest, Rosalind Radcliffe of IBM, and we’re gonna be talking to Rosalind about a new book which she has just offered called Mobile to Mainframe: DevOps for Dummies. Rosalind, welcome to devopsy.kinsta.cloud.

Rosalind: Thank you.

Alan: Okay, let me briefly give our listeners a little background on Rosalind, and Rosalind, I don’t mean to embarrass you, but you have quite a résumé. Rosalind is a Distinguished Engineer in IBM. She’s Chief Architect for CLM and DevOps, and she is responsible now for driving devops for multi-platform architecture. This includes System z and Power Systems. In addition, she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions, and this includes both UrbanCode Deploy and Rational Team Concert’s support for standard mainframe development activities.

Beyond that, Rosalind is a member of the IBM Academy of Technology and a master inventor. Prior to her current development related responsibilities, she has been responsible for IBM’s SOA Management Strategy and Services, responsible for deploying Systems Management solutions, and she started with ISPF development.

Rosalind, I hope I didn’t embarrass you too much, but once again, welcome to devopsy.kinsta.cloud, and congratulations on this great new addition to the DevOps for Dummies series, Mobile to Mainframe DevOps for Dummies.

Let’s start today’s chat, if you can share with our audience a bit more about you and where you are in your career.

Rosalind: Thank you, and I’m looking forward to this chat. So, a little history on why I wanted to write the DevOps for Dummies book. I started in IBM 28 years ago in ISPF development, as you mentioned, and I’ve been in different roles and different responsibilities along the way, including spending a good amount of time in the Systems Management organization, responsible for actually doing operations like tasks and deploying our Systems Management solutions for clients.

I’ve also spent a number of years in the application development space, providing and building application development tools. And so, as this developed over the years, working in operations, I used to blame development, and then when I moved to development, it was, “Oh, I guess I can’t blame operations.” So it’s deemed appropriate that I would move into this devops space of trying to bring these teams together.

In looking out at the industry today, I see that there are lots of questions, especially in the mainframe space, about, “How does this devops really apply to that environment, and with all the drive for mobile and mainframe together, how do we really make this play as an environment?” And so, that’s how I got here and why I wanted to write this wonderful book.

Alan: So, let’s dig in quickly to the book. You know, I think everyone in our audience is familiar with the “For Dummies”, if you will, franchise, and some of them can be rather fluffy, some are better than others, obviously, depending on authors and so forth. My initial reaction when I read it, Mobile to Mainframe DevOps for Dummies was, “Wow, that’s a pretty heavy topic for a For Dummies book.” Why write this book in the first place and why now?

Rosalind: Well, I think now is a perfect time, with the industry evolving, with the mobile frontier and everybody focusing on mobile, and with mainframes truly being our systems of record. So, everybody needs to connect mobile to mainframe, and if we look at the development environment, most mainframe development shops look remarkably like they did when I started 28 years ago, and that’s not necessarily a good thing.

So what I wanted to do was help explain to executives, senior leaders, and anyone in the industry, how mobile and mainframe play together and, in using the devops transformation helping them work together, they can get more value out of the systems that they currently have.

Alan: Absolutely. And just so we can mention, of course, Rosalind, the book is available for download, we’ll have links on it up on devopsy.kinsta.cloud. But, as I mentioned, it’s not a fluffy book—there’s a lot of great content here. I can tell how much time and effort you put into this thing.

But, give our audience a sense—how much, how big an effort was it for you?

Rosalind: It was a significant amount of time in writing. I spent a lot of time on plane flights back and forth to Europe, and that gives you a lot of time when you can’t do anything else, and so I spent a significant amount of that time writing. It’s a relatively short book, it’s only 70-something pages, so it’s not as long as a very long book, but it did give me the opportunity to hopefully give some background, explain more about the current environment, and give people an insight as to what I’ve been seeing with clients and help them move forward.

After you write it, then you have to edit it, and I have to thank the many people that helped me work on this and help provide contributions and pieces of the document, because they helped me put this together, and helped me do a lot of editing as well to make sure that it was complete in the environment.

Alan: Sure. I mean, I’ve been lucky enough to have a chance to see a pre-publication version of it, and I do think—you’re right, it is only 70-some odd pages, but it’s pretty in depth. But it really benefits from the sort of, the For Dummies kind of franchise—you know, the icons they use to help you focus in on what’s really important and giving you Cliffs’ Notes version if you wanted to not read every word. You used the format very well, and I think people will get a lot out of the book.

Let’s dive in a little bit, though, into some of the key points that you’ve brought up in the book. You know, just picking some random ones that I thought were important—in chapter 3, for instance, you speak about why we need to understand why devops is so critical for mainframe environments. And we need to start with the dev side.

But devops is about breaking down silos, it is about cross functions—and nowhere, in my mind anyway, nowhere are these silos more separated than between the mainframe teams, like you said, haven’t changed sometimes in 28 years when you started, and the distributor mobile development teams, who are today all about cloud and virtualization and instant up and instant down.

Can you elaborate a little bit more on this point for our audience?

Rosalind: Yeah, I’ll be happy to. This is one of the key points as to why devops matters more than ever now in the mainframe space—this transition to mobile, this transition to systems of engagement and their dynamic changes, their need for speed, and the need to access these back end systems of record. So now is the time for us to evolve the environment, the mainframe development environment, to modern technologies and modern tools to allow these teams to actually work together.

There is absolutely no reason that mainframe environments need to do development the same old way. They don’t need to be done using waterfall development practices. There’s no reason not to apply the same agile and lean IT practices across the development organization from mobile to mainframe, and using the same tools and the same capabilities so these teams can work together, they can share information, they know what each other’s doing, and you can break down those silos.

One other reason those silos are there is, you know, if your mainframe development team is using ISPF, I’m not sure those mobile guys using X code even want to look at a green screen. So this has to change. The perfect time—bring these teams together, use modern development practices, use modern tools, and this allows the silos to be broken down, allows the teams to work more efficiently together, and helps deal with this variable speed IT issue that we have. Mobile needs to move fast. Those systems of engagement need to be moving.

But the back end systems of record need to be able to define standard APIs. They need to provide those services that the front end needs, and they need to do it fast enough—so they need to do it at the speed of business, and devops helps them do that.

Alan: Excellent. And so, Rosalind, you actually touched on something here, and it’s this variable speed IT—variable speed devops, I’ve heard some analysts call it a bimodal IT—and it, I mean, you nailed it right on the head. These mobile development teams that are running at the speed of today’s business, tearing it up, putting it up, tearing it down, putting it back up—changing, changing, changing thousands of hundreds of times a day, even, in some cases.

We can’t expect the mainframe systems of record to perhaps move at that pace, but there’s no reason they can’t move faster, especially using modern tools, modern development environments, though I still find something comforting about a green screen. [Laughter]

But, that being said, you know, this was the subject of a whole series of webinars we did here on devopsy.kinsta.cloud on variable speed IT and variable speed DevOps. Can you help our audience understand why it’s so critical for mainframe environments to embrace devops and why now, more than ever, now is the time?

Rosalind: Yes, so with this variable speed IT, and as we talk about it, it’s not that the back end is slower because mainframe development is slower, it’s that, in variable speed IT, you need to move at the speed of business, and if you define services as your back end systems of record, those don’t need to move as fast.

What we need is to define those as services so the front end system can use them, so these systems of engagement can call back into the function. So the need to define these services based on the existing legacy code means development teams need to be able to respond at the speed of business. They need to be able to move faster. And the old ways of doing things—you know, making a change and testing it for three months—just isn’t gonna work. We need to apply the principles of automation, automated testing, virtual services, and interface testing, and bring all of those concepts to allow you to build those services based on the existing business function into the environment so that they can then be called by the systems of engagement.

Companies have significant assets sitting on the mainframe systems. Mainframes aren’t going away. They’re gonna be here forever. They provide the qualities of service needed for large scale transaction performance systems. And so, with mobile, large scale transaction performance systems—that’s perfect. Mobile backed with mainframe is a perfect environment. And companies with the assets that they’ve built up, if they can service-ify them fast enough, they can provide disruptive technology today.

And that’s what the companies need to do. They need to take advantage of the assets they have, providing services using the new development practices, and then it all fits together and they get the business value at the speed they need to. And you know, I helped build ISPF, so I do like that green screen, too—but it’s not really the right development platform for developers today.

Alan: Yeah. But what about—look, you know, people make fun of COBOL developers, but there’s still a lot of jobs out there for COBOL developers.

What about the shortage of experienced mainframe IT skills in the marketplace, Rosalind?

Rosalind: Yeah, so that’s one of the points I make in the book. Developers can write any language. You know, get a good developer, they can write COBOL—and there’s nothing wrong with COBOL. COBOL serves its purpose. PL/I serves its purpose. And some people will cringe as I say this—Assembler serves its purpose. But you know, I’m not gonna write it using ISPF.

If I’m a kid coming out of college and you give me a modern IDE that has all of the language syntax in it, it has code rules, it has the ability to build unit tests for me—I can write COBOL. Not a problem. It’s the—give me an ISPF screen, and I don’t even know how to use it, much less how to do COBOL.

Alan: Understood, understood. Let me—we’re running low on time, so let me turn to some other questions I had prepared, if it’s okay. In the book, you talked about some of the best practices—devops best practices on System z which, for our listeners who may not be IBM aware, System z is the IBM mainframe platform.

Rosalind: Correct.

Alan: And there are several good ones that you have highlighted in the book. Are there specific devops practices that you would recommend for System z to get started down the path of continuous delivery, which some people think is the ultimate aim of devops, or the ultimate goal?

Rosalind: Yeah, so there are a number of different practices, but a few call out based on the way many mainframe organizations are working today, and it has to do with where they are today. How do they improve the process from where they are to get into more continuous delivery practices?

And before someone says something, I’m gonna say—continuous delivery does not necessarily imply continuously delivering into production. It means continuous delivery into a pre-production, et cetera, environment. You may still need to stage those based on an outage window, especially for systems of record, because you can’t afford to have a transaction change mid-flight.

So there are some—you know, continuous delivery within reason. But if we think about those things, one of the key practice is modern development tools to break down the silos. And one of the others that is absolutely critical is automated testing. There is no way to get to continuous delivery without automating testing, and since you’re building services out of your back end systems, services are a perfect thing to use automated testing against.

So, building up automated testing based on the service interface, being able to test the function without having to have users go in and test the business function—just run a bunch of automated tasks and make sure you’re picking the right automated task based on the code that you’re changing, but automated testing is probably the biggest change that is needed for mainframe environments and, in many ways, the most valuable. We look at many shops and they’re spending months running lots and lots and lots of manual tests that they hope will find the problems.

Alan: Got it, got it. Rosalind, we only have time for maybe another question or two, but I have one very IBM specific one, one a little bit more general.

So recently, the new z13 launch really put the mainframe front and center as the core element for IT infrastructure. Is this the rebirth of the mainframe? How do we see this new mainframe fitting into this seemingly ever changing IT landscape? More importantly, what do existing mainframe clients do to prepare for this new age of mobile to mainframe?

Rosalind: So, the z13 has lots of additional capability and functions along with the updated compilers to increase the speed to allow you to provide more function faster, COBOL improvements using the new system hardware, Java improvements to be able to do more Java development on the mainframe, as well as significant memory availability changes.

So, with the combination of the system, you can look at it as the best Linux environment that you can use for your cloud environment, so you can have—use Linux on System z to provide your Linux environment for your front end applications, and then, looking at z/OS, you can start to take advantage of this new memory that’s available to increase and improve your performance from a caching standpoint, numerous other things from a performance standpoint with the new compilers, and the mobile connectivity into the system. If we think about the fact that that could drive huge numbers of transactions—could drive huge numbers of transactions—we get the mainframe as the perfect platform to handle that variable load.

So you never know—you know, I guess if you’re a retailer you know if it’s Thanksgiving or near Christmas it spikes, but many times, you don’t know where the spike’s gonna come, so it’s important to have that capacity on demand, to have that variability, and so the system plays very well.

I think there are a lot of clients and a lot of organizations that are taking a new look at the mainframe of the latest z13 because of its capability, because of its enhancements from a memory standpoint, and because they think—you know, reality. People are realizing the mainframe is not going anywhere, and it really is the best platform for those high transaction systems and allows you to consolidate things together in a Linux platform. So it’s a great advantage that customers were already using we they have, and it’s something other customers are looking at to do, “You know, I can take advantage of that as well.”

Alan: Okay. Rosalind, again—I’m sorry to keep saying this, but I’m trying to keep it short for our listeners, and relevant, but there’s just so much here. So you’re constantly out talking to clients that utilizing mainframes, and kind of living this devops and mobile to mainframe way of doing business—can you give me two or three quick examples of companies that are, that you think are doing it right?

Rosalind: So, if we look at the industry and we look at the publicly available references, Nationwide is one of them that’s been out talking and describing their devops transformation and how they’re exploiting the fact that they’ve brought their teams together to provide value faster in the environment. We can look at Fidelity, who’s talked about their improved deployment capability and their improvements overall in their environment. Or, one of the examples I like that Walmart and their example of using services on the mainframe to actually provide infrastructure services to all their distributed applications from a caching service.

And so there are numbers of good examples that talk externally, and then there are a whole bunch more examples who consider their transformation to devops a business advantage. They see that, by transforming to devops, they’re getting a leg up on their competition, and so they’re not as willing to let us use their names—but there are lots of wonderful examples of people who have transitioned and who are getting the value out of it, including IBM itself. We have numbers of examples that we provide to show our development process significantly improving and breaking down the silos within our own organizations and improving our ability to deliver.

Alan: Excellent. Rosalind, I think this was very helpful, as is the book—a great guide for, as you mentioned earlier, both executive managers and practitioners.

What about you, Rosalind? You’ve had such a successful and storied career—what’s next? What’s next for Rosalind?

Rosalind: Yeah, so the next thing next week, actually, I’ll share. So, next week, we have one of the major user conferences or the major user conference happening in Orlando. And, as part of SHARE, obviously, we talk about mainframes and development activity as well as lots of different topics, and I’m looking forward to that in particular, because we’re doing a series on mainframe and mobile. More specifically, we’re doing a discussion about hooking Bluemix, our development app platform as a service along with IBM devops services to the back ends, and helping show the relevance of Bluemix to mainframe environment through a series of sessions as well as showing System z as the new cloud disruptor, and there are numerous sessions by other clients like Walmart who will be speaking.

And so it’s a great opportunity for me to, first to hear stories from our clients as well as to provide some additional sessions for our clients and show what we’re doing, and it will be my first opportunity to have hard copies of this book and do a book signing for any of the client who are there.

Alan: That’s what I was gonna say—there’ll be plenty of copies of the book there available and signed by yourself.

Rosalind: Absolutely.

Alan: Great. Okay, we’re gonna—I think we’re gonna call it a wrap here, Rosalind, and thank you so much for your time. I know you’re busy and I appreciate it. Rosalind Radcliffe, author of Mobile to Mainframe DevOps for Dummies, available now for download or if you’re attending SHARE in Orlando next week, you can get an autographed copy. Rosalind, thank you so much for your gracious time and spending some time with us today. We hope to—you know, best of luck with the great book, highly recommended, and we hope to have you back here soon.

Rosalind: Thank you for having me, and I’m happy to come back and talk to your audience whenever is appropriate.

Alan: Okay. Rosalind Radcliffe, IBM, and author of Mobile to Mainframe DevOps for Dummies. This is Alan Shimel for devopsy.kinsta.cloud, and thank you for listening into this DevOps Chat, and join us again soon for another one. Have a great day.

That’s a wrap on this DevOps Chat. If you would like to be interviewed for a DevOps Chat please contact me at editor@devops.com

August 12, 2015