Beyond IaC: Why Platform Engineering Is the Next Evolution

Infrastructure as code isn’t new. The lineage stretches back to Unix config scripting in the 1970s, picks up momentum with virtualization in the early 2000s, and takes its modern shape with CloudFormation in 2011, followed by Terraform, Ansible, Pulumi, and the rest. By the time most organizations were seriously adopting it, the tooling was already mature. What’s still evolving is what happens after IaC, once teams have written their first few modules, scaled them across products, and started running into the limits of the model.

That next step is platform engineering. And for teams that have already made the investment in IaC, it’s less a pivot than a natural extension: applying the same principles of codifying standardization, versioning, and automation to the rest of the business ecosystem that surrounds infrastructure (CI pipelines, feature flagging, observability tooling, developer portals, governance controls, and cost guardrails). These are the parts of the developer experience that IaC alone was never going to solve.

Terraform is deceptively easy. You can pick it up over a weekend and start provisioning cloud resources within hours. On a single project, with a small team, it feels like a win.

The interesting problems start when you’re onto your second, third, or fourth project. The team has grown. The org has restructured. Teams have diverged in how they model the same primitives because there are a multitude of ways to configure anything in AWS, and no two engineers will pick the same one. What began as a clean set of modules is now a tangled mess of inconsistent conventions, half-migrated anti-patterns, and infrastructure that nobody wants to touch.

Platform engineering doesn’t make that complexity disappear. You still have to write well-structured IaC. But it does change the frame. Instead of thinking about infrastructure in isolation, you start treating the platform as the thing being engineered. Most of the real pain in a mature IaC estate is not the IaC, it’s the friction between well-structured IaC and the parts of the business that aren’t configured as code and aren’t as well structured: the ticketing systems, the approval flows, the observability stack, the internal tools that each team wires up differently.

Platform engineering is the discipline of closing that gap.

A common framing in the industry is that DevOps is dead and platform engineering is taking over, but that’s an overstatement. Although the two disciplines overlap, they aren’t interchangeable, and large organizations will often run both.

DevOps is about the interface between development and operations: how software is built, shipped, and operated in production. It’s primarily a set of practices and a cultural orientation. Platform engineering sits a level below that. It’s the tooling, the integrations, the self-service surfaces that make those practices executable at scale. In smaller companies, the same people wear both hats. In larger ones, the two roles coexist and complement each other.

The benefits, where platform engineering is done well, are measurable. Google’s DORA report and Harness’s State of Developer Experience research both consistently show improved developer productivity and stronger organizational performance at companies with a functioning platform team. Most organizations of any real size are already running some flavor of developer platform. The question is whether they’re running it deliberately, or whether it emerged by accident.

Platform teams shouldn’t be treated as fundamentally different from product teams. Their customers are internal, but the dynamics are familiar: You’re building something for users, you need to understand their workflows, and you’ll be judged on whether you make their lives measurably better.

The internal-customer dynamic has its own quirks. Feedback cycles are fast, which is good. But your customers also know exactly how your platform works, so they can see the dirty secrets, and they know precisely how to break it. That visibility is healthy in the long run, but it puts pressure on platform teams to be disciplined about what they ship.

The failure modes mostly mirror those of product teams: unclear ownership, building the wrong thing, scope creep, shipping abstractions that don’t actually match how users work. The distinguishing feature is that platforms touch everything, so the cost of getting it wrong compounds.

If you’re starting a platform effort from zero, the single most useful discipline is to measure before you build.

Platform is a broad topic. Everything is potentially valuable, and quantifying value inside a platform is notoriously hard. The trap is that a new platform team, handed the remit of “improve developer experience,” tries to improve everything at once and drowns in the complexity. Pick one metric that matters to the business and that you can measure automatically. Once you’ve improved it, move on.

Cycle time is a reasonable default. It’s a broad measure that captures much of what platforms actually influence, and tools like LinearB integrate with most common dev stacks out of the box to give you DORA-style metrics without a heavy build. Starting with cycle time lets you establish a baseline, ship a change, and point at a number that moved.

This isn’t glamorous advice, but it’s the advice most platform leaders wish they’d been given earlier. Being able to quantify the benefit you’re adding makes later responsibilities like staffing decisions, prioritization, and executive conversations considerably easier.

Once you start designing the platform itself, one of the earliest forks in the road is whether to offer a paved road or a Golden Path.

A paved road gives developers a clear, well-supported default route through the platform, but allows them to diverge if they have a legitimate reason to. A Golden Path is more opinionated — divergence isn’t really an option, and the platform team is expected to cover every use case that matters to the business centrally. Both approaches have their place. The right choice usually comes down to how much variance already exists in how your teams provision infrastructure and how centralized your engineering culture is.

Related to this is the question of whether your internal developer platform (IDP) should be headless or have a UI of its own. Off-the-shelf products like OpsLevel and Backstage make the UI question easier to answer, but they come with a real upfront cost. If your teams have already decentralized and diverged, a heavy IDP build can feel like you’re trying to retrofit uniformity onto a system that’s already comfortable with its differences. It can be significantly more pragmatic to adopt a headless approach, where Terraform and tooling APIs do the work of enforcing standards without forcing everyone into a new portal.

In 2019, Checkout.com had roughly 200 engineers and three DevOps engineers managing all the infrastructure. Everything of consequence went through that small team, mostly via ClickOps. It was not viable.

The first move was decentralization, which involved loosening the bottleneck by pushing infrastructure ownership out to the product teams using a Spotify-style model. At roughly the same time, the company began rolling out IaC in earnest. The initial approach was deliberate: start with a single, relatively simple product and build it entirely with IaC, use it as the learning ground, and expect to redo parts of it once the team understood what not to do. Every team that takes the Terraform journey for the first time ends up reworking their early projects once they learn the patterns. Planning for that from the start makes it much less painful.

Governance wasn’t abandoned in the process. Every team could provision their own infrastructure, but changes still passed through architectural reviews, and certain categories of resource still went through a shared IT function. The result was genuine self-service without losing the ability to say no to something that didn’t belong in the estate.

The platform team itself was stood up around 2020. It was small. Its remit was explicitly to accelerate teams rather than to own everything. Given how much variance had already built up across the org, added to AWS’s infamous flexibility, a paved road model made more sense than Golden Paths. Product teams could pick from a range of tools and patterns, but the platform team used Terraform to configure those tools in an opinionated way. The modules they shipped constrained how the tools got wired in, while leaving room for teams to express the differences that genuinely mattered.

That applied to everything from feature flags to low-code UI tooling. Teams had to operate within a standard, but the standard had room in it.

Two takeaways from that period stand out. The first is that you don’t need to go big-bang. Building the perfect Backstage instance on day one is almost always the wrong move; the cost is enormous and the payback is distant. Start small and let the platform grow in response to real demand. The second is the one already mentioned: measure engineering efficiency from the beginning. A lot of the difficulty of that period was self-inflicted because no one had told the team to instrument what they were doing before they started changing it.

Three trends seem most likely to shape the next phase of platform engineering.

Shift Left FinOps. IaC has made provisioning infrastructure almost trivially easy, which means most organizations are running over-provisioned infrastructure or the wrong types of infrastructure entirely. Cost decisions tend to be made late, after the bill arrives, rather than at the point of provisioning. Pushing cost awareness earlier into the development lifecycle, so that cost implications are exposed inside the IDE, inside PR reviews, inside module defaults, is one of the higher-leverage opportunities available to platform teams right now.

AI in the SDLC. Generative AI in code editors has been done to death. The more interesting frontier is AI that attaches itself to the rest of the delivery pipeline: AI that helps you improve your CI, diagnose build failures, reduce change failure rate, accelerate rollbacks, and shorten mean time to resolution during incidents. That’s where platforms stand to gain the most, and where the work is still genuinely open.

Platform orchestration. The term is still settling, but the idea is the coupling of infrastructure and application code in a way that lets teams deploy both together through a standardized interface. A lot of what exists today in this space is self-built — prototypes inside individual companies rather than shared industry patterns. The epiphany moment, where the industry converges on a common way to deploy application code and the infrastructure it depends on, hasn’t quite arrived. But the direction feels right, and the demand is clearly there.

Platform engineering isn’t a replacement for IaC. It’s what IaC grows into once your organization is large enough that the tooling, the integrations, the governance, the developer experience around your infrastructure starts to matter more than the infrastructure definitions themselves.

The lessons from teams that have been through this evolution are consistent:

• Start small.
• Measure one thing.
• Treat your platform as a product with internal customers.
• Favor paved roads over Golden Paths unless you have the centralization to pull the latter off. Use IaC not just to provision cloud resources but to configure the tools your developers actually work inside every day.
• Keep an eye on trends in cost, AI, orchestration that will shape what the platform has to do next.

The organizations getting this right are the ones that understood early that the platform is a product and built it accordingly.