What is DevOps anyway?

There are two sides to the DevOps story. Here CloudBees CEO Sacha Labourey gives the Dev perspective

For most of us DevOps is quite a new term. As such, beyond the obvious clue in the name, inevitably there is some confusion about what it actually means. Is it merely a collective rebadging of practices such as agile and continuous improvement or is it really something new? We asked Sacha Labourey, CEO and founder of continuous delivery software provider CloudBees, to explain some of the concepts behind DevOps.

Why now?

Increasingly companies are defined by the intelligence built into their products by software. Take traditional car manufacturers who, Labourey says, are looking nervously at innovators like Tesla and Google and wondering what the future will hold for them.

"Already when people buy a car they are thinking 'what is the integration with my phone and the other systems I have?' And if you look forward five or 10 years and think about self-driving cars, the amount of IT in these will be huge. I suspect I'll be extremely interested in knowing who is the producer of the software that's going to drive my car. That's going to be more important than the number of cylinders or the horsepower."

So software is already central to adding value and differentiating all sorts of products from the competition and in the future it will become even more important. This means that software development, including testing on all the environments on which it is to run, must happen at the speed of business rather than at a pace dictated by IT - which has so often become a byword for "late".

"IT is a remote team that is given a project by the business. Twelve or 18 months later they check it and say: 'does it work or not?'," Labourey (pictured below) explains.

Even if it works, in that 12 or 18 months the market may well have moved on so that all the IP and money invested will have been wasted. So why does it take so long?

Part of the problem is that as well as coders, commercial software development requires IT operations staff, testers, QAs and others to get the code up and running on web servers, app servers and whatever other platforms it needs to work on. They need to put the code through its paces, testing it for security and quality before it can be released. And the strange thing is, these parties often don't speak to each other until the code is handed over, at which point many of the issues that cause delays are already baked in.

The premise behind DevOps is almost laughably simple. Software development and IT operations are interdependent, neither can function without the other. So instead of having the two sides working on a large project separately, get them all in the same room from the start. With an approach focused on frequent releases the project can be broken down into chunks, with teams working on specific deliverables. These teams will be more inclined to communicate and overcome their differences, thus leading to a quicker delivery of a better product. That's it.

Seems sensible, so what's stopping it?

"Common sense says you should do it this way," says Labourey. "It's a bit like what happened in the motor industry about 40 years ago. Toyota and those other Japanese companies were working with lean processes and so on. When you hear about that today it makes sense, you wouldn't build a factory differently. But 40 years ago that was crazy stuff."

The fact that "Devs" and "Ops" work in different ways and are often very different personality types is a cause of friction, Labourey says.

"Developers are always bent on innovation and creating new things, whereas Ops people are bent towards safety and systems always being on - something that works rather than something that is cool and doesn't work. So they have different agendas and they might have different time frames too. The development team could be working on a weekly release basis but if IT ops only takes new orders on a quarterly basis then why should they bother?"

So it's all IT Ops' fault for being box-ticking jobsworths?

Not at all, says Labourey. Developers often prioritise their own pet projects with little thought about how they will fit into the bigger picture and they need to take heed of the new reality, as happened decades ago with Toyota's workforce.

"As software engineers we've been spoiled kids with plenty of time to work on our 'cars' one by one and now it's time to grow up and produce a factory to create software value."

That said, however, DevOps does tend to meet with most resistance from the Ops side as this is where the change is biggest.

"Suddenly we ask those guys 'look, you know what? What you do works pretty well, but let's all jump into the unknown with this new project called continuous delivery' and that all seems a bit of foolishness," Labourey says, adding that change can be uncomfortable for everyone at first.

"I think the silo approach is collectively comfortable because you have a well-defined hierarchy within the organisation. So even if it's frustrating for business to push an idea to IT and have it come back nine months later, it's also sort of comfortable. If it doesn't work was it because IT screwed up or was it because the business made the wrong assumptions? Who can say? Everybody can hide and blame the other side."

As such the DevOps approach can leave people feeling rather exposed, he goes on.

"If you start working in a small team with developers, IT ops, marketers, business leaders.. everybody in the same room saying 'okay this is what we want to solve' you start putting your opinion on the line in front of everybody .. so it's a much more intense way of working and there is no hierarchy .. that's not comfortable for everybody."

So, you drag spoiled arty-farty developers and surly utilitarian ops guys away from their comfort zones, shove them in a room and tell them to talk to each other and to take responsibility for their actions rather than blaming the other side. How can that possibly reduce friction?

The proof of this particular pudding is all in the eating, Labourey says, so it's vital to get off to a good start.

"It's important to start with non-critical projects, proofs of concept, easy projects to really start building a culture that demonstrates that this option is better at all levels."

Automation, automation, automation

So far from being about slapped wrists and enforced comradeship, the answer is to foster better communication by getting stuck straight into a quick-win project that will make everyone see the benefit of working together. Key to this is a focus on automating repetitive tasks on both sides of the Dev-Ops equation, allowing everyone to work on high value (and hopefully more interesting) activities.

Automating and orchestrating tasks in the software delivery pipeline is where the tools come in. On the Ops side you have tools like Chef and Puppet, which enable the automation of manual tasks by provisioning infrastructure as code. Recent developments such as software-defined networking and storage and converged infrastructure also fit in well with this principle. On the Dev side there is Jenkins, the open-source project used by CloudBees for orchestrating and automating the continuous delivery of software.

An important feature of DevOps, continuous delivery (CD) is a subset of the agile development methodology that has the goal of developing software in a such a way that the code is always ready for release - whether you choose to release it or not. This is achieved via automated testing and continuous integration and allows updates and bug fixes to be pushed rapidly and automatically to customers, as Labourey explains.

"The objective of CD is for software always to be in a release-ready stage. So if you have a mobile application in the app store, and if a security issue comes up, you fix it, you wait at the end of the pipeline 'til your new binary is ready and boom - you can decide to pull the trigger."

At the extreme end of CD you have continuous deployment: "That's what Facebook does typically. It's continuous delivery when you actually deploy the thing in production."

OK, so CD is a subset of agile. Is agile a necessary requirement for DevOps?

"Agile is a development methodology, DevOps is about improving the flow and the relationship between Dev and Ops. They are compatible. In theory you could manage to do each without the other, but agile would fit extremely naturally in a DevOps type of organisation, which itself is a great way to achieve continuous delivery," says Labourey.

The DevOps adoption cycle

Labourey says the "tools" part of DevOps is just 30-40 per cent of the overall picture. The rest is about culture and process, which is why it can take a while for changes to work their way through an organisation. Cloud platforms can help with collaboration, but they are not a necessity, he claims, with a wide range of possible approaches.

"DevOps doesn't happen in a single step, it is an iterative process, starting with small experimentations," Labourey says.

"I'd say that it starts with having a champion and a quick-wins project. Then it typically gets expanded to nearby quick-wins projects, maybe less quick than the first one, which require education, cross-functional skills and some limited budget. Once the proof points have been assembled, this is where you can build a clear business case, build a budget, present it to management and get backing from the exec team."

Not all projects will be amenable to a DevOps approach, Labourey says, but as an iterative methodology that emphasises quick results adopters should not have to wait too long for demonstrable results.

"[The time needed to propagate DevOps throughout a large organisation] all depends on the DNA of the company and it might not be a high priority to convert all projects as some are pretty static and might not provide a great ROI. But I would say that five years is probably not unreasonable for a large company, but benefits will appear much before the transition is complete."

Sacha Labourey is coming at DevOps from the Dev side. The view from Ops may be different. Do you agree with his thoughts on what DevOps means and how to approach it? You can leave your comments below. In addition, why not attend Computing 's DevOps Summit in London on 8 July? It's free for most delegates. Click here to find out more.