The Commodification of DevOps

"We are uncovering better ways of developing software by doing it and helping others do it."

The Agile Manifesto, 2001.

It's been quipped more than once that most amazing Silicon Valley innovations are simply a bunch of nerds poorly recreating a service that already exists, but with an app. While I find this to be in some ways a truism (after all, there is nothing new under the sun), it's a fairly trite observation. What's far more interesting is how the organizations that build and deliver these 'innovations' themselves develop, and the process of that development is especially interesting due to the pressure-cooker of free money and labor elasticity that has characterized the 'startup economy' over the past twenty years or so. What's any of this have to do with DevOps, you may ask? Simply this -- DevOps is a reaction to the commodification of Agile, and the rise of SRE is a reaction to the commodification of DevOps. To reduce the thesis further, many of the trends you see in software development and delivery can be understood as a cyclical reaction to anarchists running headlong into the invisible backhand of the free market.

Let's start with a brief overview of the idea of a commodity, commoditization, and commodification. A commodity, in an economic sense, is some highly fungible good or service -- like wheat, or salt. They're raw materials, basically. Commoditization is the process by which an economic market for a particular good transforms into a commodity market. One example of this you may be familiar with is the concept of generic pharmaceuticals due to patent expiry -- if enough people can make the same thing, then the market for that thing will change. Commodification is a cultural critique of the above process happening to something that it shouldn't happen to -- "microprocessors are commoditized, love is commodified". Marx's critiques broaden the definition of commodity to encompass any good or service produced by human labor which is then offered for sale, in an attempt to quantify the general economic value of any particular good through the labor theory of value (LTV), which in short states that the economic value of any commodity is determined by the amount of 'socially necessary labor' required to create it.

Please note that I am not an economist and these explanations are overly simplified.

What does this have to do with developing software? There's quite a few load-bearing metaphors for the act of software development as a team or organization, but my preferred one is the idea of a kitchen. Cooking is a blend of science and art, cooking for a dinner service is different than cooking for yourself, and it requires a high level of implied and explicit communication. The dynamics of a high-performing kitchen are eerily similar to a high-performing development team in both positive and negative ways. There's a certain grace and elegance to the actual moment-to-moment functioning of a kitchen during dinner service when everything is working right, which you can also see during well-functioning incident response on a development team. That said, there's also high levels of burnout and stress, poor coping mechanisms outside of work with alcohol or drugs, and internecine interpersonal relationships. I believe this is why a non-zero amount of techies liked the Bravo show Vanderpump Rules (before it got lame because everyone in it got successful), game recognize game.

With that said, how does this blend with the idea of DevOps as a commodity? We need to go back to where we started in this piece -- by talking about Agile, and the LTV. Remember how I mentioned 'socially necessary labor' earlier? Well, how do you quantify that for software? What's the actual cost of fixing a bug, or writing a line of code? The fixed costs are fairly straightforward -- a computer, a monitor, etc. -- but if you assume that any software built as a team is going to provide a fairly infinite amount of bugs and improvements, the actual cost needs to be attributed elsewhere. If you're a manager, this becomes a fairly simple calculation of salary, time, and revenue -- fix the bugs that impact revenue the most, implement the features that impact revenue the most, and so on. It's generally agreed that Agile is a reaction to this sort of top-down management of "work", but I would go a little further than that; Agile is a reaction to the idea of who gets to determine what's 'socially necessary'.

Agile, fundamentally, was a power struggle between the 'haves' and the 'have nots' in the knowledge economy -- and the workers won, for a time. Management can want whatever management wants, but they can't provide the necessary labor required to actually make the computer go in a way that produces a reliable commodity that has market value. Imagine our theoretical high-performing kitchen; If the chefs get together and figure out a way to work that makes them happier than the way the owner wants, the owner may certainly decide to fire them and hire new cooks, but at the potential cost of revenue, especially if those new cooks don't have the talent or ability of the prior team.

Historically, the 'haves' are rather unwilling to cede power to the 'have nots', but they are pretty good at figuring out what to co-opt. Agile has been, quite definitively, co-opted and commodified.

This image is in and of itself almost a meme at this point, the Deloitte 'Agile Landscape'. It's a confusing mess -- this post does a pretty good summary of everything that's wrong with it -- that I surmise exists mostly because people who work for Deloitte have little better to do than create slide decks that make you feel like they know what they're talking about. The very concept of 'agile' has been reduced to a credential, something you can get certified in. The moment you can pay someone to tell you that you're a 'Disciplined Agile Senior Scrum Master' I would suggest that your idea is no longer a radical one, and that's an important part of the commoditization in software development. Looking back to 2001, Agile was genuinely a radical and anarchist experiment in work! "Individuals and interactions over processes and tools" is an extremely radical concept given the popularity of scientific management in the modern capitalist enterprise.

If we think of Agile as a radical statement of culture and values, then it follows that DevOps is primarily a response to the commodification of Agile. Indeed, go read some of the notes from early DevOpsDays. As Agile practitioners lost their ability to drive change in organizations through the commodification of the practice, something new was needed. In these early DevOpsDays we see, again, specific reactions to this process. "DevOps is not a certification, a role, a set of tools, a prescriptive process" (some readers may begin their cynical chuckling at this point). Without getting into the weeds too much, DevOps worked in the same way Agile did, as a way for individuals who didn't have a lot of power to claim some back. Agile and DevOps both were ultimately about workers who weren't "in the room where it happened" building a new room around them and forcing concessions by changing processes, policies, and culture.

Both DevOps and Agile were, fundamentally, about changing the structural power dynamics of an organization. The benefits to software quality and delivery are incidental to the equation. Effectively, you make better software when the people building the software are the ones running the organization that builds the software.

So, what happened to DevOps? It might not surprise you that it also has been credentialized. The commodification of DevOps has been far more rapid and drastic than Agile, I would say -- while Agile has mostly been turned into a product that you buy from rapacious consultants, DevOps is turning into an entire suite of literal products and services that promise to use artificial intelligence and machine learning to eliminate the human factor in DevOps entirely. You can find any number of tools, services, books, training courses, and so forth that sell you 'DevOps' or parts of it. Hell, there's about 500 people in the world whose entire job it is to fly to other parts of the world and tell you how to do DevOps (or how not to do DevOps); I'm one of them, I guess? There's a decent chance that if you're reading this, you're one of them too.

If there's one thing you can count on in cycles, it's that they tend to happen faster the more times they happen. With that in mind, is the rise of Site Reliability Engineering as a response to DevOps a terrible surprise? Originally developed at Google (and, quite honestly, you can tell), SRE can be thought of as a reaction to the commodification of DevOps and Agile but in an increasingly specific way; This makes sense, because we're running out of broad and obvious things to write manifestos about. Instead of talking about large cultural changes, SRE focuses on smaller, more discrete things like "if something breaks, don't pile on the dude who pushed the bad change" and "you should use math to calculate interesting things about your system". Is SRE going to be subject to the same commodification and de-fanging that Agile and DevOps have been? That's still an open question -- certainly, 2020 has seen the launch of several open source and commercial products that tie in directly to some of the trends espoused by SRE; things like observability, blameless postmortems, SLOs, and so forth.

What will doom SRE to the fate of Agile and DevOps, though, is less its scope and more the why of SRE. Agile, DevOps, and SRE all share one thing in common -- they all attempt to reshape the power dynamics of a workplace, of a business. They're all attempting to ask what is 'socially necessary labor', and what the actual value of a widget is. It works, for a time, in the white-hot inferno of startup economics because money is free, and talent isn't -- but it's not a steady-state system. Revolutionaries have a tendency to get managed out, laid off, promoted and defanged, or to leave on their own volition. Perhaps this is just the natural state of trying to be a revolutionary under startup capitalism -- we can reinvent the past hundred years or so of labor theory every few months, but at the end of the day, the investors will get their returns one way or another.

So, what's the answer, what's the solution? I don't think there is one, at least, not necessarily. I'd caution readers about drawing any grand conclusions from what I've said here -- but I do think it's a useful analysis. Beware anyone who comes trying to sell you these commodities, however -- you really can't buy SRE, Agile, DevOps, or much of anything else when it comes down to how you do things. Ultimately, it's that how -- who gets to make decisions, how those decisions get made -- that determines more than you can ever really know. Maybe you really just need to unionize?