For a decade the prevailing wisdom was DevOps: tear down the wall between development and operations, give every team end-to-end ownership of the services they ship. It worked — for the high-performing companies that practised it deeply. For everyone else, the strategy started to crack under its own weight.
The Problem That Brought Platform Engineering
"You build it, you run it" is sound philosophy. In practice, by the late 2010s a typical application engineer needed to know:
- Kubernetes (Pods, Deployments, Services, Ingress, RBAC, NetworkPolicy, HPA, PDB...)
- Terraform / Pulumi / Crossplane for cloud infrastructure
- CI/CD systems (Jenkins, GitHub Actions, GitLab CI, Argo CD)
- Observability stacks (Prometheus, Grafana, OpenTelemetry, Loki, Tempo)
- Security tooling (Vault, OPA, Falco, image scanners, SBOM)
- Cloud-provider services across one or several clouds
- Service mesh (Istio, Linkerd, Cilium), API gateways, message brokers
- Compliance frameworks (SOC 2, ISO, PCI, HIPAA)
The job description "full-stack engineer" had quietly become "full-stack plus operating-system, network, security, and compliance engineer." Teams shipping product slowed down because the cognitive overhead of running their service consumed every other Tuesday. The 2021 State of DevOps report (DORA) made the connection explicit: cognitive load is now the single biggest impediment to delivery performance.
The Response: Platforms as Products
The platform engineering movement crystallised around a simple idea: extract the cross-cutting concerns into a paved path that application teams can adopt as a product. A platform team builds, owns, and operates this paved path; application teams consume it.
The CNCF's working definition (2024):
Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organisations in the cloud-native era. Platform engineers provide an integrated product, most often referred to as an Internal Developer Platform (IDP).
What an Internal Developer Platform Is
An IDP is not a single tool. It is a curated set of capabilities accessed through a coherent interface — usually some combination of:
| Layer | Examples |
|---|---|
| Developer portal | Backstage, Port, Cortex, Roadie |
| Service templates | Backstage scaffolder, Cookiecutter, internal CLIs |
| CI/CD as a service | GitHub Actions runners, GitLab, Argo Workflows |
| Deploy / release | Argo CD, Flux, Spinnaker, Humanitec |
| Infrastructure orchestration | Crossplane, Pulumi, Terraform with policy |
| Observability defaults | Pre-wired Prometheus, OTel, dashboards, alerts |
| Secrets and identity | Vault, SPIFFE, cloud IAM federation |
| Policy and security | OPA / Gatekeeper, Kyverno, Sigstore, supply-chain |
Crucially, the platform is whatever fraction of these your developers actually need. A 40-person startup might have a platform that is "GitHub + Render.com + a Slack channel." A 4 000-engineer enterprise might have a custom Backstage with hundreds of templates. Both are valid platforms.
What It Is Not
- Not "ops renamed." The ops team that did manual ticket work and called themselves "platform" — without changing how they work — is not practising platform engineering.
- Not a single tool. "We have Kubernetes" is not a platform. "We have Backstage" is not a platform. Tools are ingredients.
- Not a way to enforce policy via gate-keeping. A platform that says "no" by default is one developers route around. Good platforms make the right thing the easy thing.
- Not just for hyperscalers. Spotify, Netflix, and Google built platforms because they had to. Companies a tenth their size adopt the same patterns because the cost of not doing so is now visible.
Platform Engineering vs DevOps vs SRE
| Discipline | Primary concern | Output |
|---|---|---|
| DevOps | Cultural integration of dev and ops | Faster, safer delivery |
| SRE | Operational reliability of running services | SLOs met, toil reduced |
| Platform engineering | Developer productivity at scale | An IDP product that other engineers consume |
These overlap heavily. In small orgs one team does all three; in large orgs they are distinct functions that collaborate.
The Industry Signal
- Gartner: by 2026, 80% of large software engineering organisations will have platform teams.
- CNCF launched the Cloud Native Platform Associate (CNPA) cert in 2024 to formalise the discipline.
- Job titles "Platform Engineer", "DevEx Engineer", "Internal Tools Engineer" grew 3-4x year-on-year through 2023-2024.
- Open-source projects: Backstage (40k+ stars), Port, Crossplane, Kratix, Humanitec — all growing.
- Vendor activity: every major cloud (AWS Proton, GCP Cloud Workstations, Azure Deployment Environments) now ships IDP-adjacent products.
The Honest Caveats
- Platforms have failure modes: over-abstraction, ivory-tower architecture, gold-plating, slow uptake.
- The discipline is young; many "platform teams" are still mid-rebranding from ops.
- ROI is real but lagging — usually 6-18 months before the curve bends.
- Measuring success requires honest developer satisfaction surveys, not vanity metrics.
The rest of this course covers the team patterns, tools, and operating model that make platform engineering work in practice.