Platform Engineering Didn't Replace DevOps — It's DevOps Grown Up Enough to Ship as a Product

I keep seeing some version of the same argument on LinkedIn: platform engineering is killing DevOps, or DevOps was always a fad and platform engineering is the “real” discipline that replaced it, or — my least favourite — that the two terms are just marketing labels for the same job with a new coat of paint every few years so vendors have something to sell at KubeCon. None of that matches what I’ve actually watched happen, either in my own homelab or in twenty-five years of building infrastructure for other people’s businesses. So this is post one of five where I want to work through it properly, using a pipeline I actually operate rather than a diagram borrowed from a vendor deck.

The short version, before the long one: platform engineering didn’t show up to replace DevOps. It showed up because DevOps worked well enough that it stopped scaling.

What DevOps Actually Asked For

#

DevOps, at its core, was never a job title or a toolchain — it was a culture change aimed at a specific dysfunction: developers who threw code over a wall and operations teams who caught the pager when it broke. The fix was “you build it, you run it” — the team that writes the code owns it in production too, which means the same team owns the pipeline that gets it there. CI/CD stopped being something a separate release-management function did on a schedule and became something every product team was expected to own for itself.

I lived the “before” version of this. Early in my career at Syrex, infrastructure and application teams were genuinely separate — I was the escalation point for a multi-site Active Directory trust or an Exchange DAG failover that some other team’s decision had quietly broken, weeks after the fact, with nobody left who remembered making the call. DevOps culture is the industry’s answer to exactly that gap: collapse the distance between the decision and the consequence, and put both in the hands of the same people.

That answer was correct. It’s still correct. Nothing in this post argues that shared ownership between build and run was a bad idea that platform engineering is now here to undo.

The Bit DevOps Never Solved

#

Here’s the problem it left behind, and it only shows up once you have more than a handful of teams doing this at once: if every team owns its own pipeline, every team ends up building its own pipeline. Team A wires Jenkins to a bespoke deploy script. Team B picks GitHub Actions and hand-rolls its own promotion logic in a YAML file nobody outside the team can read. Team C never gets around to a security gate at all, because nobody told them they needed one and nobody stopped them from shipping without it. Multiply that by twenty teams in a regulated organisation and you don’t have twenty examples of DevOps done well — you have twenty ways to make the same mistake once each, twenty audit surfaces instead of one, and twenty engineers who are now half pipeline experts and half whatever they were actually hired to build.

That’s not a hypothetical. It’s the exact shape of the problem I deal with at eBucks, where the question isn’t “does this team believe in shared ownership” — everybody does, by now — it’s “did this team’s version of shared ownership include a security gate before the image touches any environment, or did it quietly skip that step because nobody wrote it down as a requirement.” DevOps gave every team the authority to own their pipeline. It never gave them a reason not to reinvent it badly, alone, under deadline pressure, without the person who’s seen this exact failure mode before.

What Platform Engineering Actually Is

#

Platform engineering is the industry’s answer to that specific gap, not to DevOps culture itself. Instead of every product team becoming expert enough in CI/CD, image scanning, promotion policy, and progressive delivery to get all of it right independently, a dedicated platform team builds that expertise once, into a self-service internal developer platform, and exposes it as a small number of golden paths. A product team consumes the platform the way they’d consume any other internal API — push to Git, get a build, get a scan, get a promotion, get a rollout — without needing to know how any of it works underneath, in the same way I don’t expect a developer to understand DNS-01 challenges to get a working TLS certificate.

The word that matters here is product. A platform team doesn’t hand product teams a shared Jenkins server and call it done. It treats the platform itself as something with users, a roadmap, and a reason people choose the golden path over building their own. That’s a genuinely different job from what most DevOps engineers were doing five years ago — less “keep this pipeline running,” more “understand what fifteen product teams actually need from a paved road, and build the thing that makes reinventing it pointless.”

None of this is abandoning DevOps skill. It’s productising it. The engineer who used to hand-wire a Jenkins pipeline for their own team is the same engineer who’s qualified to build the reusable WorkflowTemplate fifteen teams consume — the skill didn’t change, the audience and the packaging did.

What I Can Already See From My Own Pipeline

#

I run this blog through a full GitOps pipeline, solo, in a homelab — I’ve documented the mechanics twice already : a Gitea push fires a webhook, Argo Events validates it and hands off to Argo Workflows, which builds a multi-arch image with BuildKit and runs it through SonarQube and Trivy in parallel. From there Kargo takes over — a Warehouse watches the registry for a new tag, wraps it in Freight, and promotes it through a preview Stage and then a production Stage, each one gated by policy defined in YAML rather than hand-typed into a deploy script. ArgoCD syncs whatever Kargo commits. Argo Rollouts cuts a blue-green switch, and exactly one human decision — kubectl argo rollouts promote blog -n blog — sits at the end of it.

I’m one person. There’s no second team consuming this pipeline. But the shape of it is already the shape a platform team would extract as a golden path, and the shape that’s still bespoke is instructive too:

The Kargo layer is the clearest example of what “platform-shaped” actually means in practice. The promotion policy — which Freight is allowed into which Stage, whether it auto-promotes, what verification has to pass first — lives entirely in resources in Git. If I had a second project tomorrow, I wouldn’t write new promotion logic for it. I’d write a new Stage that points at the same policy shape the blog already uses. That’s the whole idea of a golden path in one sentence: the policy is reusable even though the artefact being promoted is completely different.

Compare that to the Gitea Actions workflow file itself — the bit that constructs a JSON payload and calls a webhook receiver. That’s still something I’d hand-copy into any new repo I wanted onto this pipeline, and it’s exactly the kind of boilerplate a platform team would delete by giving teams a shared Action or a CLI instead of a copy-paste starting point. It works today because I’m the only consumer and I remember how it’s wired. It wouldn’t survive a second team without becoming someone’s full-time job to keep consistent — which is precisely the moment a platform team’s existence starts paying for itself.

Not a Replacement, a Productisation

#

The framing I’d push back on hardest is “platform engineering versus DevOps,” because it implies a team has to pick a side. What’s actually happening across the industry going into this stage of 2026 is closer to a maturity curve than a rivalry: DevOps established that the team building the software should own running it; platform engineering is the answer to what happens once you have enough teams doing that, that reinventing the pipeline per team becomes its own source of risk. The skills don’t disappear — the CI/CD literacy, the incident instincts, the “I’ve traced this failure mode before” pattern-matching that DevOps culture built into individual engineers — they get concentrated into a smaller team whose job is to build the paved road well enough that everyone else doesn’t need those skills to ship safely.

That’s not a smaller job than DevOps. It’s a different one, closer to product management with a Kubernetes cluster attached, and it’s the one I’ll spend the rest of this series digging into — what the actual distinction is between shared DevOps culture and a dedicated platform team, what my own pipeline would need to become an internal developer platform rather than a very disciplined solo project, and what a golden path buys a regulated organisation that a pile of individually-excellent pipelines never will.

Summary

#

DevOps was right about who should own a pipeline — the team that builds the thing should run it too. It was never a plan for what happens when twenty teams all try to build that pipeline independently, under deadline, without a way to share the parts that don’t need reinventing. Platform engineering is the industry productising the parts of DevOps practice that kept getting rebuilt from scratch — golden paths, self-service, promotion policy defined once and reused rather than copied — while leaving the underlying culture of shared ownership completely intact. My own pipeline, run solo, already shows the seam: the promotion policy in Kargo is reusable configuration; the webhook boilerplate in Gitea Actions is still something I’d hand-copy per project. That seam is exactly where the next four posts in this series are going.

More on this next week — the actual distinction between DevOps as culture and platform engineering as a team.

Get in touch · View Resume · Connect on LinkedIn