When acolytes explain the DevOps movement to the uninitiated, they usually run into a chicken and egg line of questioning. What is DevOps, really? Is it a culture? Is it a pattern of processes? Or is it a technology? What comes first?
The ratios of the perceived importance of each of those elements may shift depending on who you talk to in the DevOps community. But the inevitable answer to these questions is usually that DevOps depends on at least a little of all of them, but probably on culture above all else.
“I think it’s first and foremost cultural. The development team is a tribe. So is operations. They have norms. They have things they value. They have things that they reward and admonish,” says Josh Corman, chief technology officer for Sonatype, a component lifecycle management firm. “Developers are incentivized to cause change. And ops people are incentivized to prevent change, to promote stability. So they were natural enemies. And when they work it out and align to each other’s tools and incentives, they’re able to go faster.”
Therein lie the historical roots of DevOps, agrees Andrew Storms, senior director of DevOps at cloud security firm CloudPassage, who explains that it is an answer to the blame game that inevitably occurs in the old model.
“I think that existing corporations or companies or groups are probably doing DevOps in response to existing pain,” he says, explaining that in previous non-DevOps shops he worked at, it was inevitable that development would write a piece of code, throw it over the fence and let ops catch the heat when trouble brewed. “The question is, why is the person at the end of the train always feeling the pain for something that originated at the beginning of the train? To me, DevOps says, ‘There is no train.’ There’s no more division of who’s in trouble for anything. Everybody is on the same darned team.”
It’s for this very reason that Jez Humble, a principal for the consultancy ThoughtWorks and co-author of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, says that the fundamental ingredient to successful DevOps is trust.
“You need to trust each other. Developers can’t just assume the ops people are all dumb and don’t know anything about code or are just command line monkeys. And the ops people can’t assume the developers don’t know anything about how systems work in real life,” he says. “These assumptions make it all a big finger-pointing exercise.”
A lack of trust is the underlying roadblock to better teamwork between dev and ops, but it can be difficult to achieve within enterprises.
“In small organizations people trust each other because they can see each other and work with each other and must learn to trust to get anything done,” he says. “But as organizations scale you lose that human contact.”
It’s replaced instead with brittle and bureaucratic processes that only feed into those distinct walls between each tribe. However, as organizations feel the pain that’s inflicted by those bureaucracies that have evolved so far in IT and by the walls thrown up as a result, they face a choice. Engender that trust and a culture that allows dev and ops to simplify processes and tear down the walls, or face further roadblocks that will hurt the business.
From there, it is a matter of establishing behavioral and process patterns that are a hallmark of DevOps cooperation.
“I think ‘patterns’ is the right word for it. People get hung up on this textbook or technical definition of DevOps. And while there are certain common processes and things like Kanban boards and Scrums, and sometimes it’s a hybrid of Agile, sometimes not that ,” Corman says, “what matters the most is an attitude to fail fast and iterate, to continuously look for ways to increase flow, to automate, instrument and find and root out weakness. And to be responsive to new ideas of the business, or new ideas of your install base, or new market pressure.”
According to Corman, the beauty of DevOps is that it’s a ‘jump ball’ for IT, so there are no set processes that make or break whether a shop is DevOps or not.
“It’s in a state of flux, and the cement hasn’t dried. It’s a singular opportunity to redefine the way we engage with the business and drive value, the likes of which we will not see again for 30 years,” he says. “It’s very, very rare.”
And while few within the DevOps community would say it is defined by technology, it certainly is enabled by it.
“To me it is more a cultural shift than a tool shift, but that tools shift presents a huge change in the way IT runs,” Storms says, explaining that instrumentation and orchestration tools like Puppet and Chef makes it possible to achieve continuous improvement and fast iterations. “So does it come about through the cultural change or the technical change? I think, actually, neither. I think it happens at the same time. That’s the force multiplier, that two plus two equals five kind of thing.”
But like tectonic shifts, changes in IT happen sometimes all of a sudden, but mostly in increments.
“One part of it is focusing on what we can do every day to make things a little better for everybody. You have to proceed incrementally and accept that it’s going to take time,” Humble says. “You can’t say, ‘Well, we’re going to adopt Agile now across the whole organization—go!’ There has to be enthusiasm from the people on the ground to do this stuff and then you have to work together though a process of experimentation and trial and error to work out how to make it work in practice, probably with a small group of people initially.”
Even with that force multiplier, Storms says, you’ll still see positive steps forward by establishing an element of DevOps one at a time.
“Even if you’re in a difficult situation where you can’t have the force multiplier of culture and technology changes at the same time, just one or the other is still going to be a big win,” he says. “Let’s say you just took the one piece of ‘Let’s move our dev and ops teams together and make them be friends,’ you don’t necessarily have to orchestrate and instrument like crazy to win. But you can also do the opposite and just picked the orchestration piece and say, ‘Hey, ops people, stop doing things by hand.’ You send them to Chef conferences and make them learn Ruby and guess what? Their skill sets just went through the roof.”
