When DevOps isn't enough: knowing when to shift to Platform Engineering
Before you start architecting your IDP and buying licenses, let’s talk about the "why".
👋 Hi, I’m Thomas. Welcome to a new edition of Beyond Runtime, where I dive into the messy, fascinating world of distributed systems, debugging, AI, and system design. All through the lens of a CTO with 20+ years in the backend trenches.
QUOTE OF THE WEEK:
“ […] don’t try to measure the individual contribution of a unit in a complex adaptive system, because the premise of the question is flawed.” - Dan North, The Worst Programmer I Know
There’s a moment in every growing engineering org when DevOps, despite all the automation, all the culture conversations, all the best intentions, just… stalls.
It’s not that DevOps has failed. It’s that it’s doing exactly what it was designed to do: break down silos between developers and operations, enable faster delivery, and shift responsibility left.
But as your organization scales, that shift starts to weigh more heavily on everyone.
I’ve seen this story repeat itself at startups and enterprises alike:
Infrastructure complexity grows.
Everyone becomes responsible for everything.
Developer productivity tanks because they’re context switching between building features and maintaining pipelines, Kubernetes, and IaC modules they barely understand.
At some point, DevOps needs a platform.
But knowing when to make that shift (and how to do it without making things worse) is where things get interesting.
The hidden cost of “You Build It, You Run It”
DevOps was a massive leap forward when it emerged in the late 2000s. It taught us that development and operations weren’t two separate worlds, and that software could move faster when teams collaborated across responsibilities.
But DevOps doesn’t scale neatly. Once you have dozens of teams, hundreds of services, and thousands of moving parts, the DevOps ideal starts to collapse under its own weight.
By shifting everything left, you end up with developers writing business logic, maintaining Kubernetes clusters, debugging Terraform errors, and configuring Prometheus exporters.
Sure, technically they can do it. But is it the best use of their time?
Eventually, you have to ask: what are we actually optimizing for? Velocity? Autonomy? Maintainability? Because overloading developers with infrastructure responsibility achieves the opposite of what DevOps set out to do: it slows everyone down.
From DevOps to Platform Engineering
That’s where platform engineering comes in: not as a replacement for DevOps, but as its logical continuation. It brings standardization, scalability, and consistency to a landscape DevOps made possible.
Where DevOps encourages teams to build their own workflows, platform engineering consolidates the best of those workflows into internal platforms, so developers aren’t reinventing the wheel every time they spin up a service.
The four signals it’s time to build a platform
So how do you know when DevOps alone is no longer enough? Here are the patterns I watch for:
1. Infrastructure becomes a bottleneck
You know this one. A new service takes a week to deploy. Not because of code, but because of provisioning. Teams copy-paste Terraform from the last project. There’s no consistent monitoring. Everyone sets up alerts their own way (or not at all).
At this point, standardization is a necessity. Platform engineering steps in to create reusable modules, policy enforcement, and automated provisioning. It reduces variance across teams and gives you confidence that your infrastructure works the same everywhere.
2. Security is fragmented and inconsistent
If one team uses Snyk and another uses Trivy, and a third doesn’t scan anything until the pen test… you’re playing security roulette.
DevSecOps principles help, but they often stay siloed within individual teams. Platform engineering enables shared pipelines with built-in security tooling, secrets management, and policy enforcement across the board.
Instead of asking every team to implement best practices, platform engineering bakes those practices in.
3. Developers don’t know what exists
When service discovery is a Slack thread, you have a problem.
In large distributed systems, it’s easy to lose track of what services exist, who owns them, or how to interact with them safely. Developers waste hours reverse-engineering APIs, digging through GitHub, or building redundant functionality.
Platforms like Backstage or Multiplayer solve this by automatically discovering and building a real-time, searchable map of your system. They make your architecture explorable, auditable, and, crucially, understandable.
4. Multi-cloud or Multi-team coordination breaks down
As soon as you’re running across multiple cloud providers or have multiple platform teams, consistency becomes painful. Different IaC practices, different naming conventions, different security rules.
Platform engineering enables cloud-agnostic modules and IDPs that abstract provider-specific details while giving developers a uniform interface.
Final thoughts: it’s not either/or
Platform engineering isn’t a replacement for DevOps. It’s what happens when DevOps grows up.
If DevOps is about breaking silos, platform engineering is about building highways. It gives developers a paved road that lets them move faster, with fewer surprises and fewer distractions. But you have to build the right road, at the right time, for the right motorists.
If your teams are drowning in bespoke infrastructure, if every new service feels like starting from scratch, if your best engineers spend more time managing tools than solving problems, then it might be time to invest in a platform.
💜 This newsletter is sponsored by Multiplayer.app. AI-powered debugging for distributed systems.
I originally wrote about this topic in this deep dive overview:
Read the original for more information about:
Summary of key platform engineering vs DevOps concepts
A brief history
Comparison of approaches
When should organizations introduce platform engineering?
Examples of introducing platform engineering into an organization
How to introduce platform engineering
📚 Interesting Articles & Resources
What is Platform Engineering and how it fits into DevOps and Cloud world - TechWorld with Nana
This video provides a very clear and succinct explanation of how platform engineering is reshaping DevOps and cloud roles. Rather than replacing DevOps, platform engineering introduces Internal Developer Platforms (IDPs) to standardize tools, enforce non-functional requirements, and reduce cognitive load.
How much does AI impact development speed? - Abi Noda
This article summarizes the results of a randomized controlled trial conducted by Google with nearly 100 full-time engineers. It found that AI tools can reduce task completion time by approximately 21% in enterprise settings. Interestingly, neither engineer seniority nor prior frequency of AI tool usage had a significant impact on speed, challenging earlier assumptions about who benefits most from AI assistance.
Kubernetes Emissions Insights: Turning Cloud-Native Green (Without Recycling Pods) - Flavia Paganelli & Jasper Geurtsen
An interesting talk presented at FOSDEM in February (I’m still catching up with my to-be-read and to-be-watched list!). It introduces Kubernetes Emissions Insights, an open‑source tool that estimates the carbon footprint of your cloud-native workloads using data from Kepler, Electricity Maps, and Boavizta. It shows how developers can make Kubernetes environments greener (without rewriting pods) alongside insights from CNCF’s Green Reviews initiative, demonstrating practical ways to monitor and reduce cloud emissions.