Trending Articles
Trending Topics
Trending
This article is part of our Opinions section, where we invite industry professionals to share their views on the most pressing technology questions of our time.
DevOps is dead, or at least dying. Though it looked great on paper when we came up with it, in practice, DevOps has proven to be unsustainable, bringing more chaos rather than order. Why was this, though, and how can its successor, platform engineering, learn from its mistakes?
When DevOps came into being, it seemed like a great idea, with teams encouraged to choose the best tools for the job. Naturally, this led to an explosion in tooling and the massive rise in popularity of Kubernetes, Terraform, GitOps engines, custom pipelines, and other solutions that have become our stock-in-trade.
However, this approach has the built-in expectation that each team will design, build, and maintain end-to-end delivery stacks. This in turn leads to each team creating its own miniature platform. This works great in large, mature organisations, but isn’t feasible in more average organisations.
This is because in large organisations, each team has somebody who handles things like security or infrastructure. In smaller teams, though, many developers are forced to take on part-time roles as SREs, infra engineers, and security analysts. This, coupled with a rise in complexity associated with using the new tools, leads to cognitive overload and burnout among many teams.
The result is that teams perform less well than they can, with inconsistent results, higher operational risk, and the associated rising costs. All of which could be prevented by simply seeing whether DevOps was the right fit for an organisation before implementing it.
The issues with DevOps don’t necessarily stem from decentralisation. In fact, decentralisation is very much a good thing that lets teams get on with what they need to do, without needing to worry about a higher hand. The issue is more that it should be seen as a philosophy rather than a practical way to handle day-to-day tasks. For that, you should probably look elsewhere.
This is where platform engineering comes in. It’s a practical approach that lets teams keep their autonomous nature, but increases coherence – same independence, but far less chaos. This is achieved through the IDP, or Internal Developer Platform.
An IDP is a gateway used by an organisation that replaces the plethora of tools advocated by DevOps. It offers self-service provisioning, standardised pipelines, and golden paths, but without the intricacy of cloud-native complexity.
In a way, the platform acts like the product, with users, documentation, support, and a roadmap of its own. By stripping away Kubernetes and other ecosystems and embedding them in the IDP, you take away much of the complexity of daily work for developers. This lets them get on with their job, without worrying about how to make things work.
At the same time, using an IDP lets you worry a lot less about compliance frameworks, with NIS2 being a much-dreaded example. Instead of each team worrying about this individually, you can let automated workflows handle things like security, compliance, and architectural policies. Devs don’t need to be experts in infrastructure, compliance, and security; they need to focus on building code.
Platform engineering isn’t some intellectual exercise, either: it’s already changing organisations the world over, with some impressive results.
A widely cited example comes from Capital One, one of the earliest large enterprises to embrace cloud-native development at scale. As the number of teams and services exploded, the bank faced mounting operational fragmentation: inconsistent pipelines, duplicated tooling, and rising cognitive load on development teams.
To counter this, Capital One built an internal engineering platform that provided enterprise-wide golden paths, standardised CI/CD workflows, and self-service provisioning for common application types. Crucially, the platform embedded security controls, compliance policies, and architectural guardrails directly into the developer workflow—automatically, rather than as after-the-fact checks.
The outcome was a dramatic increase in delivery consistency and a significant reduction in time spent wrestling with infrastructure. Engineers could ship features faster, while the organisation improved auditability and reduced operational risk across thousands of services.
Airbnb’s story is similar: the company’s development was badly fragmented, and it struggled with hundreds of microservices, leading to inconsistent builds and deployment processes. Their platform engineering team introduced Paved Roads, which curated and standardised workflows.
These allowed teams to build and deploy services without navigating infrastructure themselves, thus reducing operational overhead and cutting service creation from weeks to hours.
Netherlands-based ING Bank was an early adopter of DevOps, and one of the first to run into its limitations. Many of the multinational bank’s divisions started to maintain divergent practices, leading to fragmentation and chaos.
To fix this, ING created a centralised Engineering Platform Tribe to standardise pipelines, infrastructure patterns, and security guardrails. This shift improved release speed, strengthened auditability, and significantly simplified compliance in a regulated environment.
DevOps promised autonomy, and it has succeeded in that. However, the many organisational issues that come with it are not within its power to fix. Platform engineering provides the operational discipline and consistency to make that autonomy sustainable.
It’s not some abstract fix, either: many organisations, ranging from the small to the multinational behemoths, have implemented IDPs to make better products faster, without security hassle or infrastructural headaches.
As important as the philosophy of DevOps has been, it’s time to set its practical recommendations aside and use something that actually gets the job done.
