Why Platform Engineering Won the DevOps Debate in 2024

TL;DR — DevOps as “everyone owns ops” hit a cognitive wall around 2022. Platform engineering re-centralizes the toil into a product team that sells golden paths to internal customers. The 2024 shift is treating the platform as a product, not a wiki.

For about a decade, I told junior engineers the same thing: “DevOps isn’t a team, it’s a culture.” That was true in spirit and false in practice. Sometime in 2022 the cracks started showing. By late 2023 my Slack was full of senior backend folks asking the same question — “Why does every team in our org now run their own Terraform fork, their own GitHub Actions templates, and their own half-built Kubernetes operators?” The honest answer is that pure DevOps-everywhere doesn’t scale past a few dozen engineers. In 2024 the industry has more or less admitted it and put a name on the fix: platform engineering.

This isn’t a rebrand. It’s a structural change in how org charts and ownership work. The platform team treats other engineers as paying customers, ships a product called the Internal Developer Platform (IDP), and is measured on adoption — not ticket throughput. If you’ve been reading the DORA reports the last two years, this thread has been there all along: high performers reduce cognitive load on application teams. They don’t multiply it.

So this piece is the framing post. Why DevOps-for-everyone stopped working, what platform engineering actually replaces, and what the rest of this month’s posts will dig into.

The DevOps cognitive ceiling

The DevOps movement won the early war. It killed throw-it-over-the-wall ops, gave us infrastructure-as-code, and made deployment automation a baseline skill. Good outcomes. The unintended consequence was that the surface area each developer is now expected to own kept expanding:

• Kubernetes manifests, Helm charts, Kustomize overlays
• Terraform for cloud resources
• CI pipelines in YAML
• Service meshes, ingress controllers, observability agents
• Secrets management, IAM policies, image signing
• SBOMs and supply-chain attestations

I once asked a backend engineer on a colleague’s team what they spent their week on. Forty percent on infra YAML and CI debugging. Maybe thirty on actual feature code. The rest on tickets that boiled down to “the platform doesn’t make this easy.” That ratio repeats across every org I’ve consulted with since 2022.

Team Topologies (Skelton and Pais, 2019) gave us the vocabulary for this. Stream-aligned teams should have a fast flow of change. Every detour into infra toil is friction. Past a certain headcount — somewhere between 30 and 80 engineers, in my experience — the infrastructure surface becomes too wide for stream-aligned teams to keep up with. Their cognitive budget is gone.

You can hire SREs and embed them. Helps for a year. Then the SREs themselves get pulled in fifteen directions. Same pattern.

What an IDP actually delivers

Platform engineering’s answer is to take everything below the application boundary and turn it into a self-service product. The IDP is the user interface and contract for that product.

A useful definition I keep coming back to: an IDP is the set of abstractions, tools, and workflows that let a developer go from “I want a new service” to “it’s in production” without filing a ticket against a human. The platform team owns the abstractions; the application teams consume them.

In 2024 the typical IDP stack looks roughly like this:

# A 'golden path' template — Backstage Software Template
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: go-api-service
  title: Go API Service
  description: Provision a new Go HTTP API with CI, K8s manifests, observability
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service info
      properties:
        name:
          type: string
          pattern: '^[a-z][a-z0-9-]+$'
        owner_team:
          type: string
  steps:
    - id: scaffold
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
    - id: github
      action: publish:github
      input:
        repoUrl: github.com?repo=${{ parameters.name }}&owner=acme
    - id: register
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.github.output.repoContentsUrl }}

A developer hits the button in Backstage, fills two fields, and three minutes later has a repo, a CI pipeline, a Kubernetes namespace, monitoring dashboards, and a row in the service catalog. They never touched Terraform. They never wrote a Deployment YAML.

Underneath, the platform team is running Kubernetes 1.29, ArgoCD for delivery, Crossplane or Terraform for cloud resources, OpenTelemetry collectors, and whatever else makes sense. None of that leaks to the developer unless they ask.

The product-not-platform mindset

Here’s the part that trips most teams up. You can stand up Backstage and Kubernetes and Crossplane and still fail. The technical stack is the cheap part.

The harder shift is treating internal engineers as customers. That means:

• Discovery. Talk to your stream-aligned teams. Find out where they spend their time. Don’t build what you assume they need.
• Adoption metrics, not output metrics. It doesn’t matter how many golden paths you ship. It matters how many services flow through them. I’ve seen IDPs with thirty templates and three real consumers.
• A real roadmap with releases. Your IDP needs a changelog and a deprecation policy. Internal customers hate breaking changes just as much as external ones.
• Office hours and docs that match the product. When your “customers” hit a wall, they should be unblocked in an hour, not a sprint.

Humanitec’s 2023 platform survey put it bluntly: teams that ran the platform as a product had ~3x higher adoption than teams that ran it as a side project. The pattern matches what I see in the wild.

What’s actually new in 2024

You could argue platform engineering is just SRE in a new hat. There’s some truth there, but the 2024 wave has genuinely new pieces:

1. Workload specifications like Score decouple the developer-facing contract from the deployment target. A team writes a score.yaml. The platform team decides whether it lands on Kubernetes, ECS, or Nomad.
2. Backstage maturity. The 1.20+ releases stabilized the scaffolder and catalog enough that you can adopt it without forking three internal plugins. The plugin marketplace has finally caught up.
3. Crossplane v1.14. Provider-family architecture lets you ship narrow, fast providers per cloud service rather than the old monolithic provider. Drift handling is actually usable.
4. AI-assisted scaffolding. Several IDP vendors started shipping LLM-backed “describe what you want, get a service” UIs in late 2023. Mostly demo-ware so far, but the trajectory is real.
5. FinOps natively in the platform. Cost dashboards per service, automatic right-sizing recommendations, namespace-level chargeback. This was bolt-on tooling two years ago. It’s table stakes now.

I’d argue point 1 is the most important. Workload specs finally give us the right seam between the dev-facing contract and the infra-facing implementation. The rest of the industry hasn’t fully internalized it yet.

Common Pitfalls

A few traps I’ve watched teams walk into more than once:

• Building a platform before you have a paying customer. If no application team is willing to migrate during your first 90 days, you’re building a museum piece. Pick a pilot team and design with them.
• Confusing portals with platforms. A Backstage instance with a fancy catalog isn’t a platform. The platform is the backing automation. The portal is a window into it.
• Forcing every team onto the same golden path. You’ll have outliers — ML training jobs, batch workloads, legacy services. Carve a “self-service-with-help” tier instead of denying access. The minute you say “no”, you’ve lost adoption.
• Skipping the deprecation story. Every abstraction you ship is a future migration. Plan the off-ramp before you ship.
• Hiring all infra engineers. A platform team needs product thinking. A staff PM or a product-minded eng lead is usually the missing piece.

The one I personally got wrong, years back, was the discovery step. I built three “obviously useful” abstractions for a team that didn’t actually have those problems. Two were unused at six months. Talk to people first.

Wrapping Up

The DevOps vs platform engineering framing is mostly a false binary. Platform engineering is what mature DevOps looks like at scale — DevOps culture, but with one team productizing the toil so the rest of engineering can flow. This month I’ll dig into the concrete pieces: building an IDP on Backstage, designing golden paths, the Crossplane-vs-Terraform decision, and how to measure developer experience without falling into vanity metrics.

If you’re standing up a platform team in 2024, the first decision isn’t tooling. It’s whether you have the org backing to treat it as a product with a roadmap. Get that wrong and the rest doesn’t matter.