For those who think we’re near saturation point for enterprise DevOps adoption, Puppet founder Luke Kanies has news for you: we’re nowhere close.
“The concepts are ubiquitous, as are the job titles,” he concedes. “But the actual practices are still barely present around the market.” Don’t hold your breath for 2018 to be the Year of DevOps, either: “Everyone thinks it’s widely adopted so no one is striving any more, and as a result we’re going to be another decade or two before anything interesting happens.”
That’s right. Ten to 20 years before “anything interesting” actually happens with DevOps. Pretty grim, and it prompts the question: what have we been doing for the last 10 or so years since DevOps burst on the scene? And what is required to propel companies forward so they’re not left watching while their competitors surge past them?
The Web Rich Keep Getting Richer (and Webbier)
DevOps isn’t really about technology. Technology helps, of course, but DevOps is really about cultural change. Things like continuous deployment do require new tech, but more than this they require teams who appreciate why they must use them, and how. As Pivotal’s Andrew Shafer describes it, “The social engineering required to adopt new methods typically dwarfs the technical aspects.”
Such social engineering may be a necessary byproduct of scale. As Mike Loukides correctly observes, “DevOps was the inevitable outcome of building and operating the sites that became the web’s giants. It’s a native in the world of complex distributed systems and the cloud.” At serious scale, it’s simply impossible to do IT (or development) in the old school enterprise fashion. Automation becomes mandatory.
The Googles and Facebooks of the world, therefore, have been ground zero for DevOps adoption, while more traditional enterprises have gone missing. Yes, you can find smatterings of DevOps tucked away in the bowels of this or that Fortune 500 company – by some estimates up to 81 percent of enterprises “do” DevOps – but your odds of finding a large, traditional enterprise with deep experience in DevOps are slim to none.
Search the earnings calls of public corporations and you’ll find the occasional reference to DevOps, but only by software vendors that hope to peddle a magical cure to IT woes. Despite software eating the world, with the attendant need for companies to figure out how to make software development (and ongoing operation thereof) a competitive differentiator, the culture and process of software is stuck in the 90s.
Not that enterprises aren’t trying.
Take Capital One, which has been on the vanguard of open source and public cloud, two trends that dovetail nicely with DevOps. In a 2017 presentation, Mark Andersen, Director of DevOps at Capital One, walked through how the company has approached the cultural transformation DevOps requires. To cut their teeth, the company picked two legacy applications and formed a SWAT team made up of developers, infrastructure, and production support people. The goal wasn’t to automate everything at once, but rather to babystep toward success.
Again, though DevOps is cultural in nature, technology plays a part. As such, Capital One took the project in phases, with the first phase devoted to embracing on-premises configuration management tooling (Chef, in their case). They then moved to the public cloud (AWS), with full infrastructure automation into delivery pipelines. Phase three, where the company currently sits, involves “implementing robust pipelines with increased quality checks and automation,” coupled with pre-approved releases.” This last point is important but often overlooked, as described in Puppet’s 2017 State of DevOps report (PDF): “[P]essure to deploy faster and more often causes lower performers to pay insufficient attention to building in quality.”
This represents huge progress for Capital One, and the SWAT team approach nudged the different groups to learn greater empathy for each other’s roles, reducing friction for future collaboration.
Along the way, the company has learned what the Googles of the earth have long known: on-premises infrastructure is tough to automate. Related, every tool needs an API. Indeed, Andersen insists, even a bad API is better than no API. To move fast, DevOps teams need elastic infrastructure, with the ability to call services rather than hardwire everything together.
Sounds simple, right? Yet virtually no one is doing it.
The Road to IT is Paved with Good DevOps Intentions
It turns out the journey is very, very long, precisely because the cultural metamorphosis is very, very hard. Leading Edge Forum guru Simon Wardley shared with me a chart that details the vast gulf between traditional IT and DevOps:
If this is hard to appreciate, think about cultural shifts that may be closer to home. For those that have grown up in proprietary software, the very idea of open source is bonkers. Give away the crown jewels?!? Madness! Or think about public cloud: if you’ve always bought servers it’s hard to move to a world where you don’t own hardware. Elasticity? What?? Companies used to selling their own software struggle to embrace partner ecosystems to help share that load. And so on.
Do some companies like Capital One break through? Yes. But as Shafer caustically comments, “Everyone can point to examples and data from high performance devops organizations, just like everyone can watch the Olympics, but not everyone is willing to put in the work to get there.”
Getting to DevOps harmony demands hard work, the hardest of work: helping people work together. As Jez Humble, CTO at DevOps Research and Assessment LLC and co-author of “The DevOps Handbook” and “Continuous Delivery,” told Datamation:
“Programmers work in silos and are often happiest writing code. In as much developers measure productivity by writing code, they won’t be happy in this role. You’re going to spend less time coding than if you were a developer full time. A lot of the problems aren’t coding problems. They are problems of procedural implementation, configuration management and poor collaboration. That’s why it’s not for everyone.”
While it may not be for every person, it definitely is for every organization. Yet most won’t make the hard investments absent significant pain, Shafer says:
“Most orgs don’t have the capacity to change behavior just from new information. There often needs to be crisis and pain together with leadership and vision. Without the first, there is no impetus, without the second, there is no direction. Behavior change often faces active resistance. People attach their identity to their tasks or even worse, worry about losing their jobs.”
Just as Equifax’s catastrophic security breach, and the consequent likelihood that Congress will put U.S. executives on the hook for security, may actually make enterprises serious about security so, too, may slow-moving steps toward obsolescence push CEOs to demand change from their CIOs. This begins, however, with the CEO getting out of the rut of believing IT is a cost center. For DevOps to truly gain a foothold, the enterprise must think of IT as a center for innovation and profit.
This, however, is merely the start. DevOps is “an 80 year journey,” Kanies declares, “And we’re fifteen years in. Maybe.” For enterprises slow to get started, this could be comforting. That is, until more nimble competitors get to DevOps first and “eat their world” with software.
In sum, enterprises have the opportunity to choose to get moving with DevOps, or they can be forced to it. One way or another, however, everyone will embrace DevOps in the future…or they won’t be around to see it.
Matt Asay is Head of Developer Ecosystem at Adobe