DevOps: How to get started and how to make it work
DevOps promises to make development and operations work together seamlessly to deliver better software quicker. But how do you make the right start?
Nathan Wilson is a research director at Gartner, and his primary focus is on the adoption and governance of agile computing, including lean, agile development and scrum.
ZDNet spoke to him about the different definitions of DevOps and how it is likely to evolve.
ZDNet: I think people are finding it hard to define DevOps. Do you find that?
Wilson: Yes, DevOps does not have a consistent definition within the industry and the definition is changing because of different impacts. But initially we defined DevOps as applying agile techniques to operations and getting development and operations to actually work together.
So the next thing is you break down the wall between QA [quality assurance] and dev and then you go into agile - and soon you are breaking down that wall into operations.
That was classically the way we talked about it and then a few years ago a major vendor developed a continuous deployment tool and they re-defined DevOps. They saw it as instant deployment - where a developer would check something in and then it would be in deployment within an hour. So that got labelled DevOps.
Then a friend of mine, another Gartner analyst who covers the operations side of DevOps, George Spafford, with Gene Kim and Kevin Behr produced The Phoenix Project. That became known as the DevOps book even though it was not their intention to write a book about DevOps but instead to write a book about how you apply lean management to IT.
Now applying lean to the whole IT process is also considered to be DevOps. So you're right, there is some confusion about what DevOps is. In fact, there are a whole bunch of crazy definitions.
Q: So there must be a huge gap between the companies that are doing it, even though they might not be calling it DevOps, and those that aren't?
Yes, we look at what we call "web-scale vendors", or we might call them "hyper-scale vendors" like Amazon, Netflix, and so on, who are on the cutting edge of this. They are doing things that nobody else can do and they are a great source of inspiration.
So we say, 'Look at what those big vendors are doing and you may not be Facebook but you can learn from Facebook'.
Then there are a few companies who are kind of one step back from that but they are doing things like nearly-continuous delivery - they are doing delivery more than once a day on some of their projects.
These are companies that, like with The Phoenix Project, are working on reducing their batch sizes [reducing the amount of code required in a change] to try and get down to that magical batch size of one. That means just one very small change going out at a time. But to be honest, most of the other people I talk to are just now learning to do agile.
Unless you can do something like 'Scrum and Deploy' every week or every two weeks, you are not ready to go faster. [The idea of Scrum is to create a safe and change-free environment so that your team can concentrate on the planned development task. The team plan out a sprint of two weeks to develop and deploy an idea.]
Now of the 1,000 or so companies I have spoken to about agile, very few of them have got to that point.
Q: What are the issues?
It's largely culture. Some of it's around practices. I wrote a piece last year called Fire Two Thirds of Your IT Organisation and it laid a lot of the blame on middle management.
There was a gentleman from Intel who described it as "the middle-management permafrost". That's not unusual in any organisational change. The developers understand it and the senior managers understand it - largely because they have read The Phoenix Project - but the middle managers see it and think, "I don't know how I am going to add value to it so I am going to fight it because if I don't I think I am going to wind up on the street".
Q: So is there a middle management roadblock that is difficult to get around?
Yes, it is quite difficult to get around. One way to do it is to understand that agile is a team sport. Most IT departments are not a team, they are collections of individuals.
There was a book a few years ago called Tribal Leadership and it indicated that a team-oriented culture was only about 25 percent of any organisation. So what do you do with the other three-quarters? Do you find some way in which they can work, even though they can't form teams because their culture isn't team-friendly?
Q: But isn't that an old idea going back all the way to the cult of the 'genius lone programmer'?
That's still prevalent. You will still see articles about looking for that '10x programmer' which is what you call that person now. But I will constantly remind our clients that it does not matter if you have a 10x programmer or not. Now it is all about the 10x team. Now that 10x team may include one of those 10x programmers, but you had better put some people with social skills around him or you are going to have a problem.
Q: How many of your clients do you think are adopting DevOps or at least talking about it?
It has followed on from agile. I very seldom get a call now that says, "We are just thinking about adopting agile". Three years ago that's what most of my calls were.
So it used to go, "We have agile going on in these groups, how do we expand it?" Or, it went, "Our new CIO says that we have to be agile, how in heck do I pull this off?" Now it's: "We need to do DevOps, how in heck do I pull this off?"
So that is where I am seeing DevOps pulling agile into operations, where a couple of years ago it was the exact opposite.
Q: When this is happening, is it the case that one person is most important - that you need a champion to make it happen?
It is important to have champions. What we find now is that in a typical IT organisation about a third of the people understand that and get frustrated by it. That third go out, they attend conferences, they read all about this cool stuff that they can do but they can't because their organisation won't or can't do it. We find that the people that are doing this now and understand that it is all about getting that one third into what is almost a parallel organisation.
That organisation will just do agile projects and that is where Gartner talks about "bi-modal". That means that some of the things you will work on you will know what the problem is and all you have to do is the execution.
In others, you won't know what the problem is but you will know what the solution looks like. In that second set of projects you have to do agile, so you form teams of people who want to do agile to solve those problems. That is our typical advice and we find that it's very effective. From there, you let it grow organically. DevOps is the same.
Q: What do you think is the first and foremost thing an IT manager should consider when implementing a DevOps/agile system?
The first thing to think about is that you can't make everything DevOps tomorrow. Identify the projects that are most non-linear. This is where we start talking about things like 'the lean start-up' where you are doing experiments to figure out what the problem is.
All companies have these areas, so take the most extreme ones and attempt to do these things there.
The other thing we want them to think about is the business side, because you have to do this in partnership with the business. This is another big cultural challenge for a lot of organisations. Just like you pick the developers with the right mind-set - maybe over skill-set - because it is more important that they be agile-oriented rather than that they have worked with this piece of software before. It is the same thing on the business side. You have to pick those projects where the business understands that they have to work with IT differently to get what they need.
The other thing I encourage people with is: don't come up with a roadmap where you are going to be eight percent agile by this date and 10 percent by another date and 25 percent by the end of next year and then we are going to be 75 percent agile. Don't think that because, it's not going to happen that way.
You have to be organic. It is going to be used in pockets and suddenly the mindset of the business with change. People will say, 'Hey, this works better' - and suddenly everybody wants their project to be agile.
Q: What does Gartner predict for agile and DevOps?
My first prediction is that agile becomes the majority way to do software development by 2018. The other is directly related to The Phoenix Project, and it says that by 2020 we are going to look back and say that what IT is going through is exactly what manufacturing went through in the '80s. The adoption of lean and what Toyota went through is exactly what DevOps means to IT. It is going to be just as much of a transformation for it.
Read more:
What is DevOps and why does it matter?
Puppet Labs and Dell work together on management software