devopsy.kinsta.cloud

Category: Podcasts

DevOps Chat: Rosalind Radcliffe and Bimodal IT

I had the pleasure of sitting down with IBM distinguished engineer Rosalind Radcliffe the other day to talk about bimodal IT, systems of engagement, variable speed DevOps and IBM’s upcoming InterConnect 2016 event. I have interviewed Rosalind many times over the last few years and it is always informative and interesting. I hope you find it to be so as well.

Below is the SoundCloud streaming audio interview, followed by the transcript of our talk. Enjoy!

Alan Shimel:                Hi, Alan Shimel here with another DevOps Chats, and my guest is – for this session is a friend of mine, Rosalind Radcliffe of IBM. Rosalind, welcome.

Rosalind Radcliffe:      Thank you.

Alan Shimel:                Rosalind, I think you’ve appeared on DevOps Chats before, and of course we have done webinars and videos together, and so many other things. But for members of our audience who may not be familiar with who you are; do you want to give a brief background?

Rosalind Radcliffe:      Sure. So I’m Rosalind Radcliffe, I’m a Distinguished Engineer at IBM, and I’m responsible for our DevOps strategy for Enterprise Systems. So I am not only responsible for driving our product direction, but I really spend a lot of time with clients helping them with their DevOps transformations for their Enterprise Systems – mostly mainframe, and their systems of record.

Alan Shimel:                Excellent. Rosalind, of course, we’re going to talk a little bit about today about this term that’s been creeping up, Bimodal IT, and then I want to spend some time talking to you about the upcoming InterConnect Conference as well. Maybe we can combine Bimodal IT and InterConnect; I don’t what we would call that, but Trimodal. Anyway, so Rosalind in talking offline before we jumped on here I think we both agreed that we weren’t big fans of the term Bimodal IT, and all that seems to have entailed now. Do you want to share with our audience why you may not be a fan?

Rosalind Radcliffe:      Yeah. I think the term and the way it’s used isn’t implying that there is a defined slowness for the systems of record. I think it’s important instead of saying Bimodal to say more variable speed IT or something that implies that the systems may move at different speeds. I’m not going to disagree with that, but it’s not that one is inherently faster and one is inherently slower. It’s that hopefully for your system of record you’ve built that as a set of API’s or services, and so you don’t have to change the services as often as you need to change that system of engagement to entice the users to stay connected.

So it really should be about how the systems of record and the systems of engagement can work together through loose coupling, and through proper services. I do think that is going to happen; there are going to be different speeds at different times. Sometimes, honestly, the systems of record might be moving faster than the systems of engagement, because there are changes needed – regulation changes, etc. But it’s – we need to pay attention to it from that standpoint and that’s the reason why I don’t like Bimodal IT. It’s really variable speed.

Alan Shimel:                Yep. The other point that gets me with it is this whole idea of Bimodal IT, it almost takes that we have two tracks if you will, that move at different – or two trains on a track that move at very different speeds. But they never interact; it’s almost – it almost reminds me of civil rights, separate but equal. We have the water fountain for the mainframe guys, and a water fountain for the cloud dudes, and they both serve water so that’s okay. But the mainframe guys can’t drink from the cloud dude’s water fountain.

It didn’t work for civil rights, and – I don’t think it works for IT either. I think a better model when we talk about systems of record, systems of engagement, and this whole world, is more – I call it the Swiss watch model. Where you have gears that turn at different speeds, but they all mesh together in a fine tuned timepiece. To me, that’s a much better model than this idea of separate tracks, if you will. What do you think about that Rosalind?

Rosalind Radcliffe:      I actually think that’s a wonderful way of putting it. Because I think that – it would be a much better interpretation with the gears and the Swiss watch, and Swiss watch timing is always excellent with their gearing system; so that’s exactly what it is. The teams need to work together, and they need to be using the same tools, the same practices, the same processes, and each system needs to go at the speed that is required for the changes that they need to make. But they’re obviously interacting. Your systems of engagement is nothing without your systems of record. So they need to interface properly, they need to work together to provide this end-to-end solution for their end users.

So they have to be collaborating, and I – honestly I think the organizations that have brought the teams together, that do the systems of engagement and the systems of record into one team, actually do the best. They’re the most efficient; so they may have variable ability in the speed they’re delivering on different parts. But they’re all working together, they’re all collaborating, they’re all one team; not this separation idea. I think your example is very good, it’s not separate, but equal, it’s one team.

Alan Shimel:                I agree wholeheartedly. I’m not here blaming Gartner for pushing this whole Bimodal IT name and paradigm. But, Rosalind at last year’s InterConnect I remember having a bunch of conversations with you and Sanjeev Sharma and Carmen Diardo, and we were using the term variable speed IT. Right?

Rosalind Radcliffe:      Yes, absolutely.

Alan Shimel:                To talk about it – the similar thing, and, of course, I – we’ve heard other people use the term two speed IT. But I think in larger organizations, there’s actually more than two speeds; there’s a lot of different pieces that move at different speeds.

Rosalind Radcliffe:      That’s really the right answer. I really think it’s important have that ability to move at the speed required by businesses – the business demands, and that’s why it’s necessary. I think there’s a lot of thought process about Bimodal IT, because there are still or there seem to be people out there that still think the mainframe can’t move as fast, that it can’t use DevOps practices. I think that’s actually the core of the issue. We have to break down this thought process that the systems of record – the mainframe can’t move as fast, can’t be DevOps. It really can be, and it’s a reality – I guess it’s a hot button in a sense right now. I’ve just spent the last two weeks with two different clients, and this week with one of them – the first principle they put up was that there’s nothing about the mainframe that means it shouldn’t be DevOps. That the first principle is it needs to be DevOps, it needs to take advantage of the same pipeline, the same functions, the same capability to be able to move as fast as required in a reliable, consistent way with all the advantages of automated testing and automation.

Alan Shimel:                Absolutely. Rosalind, let’s turn a little bit to this year’s InterConnect where we will have – whether you want to call Bimodal IT, variable IT. There are out of the 200 or 300, I forget how many DevOps related tracks there, there will be some great ones, and I want to talk to you a little bit about that.

Rosalind Radcliffe:      Yeah, I’m looking forward to the event as well, though I’m not ready for it yet. There will be a lot of discussion and a number of sessions, both customers as well as IBMers talking about the variable speed IT or the different ways that different parts of the application development need to interact, and need to work together. One of the clients I was speaking with this week will be there talking about their DevOps development, particularly about how they’re literally building brand new applications on the in COBOL CICS applications using DevOps principles. So I look forward to all the different client discussions that are held there, bringing their teams together, and I think your Swiss gear interpretation is a good way of putting it. Because that’s what they’ll be talking about, how they’ve geared the teams together to be able to work together to provide the value the company needs.

Alan Shimel:                Absolutely. Rosalind, are you allowed – can we mention to our audience what company is that presenting? Are you allowed to say at this point or no?

Rosalind Radcliffe: So in that case, it’s Rabobank, because they’re published as a session speaker; so they’ll be speaking. There are actually quite a few. Rabobank’s one, UBS is another; there are numerous speakers scheduled – client speakers scheduled who are going to be speaking about their efforts and their transformations.

Alan Shimel:                Rosalind, what about you? I’m sure you’re speaking.

Rosalind Radcliffe:      Yeah, I have quite a few sessions that I’ll be discussing DevOps overall, working with clients and their transformations, the capabilities available, as well as having more discussions on the ops side of DevOps. I think one of the things that has been an interesting challenge is the how do we really bring ops into DevOps since we really do have ops organizations. That’s going to sound really strange, but when we think about DevOps a lot of the discussion has really focused on automation and delivery, not really focused necessarily on running the systems. So I’m trying to help some of the discussions bring more of the ops side in. How do we really get the ops collaboration coming in? How do we tie the teams together from a complete end-to-end standpoint?

Alan Shimel:                Excellent. Rosalind, it’s hard to pick among many, but what do you – besides the ones you just mentioned, give our audience – if they’re wondering should I go, should I not go, not sure; what are the two or three biggest either sessions or points of learning that you think people should know about to jump in here?

Rosalind Radcliffe:      Honestly, I think there are too many sessions to name, but the way to think about it is there are too many sessions to name. There are lots of client sessions, we’re going to be discussing their experiences. So the value out of a conference like this, one of the key values is the ability to hear from your peers, and to network with your peers to understand how they’ve done this, how they’re getting value. That’s the best way to learn from other people who are already experienced or who are experiencing. You’re going to learn from people who are headed for you, and you’re going to be helping people who are behind you. So it’s the networking, it’s the opportunity – hear those sessions, and the opportunity to meet all of the different people who are working in this space.

I think that’s the value of conferences like this; the chance to network and take advantage of that. Many people I’ve met in prior InterConnect’s have said it’s the collaboration, it’s the conversations, it’s the meeting of people that have given them the most value. Attending the sessions is also very important, but it’s the sessions that give them those contacts. So they learn in the session, and then they have this contact that allows them to continue to discuss. You always get fun – learn something new, you get some fun stories, you get something you’re really going to be able to take back and provide value to your organization.

Alan Shimel:                Absolutely. Rosalind, believe it or not we’re just about out of time; we probably have gone over. As usual it’s always — when this happens whenever we talk I apologize. But, I am looking forward to seeing several of your sessions at InterConnect, as well as I should mention – this is a quick plug, I am moderating a session myself on what DevOps will look like in the next three to five years, and I have none other than Gene Kim on the panel with me, which should be a lot of fun. So if anyone listening is attending Interconnect, please come on down for that one.

But, Rosalind, it should be quite a show, and I’m looking forward to how this whole Bimodal IT, variable speed IT, how it plays out. We’ve said it before, mainframes aren’t going anywhere, and the new way of doing things like DevOps and Agile and stuff it’s going to influence how we use our systems of engagement, but it’s not going to negate them. It’s always a pleasure to speak with you, and look forward to seeing you in Las Vegas February 21 to the 25^th correct?

Rosalind Radcliffe:      Correct. I’m looking forward to it as well, and as you mentioned the panel discussions, those are always wonderful. I’m hoping that I can make it to your session with Gene Kim if I’m not in another session myself. So I’m looking forward to it, and it’ll be a great week.

Alan Shimel:    Absolutely. Rosalind Radcliffe, Distinguished Engineer IBM, thanks for joining us today on this edition of DevOps Chats

January 28, 2016
To Be Continuous: Empathy in Software Development

Thanks for listening to To Be Continuous, a show about Continuous Delivery and software development hosted by Paul Biggar, Founder of CircleCI, and Edith Harbaugh, CEO of LaunchDarkly. In this segment of To Be Continuous, Edith Harbaugh and Paul Biggar talk with Sam Stokes about empathy in software development, how mini-services are the new microservices, and constantly updating software in a constantly updating world. Sam is currently a freelance software consultant and previously was the co-founder of Rapportive.

This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

[soundcloud url=”https://api.soundcloud.com/tracks/237727552?secret_token=s-k6OKe” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=flase” width=”100%” height=’166′ iframe=”true” /]

Paul: Alright, Sam, so what’s your favorite thing about continuous delivery?

Sam: I like to think about it terms of shortening feedback loops. A lot of things that startups do can basically be looked at as doing something and then waiting to get some feedback on it, and then deciding whether to do more of that thing or to do a different thing.

And continuous delivery is, people talk about sort of reducing the batch size and also about shipping stuff faster and clearly having some kind of automation. And continuous delivery is going to help you with both of those things.

Paul: So is this specifically on the, sort of on the journey of a small startup towards product market fit? Is that kind of the sense you’re thinking of it as?

Sam: I see it as applying to teams of different sizes. So for sure in a small startup you’ve got you need to iterate fast, you’ve got all these product ideas. But I think even if you’re a small team in a big company as I was recently working on, and still have a lot of the same pressures you have, product managers who want to try new ideas, you have customers who are sending in feedback all the time—some of which you want to listen to, some of which you want to tune out.

It’s sort of, in some ways, a lot like being in a startup. At least, ideally it would be. And a lot of the problems you can run into are basically about not being able to close those loops quickly enough.

Edith: Sam you’re someone who knows a lot about loops, so now might be a good time to introduce yourself.

Sam: Sure, my name is Sam Stokes. Until recently I was working as a staff software engineer at LinkedIn. And right now I am, I guess a freelance software consultant, thereabout.

Paul: I feel there’s a little bit of history missing there.

Sam: Alright. Going back in time a little bit. So I was a co-founder of a startup called Rapportive. That was a plugin for Gmail that when somebody emailed you, would show you a social profile of that person in the right-hand side next to their email.

So that you could get some insight into who you were talking to and put some more humanity into your communications with people—that’s sort of the way we saw it.

Paul: That’s still the only plugin to Gmail that I use.

Edith: I use it, too, and it’s for exactly that reason, ’cause I do a lot of customer development, and it helps so much to do, to empathize. To see that this—

Paul: Right, right, yeah is a real person.

Edith: You know, to see their face and you feel a connection.

Paul: It’s interesting just with kind of customer communication. One of the tools that we use is Intercom. And once I started using Intercom it was the same sort of feeling I got the first time I used Rapportive, that like I feel that there’s a human at the other end of this and I feel I know who that human is and it just changes how you communicate with the people.

Sam: It’s really motivating to hear and to see other examples as well. We really felt like email and sort of a lot of business communication in general can be sort of cold and formulaic.

Yeah, just bringing that human element, even just seeing a face. I haven’t used Intercom but I’m guessing they have some similar ideas.

Paul: Similar, when you send out messages or reply to someone it does the person’s face there.

Sam: Right, we had a sort of plugin API in the, it was a sort of private beta version of our product and one of the things people used it for, so this would let you plug into the sidebar, people would plug it into their customer database and so they could see something like, they’d get an email from a customer it shows them how long they’ve been a customer, how much they’ve spent in their store—

Paul: Right, right.

Sam: What version of the app they’re running, that sort of thing.

Edith: Was your original idea to do that sort of empathy or was that something that just you iterated into?

Sam: The empathy was where we started. There were lots of ideas about taking all the information from all these different sources, you know public sources like, truly public sources like Google, quasi public sources like a Facebook profile if you’re friends with them on Facebook, and then private sources like stuff in your company database.

All stuff that you would be able to search for if you could be bothered to go and do the searching but doesn’t necessarily bring itself to you while you’re talking to that person. And yeah, it was very much, what should you know when you’re talking to this person in order to make them feel like they’re interacting with a real person and an empathetic one.

Paul: So I remember when you launched Rapportive it was like, or it felt to me like it was, an instant hit and maybe that was just the overnight success that comes after years of trying. I had a doco and what was the kind of software delivery process of that?

Sam: Hmm, that’s a great question. I guess there’s two parts to that really. So how did it get there and what was our process that allowed us to survive it? So I guess how did we get there, it was a certain amount of luck in that process as there probably always is. We built our prototype and it was a pretty minimal prototype.

You know, it had the functionality that was like this awful demo website up. The only reason there was a website up was we were trying to raise a seed round at the time, we were applying to OIC. Y Combinator requires that you have a demo site that’s public. They don’t like it to be password-protected. And so we had this thing up where you could install it and we had like 20 users. One of our friends decided that he was going to email a friend of his at one of the blogs, I think it was ReadWriteWeb and say, you know, hey you should check this out.

And his friend checked it out and it turned out that one of the demographics that really liked the product that we built was journalists because they get a lot of emails from people they don’t know and they want to sort of know an extra nugget. I guess that was one of our takeaways was like, if your startup is really useful for journalists, that’s a great way to get some early press.

Edith: That’s what worked for TripIt because journalists travel a lot. So TripIt just got all this free press basically ’cause journalists used it, loved it, and blogged about it. Unfortunately, journalists do not do continuous delivery so much.

Sam: So how do we survive that? ‘Cause what happened in that 24-hour segment was that we went from 20 users up to 20,000.

Paul: Wow.

Sam: So I guess one part of it was our CEO had made the original platform choice. His name’s Rahul Vohra, he has a computer science degree, he’s an awesome technologist, but his focus is not generally on writing the software. He’d been writing the prototype, and he was like, ‘I need the quickest thing that I can get to get this market, so I’ll put it on Heroku.’

Which turned out to be a life-saving decision because when the 1,000 X traffic spike arrived we just added some more dynos. So that was how we didn’t burn down. What did we do after that? I guess in terms of software process we were pretty young as a company, so it was pretty much hack away, read all the tweets. But there was a lot of, what you might call customer development more than software development at the time. So we pretty quickly decided that we were going to try and respond to every single tweet and every single email and so on to like try and live this idea of a good customer experience.

And I think that helped to sort of amplify the viral effect of that press spike because people were sort of retweeting the things we were saying and getting a generally good feeling about us.

And so a lot of those tweets were like, ‘Oh I wish I did this,’ or ‘I wish I did that,’ or ‘I wish you could see Twitter profiles in there.’ So it was a little bit of sort of customer support-driven development. Which obviously doesn’t scale but it can be a pretty good way to build some goodwill early on.

And I think a lot of our users were sort of quite passionate about using us, ’cause they felt like they got that personalized attention.

Paul: So did the, when you scaled the dynos did it just work?

Sam: It worked perfectly until we hit the rate limit for the API that we were getting all our data from.

Paul: The LinkedIn API?

Sam: At the time we were using a service called RapLeaf.

Paul: Oh yeah, yeah, I remember them.

Sam: It wasn’t their main product, but they provided an API which … So basically the thing that Rapportive does, which is take an email address and produce social profiles about that email address. At the time that was entirely just UI wrapped around RapLeaf. We ended up building sort of our own version of that.

And so we’d been using their API on a sort of demo basis. Because again, 20 users. Yeah, we immediately had to learn about things like request queues, so that our app wasn’t just falling over waiting for their API, and then frantically Biz Dev-ing to try and increase our rate limit, while at the same time figuring out the best ways to get around the rate limit without upsetting the Biz Dev deal. Yeah, we didn’t really have much of a sort of continuous delivery process at the time.

But I guess not as many people were talking about it—this was 2010. I think the first blog post had come out from Iron View and so on, but I think it wasn’t as, you know, there weren’t full startups supporting it. What we did have was the Heroku deployment model, which was basically like within five seconds of writing the code you can deploy it to production.

Which if you squint at it, kind of is continuous delivery because you’re saying, all of the bits of your deployment that you have are automated. We didn’t really have many tests at the time, so the tests we had were automated ’cause there weren’t any. Our deployment was absolutely, you do it get push, you don’t have to like move any servers around or anything like that.

Paul: Seems like the testing model around, or the continuous delivery model around a Gmail plugin is probably going to be a fairly difficult process anyway.

Sam: We never really had a good answer to, you know, what happens when Gmail changes their UI. The surprising part was it didn’t happen that often. We thought it would be breaking every week and we’d need all kinds of canary accounts and end-to-end testing to monitor that kind of thing. In the end, it happened rarely enough and we noticed quickly enough that we could usually just fix it on the spot. So even when we got better at testing and that sort of cycle of things.

Paul: We had a problem or I guess solution with GitHub. So GitHub used to be super flaky around two, two and a half years ago, when they were still on Rackspace. And whenever something would go wrong with GitHub we would find out immediately. All of our, all the developments would start failing and so before they knew that there was a problem, we knew there was a problem.

And we would often like, declare on Twitter, oh we think GitHub’s having a bit of an issue and two minutes later their status would tweet us and then we would retweet their tweet.

Edith: So they were using you for their free testing.

Paul: Well, our customers at least.

Edith: No I mean you were acting as their tester and telling them that—

Paul: Well, I mean it was very, you know, automated on our but we didn’t have necessarily automated fixes at the start. It kind of happened every, you know, two or three months and they would swear this is the last time and—

Edith: It’s always the last time.

Paul: And in the end it happened like six or eight times and by that time we had built a thing that allowed, you know, certain fixes, but it wouldn’t be quite, you know, fully automated process that you would expect if it was happening all the time ’cause it always seemed like it was gonna be the last time.

Sam: And it’s probably always happening for a slightly different reason or in a slightly different way. It’s actually, it’s an interesting question to me in the subject of continuous delivery in general. People always talk about every time you commit you run your tests, every time you commit, you deploy.

But that’s actually only one of the kinds of events that you’re dealing with in a software life cycle, right, when something’s actually running. I mean, sure you’re changing the code but also the world’s changing around you. And I feel like you always end up needing a little bit of both—you need something that’s gonna trigger when you change it, but you also need sort of an eye on everything you depend on. And, of course, even figuring out what all those things are can be interesting.

Paul:

So I wrote a blog post about this on the Heavybit Blog, I think a while back, and it was about third-party APIs you know, how do you test third-party APIs. And the conclusion that I came to was that, so if you run the tests as part of your test suite, then if something breaks, your test suite will be broken, but also some things will just like randomly break in production.

And then of course you can’t deploy because your test suite is broken. So you’re in kind of the worst of both worlds. And so what I considered is, is that you need something which, you know, is just permanently monitoring. Like whatever API things you do constantly hits your personal accounts or your test accounts for those things, and then stub it out in your test suite.

And that way you kind of get that best of both worlds, your test suite doesn’t fall over and you get an actual monitoring event when the third-party service goes down in production.

Sam: I can tie this to an experience from LinkedIn, actually. So LinkedIn has the model where there’s a staging environment and a production environment. And the staging environment is—I don’t know if it’s technically called a staging environment because it’s not exactly production-like, but what they actually call it is early integration. Because it’s the environment in which teams integrate with other teams.

And so the idea is you deploy your stuff into EI, early integration, as soon as you can so that if any other team depends on you or vice versa, you can find out there before the thing hits prod. But what you’ve effectively got in EI is this constantly changing environment full of dependencies and you have exactly this problem and different teams which using different solutions to, well, let’s write some integration tests which actually hit the dependencies and then we’ll run them in our test suite when we deploy to EI or when in the build step which—

Paul: I can’t tell as you’re describing this whether this is a good thing or bad thing.

Edith: Yeah.

Sam: I think there wasn’t a clear conclusion, but my conclusion is that it doesn’t work for the same reason that you’re saying.

You need to know that if your test suite fails, it fails because of something you did. And then you need something else that can fail because of something someone else did.

But if you’re ever unsure which of things it is, then the signal is lost for both systems.

Be sure to listen to the full episode. While you’re there check out Heavybit’s library, home to great educational talks from other developer company founders and industry leaders.

January 8, 2016
To Be Continuous: Evolution of Continuous Delivery

In this segment of To Be Continuous, Edith Harbaugh and Paul Biggar discuss the evolution of continuous delivery. This podcast is brought to you by Heavybit, a 9-month program for developer startups.

Edith is CEO and cofounder of LaunchDarkly, a continuous delivery tool of “feature flags as a service.” LaunchDarkly powers software teams to quickly launch, measure and control their features.

Paul is the CEO and founder of CircleCI, a continuous integration and deployment platform that automates development workflows and IT operations, allowing developers to ship quality software significantly faster.

[soundcloud url=”https://api.soundcloud.com/tracks/224359194?secret_token=s-rlyTD” params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

Edith: So Paul, where did continuous delivery come from?

Paul: This is one of those things that evolved over quite a long time but I think that that major catalyst of continuous delivery was the fact that we moved to SasS and that SasS now exists.

Edith: So what was it like before there was continuous delivery? What was it like when you were starting out?

Paul: The first company that I really worked for was a games company and I think that a lot of them are kind of in the same place now. You would release software on a disk that shipped to customers via stores and you had to have a gold master at some point. We were a startup so it was quite advanced.

We had a daily build server and we actually were selling middleware so we shipped software to those companies but those companies would ship at the end of the day, they would ship a disk that went out once and there was no updates at the time.

It was 2003, 2004, something like that. There wasn’t any way to automatically update on customers’ Playstation 2, unlike even games now have a little bit of continuous delivery but back then, that was, you got your chance to ship it and that was it.

Edith: Yeah, I just had a brutal flashback to one of my first summer jobs, which was installing Windows 3.1. This is back when you actually had a set of 35 disks so my job as a summer intern was to go to every computer in the office and just literally sit there. Disk in, disk out, disk in, disk out, and if something went wrong on the install, I had to start over at the beginning.

It was a two hour long process just to get everybody up to 3.1 so in those days, there was no change of a fix pack. I think everybody was going to be on this version until probably they got another sucker summer intern in there.

Paul: So if you imagine people and their, people installing, even modern or relatively recent version of Windows where you have to think about the service pack one or service pack two or what level are you patched to, that was basically the old way of doing software.

The first time that I remember realizing that there was a different way to do it was in a Joel on Software blog. One of the major things that they could do is that there was a bug, they could fix it and in the cloud, it would be fixed.

Edith:

Yeah, I think it’s good though to realize that the reason that there was so much emphasis back then on making sure that a build was correct was because there was such heartache and pain if it was wrong.

Paul: Yeah, it made sense to hold up the release for new features or for something like that if it was promised to a customer because then, there was no alternative. It would be three, or six or twelve months later when they got the next opportunity to go ahead.

I think frankly, building software in the cloud and having the possibility of doing a release at any time you like has actually just completely revolutionized how people make software.

Edith: I completely agree. So to go back to the old days, all the emphasis was on extremely high quality and extremely stable.

Paul: Right, right.

Edith: Because you basically had once chance. You were lobbing this thing out into the world.

Paul: And even things where they had quarterly release cycles or something like that, it was still, it felt a lot like one chance. I worked at Mozilla and I was there on the switch from Firefox 3.0 to Firefox 4.0. Firefox 4.0 took 18 months to commit and there was things that were ready to be released the first week of that release cycle and that had to be held up for all these unrelated releases.

I think there was problems with the JavaScript engine and there was memory bloat and that sort of thing that kept pushing it back. And Firefox, during the process, or during the time that I was there, switched its process and it switched to what they call a release train model where basically, they ship a new version every six weeks and it doesn’t matter what’s shipped or what’s not shipped.

They’ll hold it up for total life, or build breaking, it just doesn’t work at all but basically everything else would make it go ahead. The cadence and the velocity that they’re able to get since that happened has been massive.

Edith: Yeah, so that was the first evolution. It used to be let’s try to cram everything in and then you’d get this vicious cycle where it’s like well let’s just put this one more thing in and then you’d have to add on all the QA time.

Edith: So that was the other reason why releases would take so long is you had so much QA.

Paul: Interesting.

Edith: I talked yesterday to a guy who had worked at Microsoft and he said, you know, quality had to be rock solid for Microsoft going back to my disk example.

Paul: Right, and these are people who have unit testing, automated tests as part of their builds.

Edith: But even beyond that, you have to have a person actually try it and then you have to actually go out and try it on all these different systems.

Paul: On all the different systems, right.

Paul: So one of the things that made it possible for the browsers to do, to move to the release train model is that they had the alpha channel and the canary channel, or whatever it is they called it. In Firefox, it’s the Aurora channel.

That’s the super, actually that’s not even the super beta stuff, they even have a nightly channel. They have a million people using the nightly and that tells them whether things are broken and how they are in fact and in production. I guess it’s kind of the first evolution of feature flags.

Edith: Yeah, I mean let’s talk about that for a second.

Paul: Right, we probably need to, aren’t we going to define things in this one?

Edith: Yes, this is the definitional episode, Paul.

Paul: Right, let’s start with what’s a feature flag because I think we’ve already talked about six things that we haven’t defined but what’s a feature flag?

Edith: A feature flag is basically the ability to hide code but yet have it public. So it used to be that everything that shipped was visible. So a feature flag is just basically an if then that wraps a piece of code and says it might be shipped but nobody can see it until the software team decides that it’s visible.

Paul: Right, and so some examples of that could be in a browser that you change a preference and the preference is use the new version of this or another example might be in, that a feature goes out in Facebook that’s shown to 1% of customers in Northern California who are in this demographic. Yeah, and it’s very liberating.

Edith:

The very liberating thing about a feature flag is that if something’s not working, you don’t have to do a redeploy.

So to go back to the old dark days where you had all these disks out in the world, the feature flag is useless because you’re going to ship all these disks out to people and they’re going to install it. A feature flag is useful when people are consuming stuff as SaaS.

Paul: The way that I think about a feature flag is that it separates the active shipping code from the act of actually turning on that code.

Edith: Yeah, deployment from roll out.

Paul: Right.

Edith: Yeah, so it’s deployed, it’s available, but it’s not visible.

Paul: Right, so now that we know what they are, what were we actually talking about?

Edith: We’re working our way through the evolution of software so we got up to release trains. You should talk a little about how continuous integration fits into that.

Paul: So continuous integration, to define it, it’s basically the act of having an automated build server that runs every day or at some sort of cadence and tests that your software works.

So CircleCI, my company, makes continuous integration as a service and what happens there is whenever you push to GitHub, we’ll automatically check your code out, we’ll build it, we’ll run your tests on it, and we can also deploy it to your customers, which is called continuous deployment or continuous delivery, depending on exactly how you think about the world.

Edith: You make this seem so simple but it’s really revolutionary. I remember the days without this.

Paul: Sure, sure. I remember in my first job, we had a daily build server and so we would find out every day whether or not the code actually compiled, even though we could get it all compiling on our own machines or some modules of it or whatever, compiling on our own machines, there’d be all sorts of build artifacts and dirtiness in the code that meant that this code didn’t actually work when it was ready to be shipped to customers.

Edith: Yeah, or even worse, I remember it used to be a thing when you broke the build, it was very shameful. You would have to sing a song or you’d have to do something embarrassing and that just doesn’t really happen anymore.

Paul: Right, right. My co-founder used to forget to add new files to Git so it constantly wouldn’t work although it was perfectly working on his machine but there’d be a file missing somewhere.

Edith: The classic excuse of, “Oh well it worked on my machine.”

Paul: Exactly, yeah.

Edith: Yeah, I didn’t know about builds my first summer job. At my first summer job, I was programming in Visual Basic.

Paul: Okay.

Edith: I was basically making a war game. It was for a defense contractor and I was trying to justify a space based laser versus an airplane based laser and if you had all these missiles coming over from Russia. Okay, this is a long time ago.

Paul: Yeah, yeah.

Edith: How many could you shoot down? The thing worked perfectly locally and then at the end of the summer, they wanted it off my machine. I was just like, “Oh.”

Paul: Okay, you’d need to put it on a plane or in space or one of those things?

Edith: No, they wanted my actual files off my machine.

Paul: Right, yes, in order to put it in space or on a plane?

Edith: No, it was just a simulation. I wasn’t actually controlling missiles when I was 19. Though that would have been cool.

Paul: I had this absolutely terrible release process at this place that I worked. It was O2, which is a really large phone company in the UK, in Ireland, and I think they got bought by someone recently but whatever. They were launching this feature called i-mode and i-mode is this massive thing in Japan that completely failed to take off anywhere else.

Edith: Are you saying it was literally big in Japan?

Paul: Literally, it was big in Japan. And so they tried to launch this in Ireland. Everybody in the whole world knew that this was going to be a failure, but that was how the process worked anyway. And the release process was they had all this code somewhere that was going to be deployed and attached in servers and when they did that, there’s a manual. I was part of the manual team that manually validated with handsets, clicking through handsets manually, and vouched that this stuff actually worked.

There was no automation. The entire release process had to be repeated dozens and dozens of times as they fixed bugs and they reconfigured. It was, it was just a complete cluster.

Paul:

When I moved to doing software that had any sort of continuous release cycle, it was liberating because you actually know the path from what you’re doing on a day to day basis to it arriving at customers. Everyone, every developer in the place can know what that path is and everyone knows how code acutally gets shipped. You don’t have to keep it in a continuous state of you know, oh maybe one day I’ll ship this.

Edith: Yeah, I mean I think to go back when you had these longer and longer and longer release trains or even pre-release train, people got very relaxed.

Because it just was like oh, I’m just going to sit in the corner and code away and sometime in the distant future, it might ship.

Paul: Right, and then as you’re coming towards the end of the quarter, everyone is hammering things out as quickly as possible and maybe there’s a few things that shipped early in the quarter that never got cleaned up or never got quite ready.

Edith: What do you mean by shipped right now?

Paul: So I remember sometimes where you’d merge something into master because you needed to get it tested but it wasn’t quite production ready. It’s out with the beta testers or something like that, but in order for it to actually ship to hundreds of millions of people, you need to remove whatever hacky thing you put in place.

Edith:

I think one of the things that has driven continuous delivery is just the rise of test-driven development.

Paul: That’s interesting. Yes, I mean, I think it’s obvious. You end up in a situation where when you’re trying to move to continuous delivery, you’re saying I’m afraid and we talked about the fear last week.

In order to get past that fear, you need to have automated testing and I guess in the old days, there was manual release cycles and you can’t do manual release cycles 10, 20 times a day. It’s just not possible.

Edith: You can’t depend on having a fleet, like to go back to the Microsoft example, you can’t rely on having two QA engineers for every developer who will, you know, you just fling out code and they’ll find everything.

Paul: Even with two QA developers, you can’t have two QA developers when you push code every five minutes.

Edith: Yeah, they’ll never keep up.

Paul: Exactly and then they’ll never identify the change that actually caused the bug and so on.

Edith: Yeah, I think the things we’ve talked about so far, SaaS has unlocked continuous delivery, test-driven development has unlocked it. What else do you think is really a foundational thing?

Paul: I guess the other one is kind of this change in customer expectations. Customers, as a fact of some people doing continuous delivery, everyone else has had to do it so once you start to experience it a little bit, and you start to wonder why do other sites go down for six hours on a Sunday night, this doesn’t make any sense. Why do I have to download new versions of this software versus clicking the update version or why do I even have to think about this?

Edith: Yeah.

Paul: I think for the installable software market or the desktop software market, Chrome was that sort of killer app that everyone sort of realized that this has completely changed the game.

Edith: Yeah, it’s completely changed the game.

I think even now asking people to download a plugin seems too onerous. They don’t want to do it. They just want stuff to work.

Paul: It’s almost tied to a conversion funnel. If you expect people to install 31 disks to upgrade to the latest version of Windows, people are just not going to do it. You’re not going to achieve the conversion rate that you’re expecting. There is too many alternatives to your app that are out there.

Thank you for listening, the entire Heavybit podcast can be found here.

September 22, 2015
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
CI and CD Across the Enterprise with Jenkins November 19th

We recently held another webinar in our continuing series at devopsy.kinsta.cloud. We partnered with the good people at CloudBees on CI and CD across the enterprise with Jenkins. The webinar featured:

Cyrille Le Clerc is Director of Product Management at CloudBees with more than 15 years experience in Java. Prior to CloudBees, Cyrille was Chief Technology Officer at Xebia. As an early adopter of the “you build it you run it” model, he put it in place for a number of high volume web sites. He naturally embraced DevOps culture. He is also very active in the Java community, creator of the open source project “embedded jmxtrans” and a speaker at various conferences.

It proved to be the most popular webinar we have held yet with almost 1500 people registered! Many were not able to log in live for the event. We are making a recording available for those who could not attend and anyone else who would like to listen:

Hope you enjoy it and stay tuned for more webinars.

November 26, 2014
IBM DevOps Webcast Nov 20 – Transforming Application Delivery for Continuous Innovation

What if you could deliver applications faster without compromising quality or accepting higher risk? Fast-moving adopters of technology are transforming software delivery to disrupt entire industries with rapid-fire, digital innovations that leverage cloud, mobile, big data and social.

How do you deliver 10-times faster business innovation instead of 10 percent incremental improvement? New and established companies are using DevOps to transform their software delivery process and are achieving dramatic improvements in overall speed, quality and business satisfaction.

Join executives from GE Capital, Forrester Research, IBM and others for a series of lightning talks with real experiences and best practices. Learn how you can adopt DevOps practices that deliver early wins and transform your application delivery process.

Date: Thursday, November 20th, 2014

Time: 8:30 – 9.30 AM Eastern Standard Time

Registration link: http://bit.ly/14z82GS

Speakers

Snehal Antani – CIO & Chief Architect, GE Capital Americas
Kurt Bittner – Principal Analyst, Forrester Research
Kristof Kloeckner – General Manager, IBM Software Group
Steve Kagan – VP, IBM Global Business Services
Dibbe Edwards – VP Development, IBM Software Group

In the New York Metro Area?

Join us in-person for a free, full-day event.

Click here to sign-up: http://ibm.co/1ljyjQQ

Download the event flyer here: ibm.biz/jerseycityflyer

November 18, 2014
Achieving business agility: a webinar with Chef and Rally Software
We recently hosted our first devopsy.kinsta.cloud webinar with Chef and Rally Software.

Using DevOps to Achieve Business Agility

In today’s digital economy, leading companies are turning to software to deliver new services in response to customer demand and competition. Technology can enable and expedite innovation, but it requires business leaders, software developers and IT operations teams to closely collaborate around shared goals, at new speeds, and with the flexibility to change on a dime to customer needs and market shifts. In this webinar, Rally Software, a leading global provider of enterprise-class software and services solutions, will discuss how it has institutionalized DevOps and how it uses Chef to support its speed-focused approach to delivering business agility. You’ll learn firsthand how Rally automates its virtualized infrastructure, accelerates application development and tightens customer feedback loops.

Speakers include:
- Jonathan Chauncey, developer at Rally Software. He’s been involved in Web application development for almost 10 years, four of which have been at Rally. His technical interests include: automation, testing, clojure, Ruby and search.
- Jeff Smith, development manager at Rally Software. He’s been involved in Web application development for almost 20 years, 11 of which have been at Rally. His technical interests include: test automation, continuous deployment and infrastructure automation.
- Colin Campbell, director of patterns and practices at Chef. He has worked on advanced model-based testing and analysis techniques for a number of years in industry. He is currently involved in developing and documenting Chef best practices and design patterns.
Here is the recorded version of this great webinar:
September 11, 2014
Jeff Knupp of “DevOps Killing the Developer” on Linuxinstall Podcast Tuesday

Brian Wagner and Linux Install Podcast team will feature Jeff Knupp on tomorrow nights show. Of course Knupp wrote the controversial “How DevOps is killing the developer” blog article last week which touched off a firestorm. This week Knupp will respond to some of the criticism and and further discuss his views.

In last weeks episode of the linuxinstall.net the team took author Jeff Knupp to task for his article “How ‘DevOps’ is Killing the Developer”.

Linuxinstall.net will be recording live on Tuesday April 22, 2014 @8PM with Mr. Knupp. He will be on to discuss the article and the significant response to it. If you have any questions for him please let the linuxinstall.net team know via Tweet(@linuxinstall), Google+(https://plus.google.com/+LinuxinstallNet), or via E-Mail podcast@linuxinstall.net.

Should be a good listen!

April 21, 2014
Episode 2 of devopsy.kinsta.cloud Podcast

Mitchell Ashley and I are joined this week by Stephen Wilson of Compuware. Stephen is a regular blogger here on devopsy.kinsta.cloud, but is also the technical evangelist at Compuware. Steve gives us his background and a brief description of what Compuware does. Then we all talk a bit about Steve’s last article here on devopsy.kinsta.cloud, Don’t worry testing team, DevOps is here!. While some say that testing is a big loser in DevOps and many testing/QA teams feel a threat to their job security, Stephen says not true. In fact DevOps makes the testing team superstars. Tes.com ting teams should embrace DevOps as it will make their job easier and more powerful, but not less important. Steve talks about the concept of “continuous testing”. All of this in just about 13 minutes.

Enjoy!

[soundcloud url=”https://api.soundcloud.com/tracks/142563047″ params=”color=ff5500&auto_play=false&hide_related=false&show_artwork=true” width=”100%” height=”166″ iframe=”true” /]

Also if you would like to be a guest on a future devopsy.kinsta.cloud podcast write us at podcast@devops.com

April 2, 2014
devopsy.kinsta.cloud Podcast

Mitchell Ashley and I have been doing podcasts together since about 2007 or so. Back then the subject matter was security. But now with the launch of devopsy.kinsta.cloud we are launching a new series of podcasts on DevOps. In doing so we are joining a small field of quality podcasts on DevOps. Podcasts like DevOps Cafe and Arrested DevOps have set a high bar of quality. Eventually Mitchell and I hope to join them. Our podcasts will be shorter than some of the others though. They will be supplemented with Mitchell or my notes from the show.

So here is our first episode. We really just introduce Mitchell and I to the audience and talk a little about some of the stories on devopsy.kinsta.cloud over the last week. In the future we will have guests and dive a little deeper into the world of DevOps.

[soundcloud url=”https://api.soundcloud.com/tracks/142516025″ params=”color=ff5500&auto_play=false&hide_related=false&show_artwork=true” width=”100%” height=”166″ iframe=”true” /]

March 26, 2014