The State of DevOps

If the portmanteau DevOps doesn’t mean anything to you, you might want to skip ahead to the next blog post. However, if it does (and it should), you’ll want to read on.

After recently attending the DevOps Enterprise Summit (DOES), I am struck by several key observations about the state of what has become the seminal movement in technology. So seminal in fact, that Gartner has projected that 25% of Global 2000 organizations will be leveraging DevOps patterns in their organizations in 2016.

Defining DevOps

Let’s start with the name. DevOps is really shorthand, and nothing more, for a lean approach to software delivery that leverages lessons learned in manufacturing. As it turns out, the same problems that plague assembly lines and automobile factories also turn up in software companies. And, with the advent of the Internet Age, every company is a software company, whether they want to be or not. Companies like Lego and Target made big impressions with their DevOps transformation stories.

The essence of the problem DevOps is trying to solve is that silos make delivering products, and well, everything more difficult due to collisions of opposing process, culture, and technology. Having a streamlined value delivery system means bottlenecks are minimized at all cost. Development and Operations are two such silos that have to work very closely in order to deliver value to customers. What DevOps evangelists will say is that it’s not just Dev and Ops, it’s Everybody and Everybody involved in the process, and the term DevOps is simply a symbolic representation of the underlying struggles that pepper large technology organizations.

Once you understand what DevOps is trying to accomplish, it starts to make sense why the industry is flooded with misconceptions, profiteers, and hype. It’s essentially a rough cut at the “theory of everything” for technology. It seeks to encapsulate everything necessary to have and maintain high-velocity product delivery, flow, cultural harmony, and cutting edge technology underpinning it all. That’s an awfully big problem to solve, and that bewilderment showed up prominently at DOES, alongside the great successes.

What’s in a Name?

I was particularly struck by Michael Buesche, AVP of IT Operational Excellence at USAA, when he said that internal stakeholders were so disenchanted with the use of the word DevOps that they had to rebrand it “Rapid Release” instead. He’s not the only one either. Many large companies have chosen to downplay the name in favor of quietly implementing some of the underlying patterns such as continuous integration of software and extensive automation. In some ways, this feels like trying to hold back the tide because the fastest-growing job title in technology has “DevOps” somewhere in it, including here at SendGrid.

To DevOps purists, and this was a view reflected at the conference, “it’s not a team it’s a journey.” This is true, but organizationally, DevOps represents a unified delivery team that spans the entire deployment spectrum. That’s a vision that any CEO worth their salt is going to stand behind.

Adopting DevOps in the Enterprise

I understand the schism in the industry around adopting DevOps into the organization, as I have struggled with it myself managing prior operations groups. There are many traps and pitfalls that well-meaning managers and executives can fall into when implementing it. In the end, however, I had the “Aha!” moment and realized that DevOps was essentially trying to pick up where the Agile Software Revolution left off without really even knowing it. In that light, it feels a lot less like a passing fad and more like a continuation of a proven methodology that completes the circuit in an agile transformation at scale. That’s part of why I am writing a book on Agile Operations, so DevOps has a set of well-known patterns to begin with, especially in larger organizations.

It’s my goal for SendGrid to be a model for other operations groups around the world, as we tackle the same sorts of issues that every technology group struggles with. I’ll be writing more about DevOps at SendGrid, as well as sharing some of the great things we have learned through operations at scale.