· Reflection

Did platform engineering kill DevOps?

Two or three years ago, every time I scrolled through job offers in my field, I noticed the same thing: platform engineers wanted everywhere, and DevOps engineers, well, not so much anymore. At least not as much as I remembered.

Part of it is just relabeling, to be fair. Employers post “DevOps engineer” for whoever handles automation: continuous integration and continuous delivery (CI/CD), infrastructure as code, sometimes the infrastructure itself, or something as vague as “the cloud”. Candidates, for their part, adapt their profiles to whatever is in demand. But beyond the labels, words have a meaning, and that meaning is what I want to talk about.

So, did platform engineering kill DevOps? My answer was no, and it still is. I just never took the time to write it down, until now. In this article, I look at what actually died, what a platform really is, and why the two ideas end up working together. Kubernetes shows up as an illustration along the way, but the reasoning applies to any platform you build for other engineers.

So what actually died?

First, let’s agree on what DevOps means. I will stick to the plainest version, nothing groundbreaking: building your code, deploying it and running it. The whole thing. You write it, you ship it, and when it breaks at 3 a.m., your phone rings (put like that, it does not sound like a great deal, I know).

That idea is older than the job title. Werner Vogels, Amazon’s CTO, was already describing it in 2006 as you build it, you run it. It says who owns what. What it was never supposed to be is a job title.

The industry made it one anyway, and very often a whole team sitting between developers and operations. I am far from the first one to point out the problem. Back in 2012, Jez Humble was already explaining that putting a DevOps team between dev and ops just adds another layer of indirection.

So if platform engineering had to have killed something, it would be the DevOps engineer as a middleman, a setup that had already been criticized for years. The idea underneath (DevOps) is doing just fine.

Everybody builds platforms now

Around the same time, something else happened: everybody started building platforms. The word itself was not new, but suddenly it was everywhere, on slides, in team names, in job titles. A shared Terraform repository became a platform. A Kubernetes cluster with three namespaces became a platform. A wiki page listing the approved tools? You guessed it.

Why then, though? My take is that the cloud made it possible, with some lag. Building an internal platform used to be something only the largest tech companies could afford. Once the cloud, then Kubernetes and infrastructure as code (IaC), turned the underlying building blocks into APIs, a handful of engineers could build one for their own company. And the cloud made the need obvious at the same time: the more services you can reach, the more complexity there is to hide from people who just want to ship an application.

The word is fine. The problem is that it spread long before anybody agreed on what it meant. The definition I find most useful comes from Evan Bottcher, in an article published in 2018:

A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.

The part that matters most to me is the product one: a platform is a product. It has users, a roadmap, someone supporting it and someone operating it. If nobody answers when it breaks, what you have is a shared folder with ambitions.

DevOps, twice

Put the two definitions side by side and the question from the title answers itself. DevOps says who owns what they build. Platform engineering says what you build for other engineers. They were never competing for the same seat.

In practice, you get two loops running at the same time.

The inner loop belongs to the platform team. They build the platform, deploy it and run it: versions, a roadmap, a support channel, service levels, and yes, a pager. When the platform breaks at 3 a.m., their phone rings.

The outer loop belongs to the platform’s users. They build their application on top of the platform, deploy it and run it. When their application breaks at 3 a.m., their phone rings.

Take Kubernetes. The platform team operates the clusters, the deployment pipeline and whatever templates they offer on top. An application team uses all of that to ship its service, and owns that service in production. Same model on both sides, with a line between them.

What makes the outer loop sustainable is abstraction, and behind it there is a skills problem. The underlying platforms are often too complex for everyone to master. Without abstraction, “you build it, you run it” asks every developer to know networking, IAM, container orchestration and observability on top of their own code. Training every one of them to become a Kubernetes expert does not scale, and it is expensive.

Companies found two answers to that problem. The first one was to hire someone to do it for them, and I suspect that is a big part of how the DevOps middleman was born. The second one is to build a layer: a platform team that knows Kubernetes in depth, and an abstraction on top of it so that application teams do not have to. That second answer also saves money. You still pay for scarce expertise, but only in one small team, and everybody else can hire engineers who focus on their own domain without being Kubernetes wizards.

Why not stick with the first answer, then? On paper, a DevOps team acting as a middleman works. In practice, that team spends its days executing other people’s requests, with little say in what gets built or why. That is hard to find meaningful for long, and the problem lies in the setup, which gives the team nothing of its own. The team can lose its sense of purpose, and high turnover tends to follow.

A team building a self-serving platform is in a different position. It owns a product, it has users, and it decides how that product evolves.

Platform engineering is what makes “you build it, you run it” hold at scale. That is pretty much the opposite of killing DevOps.

And I am not saying this against the platform engineering crowd. Plenty of people in that community say the same thing: DevOps is alive, and platform engineering is how you keep it sustainable once you have more than a handful of teams.

Conclusion

Platform engineering did not kill DevOps. What faded is the DevOps engineer as a middleman between developers and operations, a role that was criticized long before platforms became fashionable. The model itself, you build it, you run it, is alive and now runs twice: once on the platform, once on what runs on top of it.

When does this not apply? If you have one team and one application, there is no platform to build and no second loop to run. And a “platform” that nobody operates does not count, whatever its README says.

Which leaves an obvious question: if two loops live side by side, where exactly does the line between them fall? That depends on how much your platform abstracts, and that is where things get expensive.

To go further