Platform Engineering

Platform Engineering#

Platform engineering is the discipline of building internal developer platforms (IDPs): a curated, opinionated layer between application developers and the underlying cloud / Kubernetes / observability / security stack. The platform team owns the abstractions; product teams ship through them.

The maturation of “DevOps” into a discipline that scales beyond the team-of-the-original-engineers.

Why It Exists#

DevOps as originally formulated (“you build it, you run it”) works for one team that knows the whole stack. At company scale, asking 50 product teams to each become Kubernetes experts produces:

Wildly inconsistent practices.
Duplicated effort and tooling.
Long onboarding for new engineers.
Security gaps from teams not meant to be ops experts.
Burnout from cognitive overload.

Platform engineering reframes the question: what’s the smallest thing a developer needs to know to ship safely? The platform team hides the rest.

The Platform as a Product#

A platform team treats developers as customers:

Self-service portals / catalogs, developers can create a new service, environment, queue, or database without filing a ticket.
Golden paths, the recommended way to do common things; opinions encoded as templates and defaults.
Documentation, runbooks, getting-started guides, examples.
Office hours / support, humans who help when self-service doesn’t cover the case.
Roadmaps, the platform evolves based on user research, not guesses.

The metric that matters: time from “I want a new service” to “it’s in production with logs, metrics, alerts, and on-call coverage”.

What’s in a Platform#

The components a typical IDP provides. Service templates, ephemeral preview environments, observability defaults, secret paths, identity primitives, cost dashboards, incident routing, and compliance scaffolding, packaged as one cohesive product, not a pile of separate links.

Service templates, new-service produces a repo with CI, Dockerfile, manifests, observability hooks, alerts, runbook stub.
Self-service environments, ephemeral preview environments per PR; production environments via PR.
Centralized observability, logs, metrics, traces wired up by default.
Standard secrets management, one path to get a database credential, one path to get an API key.
Identity, workload identity, service accounts, RBAC defaults.
Cost dashboards, per-service / per-team spending.
Incident response, on-call routing, paging, runbook generation.
Compliance scaffolding, audit logs, retention, evidence collection.

The platform ships these as one cohesive product, not a pile of links.

Tools#

The IDP frameworks an operator may meet. Backstage is the de-facto starting point with rich plugins and templates; Port, Cortex, and OpsLevel cover the commercial space; Crossplane, Humanitec, Kratix, and Score handle different slices of the build-your-own-platform problem.

Backstage, Spotify’s IDP framework; the de facto starting point. Plugin-based; component catalogs, Software Templates, Tech Radar.
Port, commercial IDP; lighter setup than Backstage.
Cortex, service catalog + scorecards.
OpsLevel, service maturity, catalog.
Crossplane, Kubernetes-native cloud provisioning; the substrate for many IDPs.
Humanitec, platform-orchestrator category.
Kratix, a way to build platform APIs on Kubernetes.
Score, workload specification for developers, agnostic of the underlying platform.

The platform itself is built on the rest of this section: IaC, Kubernetes, GitOps, observability, secrets management.

Platform vs. Tool#

A platform is not the sum of its tools. A platform is the opinion about how the tools fit together:

“All services use OpenTelemetry; you don’t choose your tracer.”
“All databases are provisioned via the platform; no DIY RDS in IaC.”
“Production deploys go through Argo CD; kubectl apply is read-only there.”
“Secrets come from Vault via the platform’s CRD; you don’t touch the values directly.”

Opinions are the product. Without them, you have a wiki, not a platform.

The Team#

The composition of a working platform team. Platform engineers build and operate; specialists cover networking, security, observability, and identity; tech writers and DX engineers handle docs and internal marketing; a product manager runs research and prioritizes.

Typical platform teams have:

Platform engineers, build and operate the IDP itself.
Specialists, networking, security, observability, identity.
Tech writers / DX engineers, documentation, examples, internal marketing.
Product manager, user research, roadmap, prioritization.

The team’s customers are the rest of engineering. The team’s metric is the success of those customers, not the lines of YAML shipped.

Platform Anti-Patterns#

The shapes of platform team that fail to deliver. Tax-mode gatekeeping, monorepo-bound builds, slide-deck platforms that never ship, customer-research-free roadmaps, and premature platforms before there’s enough leverage; each is a known anti-pattern with a known cause.

Platform-as-tax, the platform team is a gatekeeper, not an enabler. Symptoms: PRs blocked for weeks, “you have to file a ticket” answers.
Platform-as-monorepo, the platform is a giant CI build that takes hours. Anyone touching shared code waits.
Platform-as-PowerPoint, aspirations published; reality is the same as before.
No customer research, platform built for what the platform team finds interesting, not what users need.
Premature platform, six engineers building a platform for ten engineers. Not enough leverage to justify.

Conway’s Law applies: a poorly-bounded platform team produces a poorly- bounded platform.

When to Build a Platform#

The thresholds that justify a formal platform team. Twenty or more application engineers, five or more teams doing similar things differently, real operational repeatability problems, and a real budget; below those, lighter standards beat a platform team in cost-to-value.

Heuristics:

You have 20+ application engineers.
You have 5+ teams doing similar things slightly differently.
You have operational repeatability problems, new services take weeks; production drifts; incidents repeat across teams.
You have a budget, platforms aren’t a side project.

Below these thresholds, lighter-weight standards (templates, shared GitOps repos, runbooks) usually carry farther than a formal platform team.

Cognitive Load#

Team Topologies (Skelton & Pais) frames platform engineering as reducing the cognitive load on stream-aligned (product) teams. Stream-aligned teams own outcomes; platform teams provide thinned-down abstractions. Enabling teams help product teams adopt new capabilities; complicated-subsystem teams own the bits that genuinely require specialists.

Platform engineering inherits this language; it’s worth reading the book if you’re building one of these teams.

What Platform Engineering Isn’t#

Not a rebranded ops team, the deliverable is a product, not a ticket queue.
Not “we run Kubernetes for you”, that’s part of it, but the product is the abstraction over Kubernetes, not Kubernetes itself.
Not the end of “you build it, you run it”, product teams still own their services. The platform handles only what’s genuinely shared.
Not for every company, small organizations don’t need it.