The practices and technologies of DevOps have begun to spread into what I’d call “the mainstream,” which is fantastic: DevOps has a lot to offer to all IT organizations. IBM has taken notice and started getting involved. Here, while at the IBM Rational conference Innovate 2011, I talk with IBM’s Pete Marshall and Peter Spung about DevOps is and what IBM has to offer.
Transcript
Michael Coté: Well, hello everybody! Here we are in sunny Orlando at the Rational Innovate Conference in 2011 of course. And this is Michael Coté of RedMonk as always, and I have got two guests with myself. Would you guys like to introduce yourselves?
Pete Marshall: Hi! I‘m Pete Marshall from Tivoli. I am in the Strategy Group.
Peter Spung: I’m Peter Spung from Rational, also with the Strategy Group.
Michael Coté: So what we have here I think is sort of like a meet embodiment of a trend going on at the moment called DevOps. On the left we’ve got the Dev and on the right we’ve got the Ops.
And so I have been talking with you guys a little bit about DevOps and just — I have been talking with everyone about it, so it’s fun to have you guys here to talk about it. And I am curious, rather than me ramble on about DevOps, what are you guys seeing is sort of the challenges that are impelling people to look into integrating development and operations together more? What’s driving this interest in DevOps?
Pete Marshall: Well, I think the interest is getting driven from a number of areas. I mean, people are seeing what’s going on in the web space, they are looking at the Flickrs of this world, the Googles of this world, and they are saying, yeah, can I do some of that? Can I do continuous integration into production? Can I get my development operations people working together? And how do I go about doing that?
And especially, how do I do that in an enterprise environment where there is a lot more going on? There is a lot more legacy code. There is a lot more moving parts. There is a lot more entrenched organizational structure. So there are some big challenges there, but I think the rewards people are looking for are great.
Peter Spung: The moving parts really resonated with me when Pete said that, because when you think about it, not only the applications that get deployed and used on the web as he was talking about or generally in an enterprise have a lot of moving parts and a lot more keep bidding at it.
In fact, there was a stat I saw the other day that in 2010 half the server deployments were virtual, not physical. So we have crossed this threshold where more and more the server deployments are virtualized instances, not physical boxes. So the number of moving parts keeps going up.
Organizations, are getting more-and-more complex, lots of off-shoring, lots of globally distributed enterprises all over. So it’s just getting more complicated. People need to be able to integrate these capabilities and functions, and people that get the work done in order to deliver the capabilities they need.
Michael Coté: That definitely sounds kind of like the enterprise take on DevOps, where you have complexity because it’s necessary, not because it’s sort of like an albatross hanging out on your shoulder, but it’s what you need to run your business essentially, and whether it’s geo-distributed or just a lot of complex moving parts in software.
And I wonder, as sort of an example of the benefits that you get to, I mean, do you guys have some interesting examples in that, whatever you want to call it, big or complex or enterprise, some examples of DevOps or DevOps-like things being successful? Like what’s a way that you can tell people, here’s why you would go through the trouble of learning about this DevOps thing and adapting to it?
Pete Marshall: Well, I mean, we’ve got one customer in the financial services space that’s bringing together its asset management for both software and the infrastructure. And what they are finding is, more and more they are just making savings in time and deployed assets, because they know where things are. They can go out confidently, do a deployment, do things quicker. Really get time benefits, cost benefits, that space.
And are they doing that a 100% across everything? Absolutely not. Doing that in a very small part of a very large enterprise, but they are getting good savings out of that already.
Peter Spung: We’ve got another client who is — basically they are a workforce company, they place employees into different jobs. And they had an application that was actually core to their business, a portal that’s used for the direct interaction of the employees with the managers and placing them.
And this employee portal, they were having all sorts of availability problems; crash, they were having problems diagnosing where the issue was, couldn’t figure it out.
So they put some integrated solutions in place, some frameworks, some automation, a whole bunch of tools offered by both Rational and Tivoli to solve this problem, and they increased their uptime dramatically, and they are looking to deploy this to more of their applications.
They felt — the framework they put in place in DevOps was not only one about tools and infrastructure, it was also about culture. They did a whole lot to break down the barriers between the development and operation organization, and get people collaborating and working together towards shared goals, keeping this portal up.
Pete Marshall: Culture being probably long-term, one of the biggest benefits you get out of this. If you can break out of this mold of, it is development and our job is done once the code is tested and then here’s the CD or a set of files, go forth and implement it. Culture change is interesting.
Michael Coté: Yeah. I mean, it’s definitely something that I see, and kind of when I am evaluating if something is DevOps or near DevOps, it seems like — it does involve a fair amount of organizational or a cultural change, or some amount, I don’t know exactly how much.
But more importantly, the kind of technologies that facilitate that and make that change possible, because there is always a back and forth between the way an organization is structured and the technology that enforces it, and it’s just a loop that goes around.
And along those lines, I mean you guys were getting to some of this, but I wonder if you could give people some guidance when they are thinking about doing DevOps or evaluating different options like, what are the kind of things they need to be looking at to trust that it is a DevOps thing? Like how can they establish trust with the offerings?
Pete Marshall: That’s a really good question. I think what you really need to look at is this — is this change in terms of a process, in terms of people, of culture as you were talking about. I think that’s a very important thing.
I’ve seen projects where we’re going to do re-tooling but we’re really going to keep these things separate. So look for shared outcomes, right. What are you actually trying to do here, if you’re just trying to improve technology or you’re just trying to improve results in operations, results in development, that’s great. Maybe you’re doing virtualization or automation, cloud, maybe you’re doing Agile on the development side, but really you’re not doing DevOps. DevOps is going to smell like DevOps, it might not be able to point and put your finger on what it is, but you’re going to see those changes happening on both sides. If it’s not, you’re not doing DevOps in my opinion.
Peter Spung: I would agree. Give it the sniff test and then make sure that it’s capabilities that span both development and operations. So it’s during planning, planning applications and scoping them out and architecting them. Can you architect the infrastructure, as part of it, right? Can you think about what’s going to be happening in deployment? Can you design for that? Can you design for run-ability, sustainability, in the manufacturing term, let’s say design for manufacturing? That’s sort of concept. Does it transcend what’s going on inside development?
You mentioned looping back, which I think is a really important notion. Once things are deployed, can you build feedback groups, that feed back information from operations back into development? Trouble tickets flowing back in defects, performance data flowing back into test automation, and test suites, that kind of stuff. Can you establish those linkages? Can the vendor show it? Call us in, call any of our competitors, and let us demo it for you. Let us set it up and do a proven technology.
Michael Coté: Yeah, that feedback loop is one of the things I like the most just because I feel like it gives developers insight into people using their applications they didn’t have before or at least a lot more easily and quickly. This data was always out there but I think there is a lot of effort in DevOps to lower those walls down and to be metaphoric about it.
Peter Spung: Yeah.
Michael Coté: So finally, we’ve also kind of hit on some of the things you guys are thinking and I am guessing they’re kind embodied or embedded if you will in IBM offerings. So I’m curious like what it is that IBM has to offer at the moment in the DevOps area? If one of those people wanted to come to you guys and ask you to, show us what you’ve got, like what would be the kind of things that you would put in front of them?
Pete Marshall: Well we’ve got a whole set of integrations between the Rational and the Tivoli tooling. We’d cover everything from deployment, integration of defect and problem management, integration of the data layer, the assets and CMDBs, change management. As Peter is saying, some more applications that get into things like enterprise deployment planning, governance, that kind of thing.
What we find is that we take these to our customers and everyone wants to do something slightly different, I don’t think there are any cookie-cutter DevOps projects at least in the market today and we’ll engage. So folks who are watching this video and who are here at Innovate come and talk to us, and if not, give us a call, get in touch. We just put a new Collaborative Development and Operations website up on ibm.com, under both Rational and Tivoli URLs, and you should come and check us out.
Peter Spung: And you’re asking this fundamental question, I think, about what claims can clients believe, and how should they test the vendor making the claims? I’d say do it, test them, I’d also say look at the particular attributes, like how consumable is the solution. Are there multiple, what we call entry points? What customers would call bite-sized, accelerated pieces that they could take on and accelerate a solution for them, and get that done. As it based on open standards, is the way the integrations are done, open accessible that other vendors can play.
We have an architectural movement and I’d call a de facto standard called OSLC that we’re working on. It’s an Open Interface, it’s got about 365 registered people in 34 companies interacting with it. Basically building out specs for integrating requirements management, change management, quality management, all those sorts of things.
So ask the vendor, is this open, is the way you’re integrating something I can extend, is it something that other vendors in a large ecosystem can play in? Those are important attributes of a solution that client should ask the vendors about, and we’ll stand by what we’re doing I think.
Pete Marshall: Probably we will, absolutely.
Peter Spung: Absolutely.
Michael Coté: Well great! Well, I think it’s been nice to see you guys as a large supposedly ponderous company, kind of pretty quickly move on to doing something in DevOps. So it’s been nice to see that you guys have actually you have something to offer people at the moment, and I really appreciate your spending the time to go over what you guys see as DevOps as useful and how it’s being used and then more importantly what you guys have at the moment to help people out.
Pete Marshall: Yeah, it’s an exciting thing, it’s an exciting time, it really is.
Peter Spung: Yeah, we are in it for the long haul, we’ve been doing it for like five years now, and we’ll be doing it for ten more, I’m sure. It’s a big problem and it’s complex, and we’re happy to be part of it, contributing, making stuff happen in the industry. And thanks for the opportunity to talk.
Michael Coté: Yeah definitely, we’ll have to check in next year and see how it’s turned out.
Pete Marshall: We’ll do that.
Peter Spung: Super!
Michael Coté: Well, we’ll see everyone next time.
Peter Spung: Thanks Michael!
Disclosure: IBM is a client and sponsored this video.
Recent Comments