The Rise of Platform Engineering: Why Your DevOps Model Is Broken

The DevOps model that made sense for 20 engineers starts to buckle around 100 and collapses somewhere after 300. Not because DevOps is wrong, but because 'you build it, you run it' at scale requires infrastructure expertise that most product engineers don't have — and shouldn't need.

The cognitive load problem

A backend engineer in 2025 is expected to write services, own their CI/CD pipeline, manage Kubernetes manifests, configure observability, handle security scanning, and reason about cost. That's four specialist disciplines on top of the actual job. The result is either burnout or shortcuts — neither is acceptable in production systems.

Platform engineering as the answer

Platform engineering centralises the infrastructure complexity into an Internal Developer Platform (IDP) — a curated set of self-service capabilities that product engineers consume through simple, opinionated APIs. Deploy a service: one command. Add observability: one annotation. Provision a database: one Terraform module. The platform team owns the golden paths; product teams walk them.

What a mature IDP looks like

A mature IDP has five layers: a service catalogue (every running service, its owner, SLA, and runbook); a self-service provisioning layer (infrastructure-as-code templates for the 80% case); a deployment platform (opinionated CI/CD with built-in SAST, secret scanning, and smoke tests); an observability layer (pre-configured dashboards, alerts, and SLO tracking); and a cost attribution layer (spend per team, per service, per environment). Backstage, Port, and Cortex are the three dominant portal frameworks — but the framework is less important than the golden paths.

The team topology that works

Platform teams work best when they operate as product teams with internal customers. This means roadmapping based on developer experience metrics (DORA metrics, deployment frequency, change failure rate), running office hours and onboarding sessions, and measuring adoption rather than capability shipped. A platform nobody uses is a cost centre, not an accelerator.

The migration path

Organisations don't migrate to platform engineering all at once. The pattern that works: start with a pain catalogue (which infrastructure tasks take the most engineering time?), build golden paths for the top three, prove adoption and ROI, then expand. Don't try to build the full IDP in a single programme. The platform is a product — ship an MVP, iterate on feedback.

Measuring success

The metrics that matter: time-to-first-deployment for a new service (should be under 30 minutes with a mature IDP), deployment frequency per team, change failure rate, and the percentage of teams using the platform's golden paths. If you're not measuring these before and after, you won't know if you've succeeded.

Our take

Platform engineering is not a technology choice — it's an organisational design choice. The technology stack (Kubernetes, Terraform, Backstage, ArgoCD) is table stakes. The hard part is building the team, the culture of internal product thinking, and the feedback loops that keep the platform relevant as the engineering organisation grows.