Post

Platform Engineering Foundations

An industry primer on platform engineering, covering organisational vocabulary (Team Topologies, Platform-as-a-Product, paved roads, SRE) and the technical building blocks of a modern Internal Developer Platform.

Posted Updated
By
15 min read
Platform Engineering Foundations

An industry primer on platform engineering, covering both the organisational vocabulary (Team Topologies, Platform-as-a-Product, paved roads, “you build it, you run it”, SRE) and the technical substance — the building blocks of a modern Internal Developer Platform (IDP) and case studies of platforms other organisations have published about. This is the entry point to the series; deeper posts cover each concept in detail.

How this series fits together

flowchart LR
    F["Foundations<br/>(this post)"] --> TT["Team Topologies<br/>for Platform Teams"]
    F --> IDP["Internal Developer<br/>Platforms"]
    TT --> PaaP["Platform as<br/>a Product"]
    TT --> SK["What Skills a Platform<br/>Team Needs"]
    IDP --> DP["Developer Portals:<br/>Backstage, Port, Cortex"]
    IDP --> GP["Golden Paths and<br/>Paved Roads"]
    PaaP --> DX["Developer Experience<br/>and DX Metrics"]
    GP --> DX
Question Read
How should platform and delivery teams be organised? Team Topologies for Platform Teams
How do we run the platform like a product? Platform as a Product
What is an IDP made of, and what do we build vs buy? Internal Developer Platforms
Backstage, Port or Cortex? Developer Portals
How do we make the right way the easy way? Golden Paths and Paved Roads
How do we prove it works? Developer Experience and DX Metrics
Who do we hire? What Skills a Platform Team Actually Needs

Why platform engineering exists

The platform-engineering discipline has, over the last decade, converged on two distinct bodies of knowledge:

  1. Organisational patterns for how platform and delivery teams work together — Team Topologies, Platform-as-a-Product, paved roads, SRE.
  2. Technical building blocks that every modern Internal Developer Platform is assembled from — developer portals, scaffolding, workload orchestration, GitOps delivery, runtime, policy & supply chain — and a growing body of public case studies from Spotify, Netflix, Zalando, Monzo, Mercedes-Benz, Adevinta, and others.

The convergence matters: a team starting today no longer has to invent the discipline from scratch. The vocabulary is shared, the layers of an IDP are well-understood, and the products at each layer form a choose-what-fits menu.

graph TD
    A[Platform Engineering] --> B[Organisational Patterns]
    A --> C[Technical Building Blocks]

    B --> B1[Team Topologies]
    B --> B2[Platform-as-a-Product]
    B --> B3[Paved Road / Golden Path]
    B --> B4[You Build It You Run It]
    B --> B5[SRE — SLOs & Error Budgets]

    C --> C1[Developer Portal]
    C --> C2[Scaffolding & Templates]
    C --> C3[Workload Orchestration]
    C --> C4[GitOps Delivery]
    C --> C5[Runtime Plane]
    C --> C6[Policy & Supply Chain]

Organisational vocabulary in brief

A short orientation. Links point to canonical sources for depth; full deep-dives live in Team Topologies for Platform Teams and Platform as a Product.

Team Topologies

Team Topologies (Matthew Skelton & Manuel Pais, 2019; 2nd ed. 2025) is the standard framework for designing engineering orgs around flow. It defines:

Four team types

  • Stream-aligned — the default. Owns a business-domain flow end-to-end.
  • Platform — internal product team. Builds a self-service platform consumed by stream-aligned teams.
  • Enabling — short-lived coaches. Help stream-aligned teams adopt new capabilities.
  • Complicated-subsystem — deep specialists for hairy problems (e.g. video codecs, ML inference).

Three interaction modes

  • X-as-a-Service — self-serve, steady state. The target for any mature capability.
  • Collaboration — time-boxed joint discovery. Two teams build something together.
  • Facilitating — temporary pairing during onboarding or new-tech rollout.

The trajectory for any capability is Collaboration → Facilitating → X-as-a-Service. A platform team perpetually stuck in Collaboration is doing consulting, not platform engineering.

→ Martin Fowler bliki: TeamTopologies.

Adjacent operating models

Each of these extends or overlaps with Team Topologies. Most mature orgs blend them.

  • Platform-as-a-Product — treat the platform as a product with customers (delivery teams), a PM, a roadmap, user research, adoption metrics. Measured by adoption, not tickets resolved. Convergent consensus across DORA, CNCF, Gartner, Thoughtworks. → Manuel Pais, Platform as a Product; Evan Bottcher, What I Talk About When I Talk About Platforms.
  • Paved road / golden path — the output of Platform-as-a-Product: the opinionated, well-lit path from git push to production. Netflix: “paved road”; Spotify: “golden path”. Teams inherit security, observability, reliability defaults for free.
  • “You build it, you run it” — Werner Vogels (Amazon). Delivery teams own services end-to-end including on-call, on top of the paved road — not instead of it.
  • Site Reliability Engineering (SRE) — Google’s discipline: reliability governed by SLOs and error budgets. Mature platforms adopt the practices even without a dedicated SRE team. → sre.google/books.
  • Cloud Center of Excellence (CCoE) — cross-cutting group for cloud standards, landing zones, FinOps. Folds into the platform team at smaller scale.
  • Traditional centralised Ops — separate Ops department receiving deployment hand-offs. The model DevOps, SRE, and Team Topologies were designed to replace. Reference point only.

The mature configuration

Most organisations settle on a blend:

Platform-as-a-Product + X-as-a-Service as the default interaction + “You build it, you run it” on top + SRE practices (SLOs, error budgets).

For a comparison of working-model alternatives and their tradeoffs, see the DevOps Topologies anti-types catalogue and the CNCF Platform Engineering Maturity Model.

What a platform actually is — the IDP building blocks

The vocabulary above describes how a platform team works. This section describes what a platform is made of. A modern Internal Developer Platform (IDP) is assembled from a recognisable set of building blocks that have converged over the last five years. Not every platform has all of them, and teams mix build / buy / open-source freely — but the shape of the stack is now broadly industry-standard.

For a deeper treatment of each layer, see Internal Developer Platforms.

The IDP reference stack (six layers)

The layers are conceptual, not organisational. One team typically owns the whole stack, but thinking in layers clarifies what the platform does, which pieces are replaceable, and where the tenant-facing contract lives.

graph TD
    Dev[Developer] -->|browses| L1[1. Developer Portal & Catalogue]
    Dev -->|creates new| L2[2. Scaffolding & Golden Paths]
    Dev -->|declares intent| L3[3. Workload Spec & Orchestration]
    L3 -->|generates manifests| L4[4. CD & GitOps]
    L4 -->|deploys to| L5[5. Runtime Plane]
    L6[6. Policy, Supply Chain, Observability] -.guards.-> L4
    L6 -.guards.-> L5
Layer What it does Representative products
1. Developer portal & service catalogue Single place for developers to discover services, owners, docs, SLOs, dependencies, runbooks. The “front door” of the platform. Backstage (Spotify OSS, CNCF incubating), Port, Cortex, OpsLevel, Roadie (hosted Backstage)
2. Scaffolding & golden-path templates Creates new services / repos / pipelines with sensible defaults baked in — the paved road, expressed in code. Backstage Scaffolder, Cookiecutter, Copier, Projen, internal generators
3. Workload specification & orchestration The tenant-facing declarative interface: “I need a service with these resources” → platform resolves the declaration into concrete cloud + Kubernetes state. Score (CNCF Sandbox spec), Humanitec (platform orchestrator), Kratix, Crossplane, Radius (Microsoft), KusionStack, CUE-based orchestrators
4. Continuous delivery & GitOps Ships code and config from git push to running workloads; keeps cluster state reconciled. Flux (CNCF graduated), Argo CD (CNCF graduated), Spinnaker (Netflix OSS), Tekton, reusable GitHub Actions workflows
5. Runtime & supporting plane The compute and day-2 concerns: clusters, networking, ingress, secrets, autoscaling, certs. GKE / EKS / AKS; Istio / Linkerd; KEDA; External Secrets Operator; cert-manager
6. Policy, supply chain, observability The non-negotiable floor: admission policy, image signing, SBOMs, metrics / logs / traces. Kyverno, OPA / Gatekeeper, Kubewarden; Sigstore / cosign, SLSA, in-toto; Prometheus / VictoriaMetrics; Grafana; OpenTelemetry

Two architectural patterns that shape the stack

Two cross-cutting patterns define most modern platforms.

Platform orchestrator pattern. A tenant declares intent (workloads + required resources) in a single config file; the platform translates that declaration into the underlying IaC modules and Kubernetes manifests; CI pipelines sync the generated artefacts to the cloud. Humanitec popularised the term and ships a commercial implementation, but the pattern is increasingly built in-house. The orchestrator is where the platform’s opinionated decisions live: which resources tenants can self-service, what defaults apply, what validation runs before provisioning.

Workload specification as a standard. A deliberately minimal, tool-agnostic spec for what a workload is (image, ports, resource dependencies) that multiple orchestrators can consume. Score is the emerging open standard — explicitly designed to be implemented by Humanitec, Kubernetes-native tools, Nomad, etc. Adopting a spec standard (even an in-house one) lets tenants stay portable across platform rewrites.

sequenceDiagram
    participant T as Tenant
    participant S as Spec (Score / CUE / YAML)
    participant O as Orchestrator
    participant G as GitOps Engine
    participant R as Runtime

    T->>S: declares workload + resources
    S->>O: feeds spec
    O->>O: resolves defaults, validates, picks IaC modules
    O->>G: emits Terraform JSON + K8s manifests
    G->>R: reconciles desired state
    R-->>T: workload running with paved-road defaults

Case studies — what other organisations have built

Short snapshots of platforms at companies that have published enough about their work to learn from.

Spotify — Backstage

A unified developer portal that catalogues every service, owner, doc, pipeline, and SLO across Spotify engineering. Open-sourced in 2020; now a CNCF incubating project with wide adoption (American Airlines, Expedia, HP, Mercedes-Benz, Siemens and 3,400+ others). Established the “developer portal” as its own layer — not an accessory to CI/CD — and showed that a catalogue-first approach scales across hundreds of services and thousands of engineers.

→ Pia Nilsson, No More Manuals: The Secret to Spotify’s Speedy Microservices Development; Stefan Ålund, What the Heck Is Backstage Anyway?; backstage.io — adopters. Detailed treatment in Backstage and Developer Portals.

Netflix — Paved Road and full-cycle developers

A deep internal platform (Spinnaker for delivery, Titus for containers, Atlas for metrics, plus a large library of paved-road services) that Netflix engineers use by default. “Full-cycle developers” own their services end-to-end — on top of the paved road. The canonical statement of “you build it, you run it” on top of a platform, not instead of one.

→ Greg Burrell, Full Cycle Developers at Netflix; Dianne Marsh, How We Build Code at Netflix; Netflix Tech Blog. Detailed treatment in Golden Paths and Paved Roads.

Zalando — Radical Agility → shared Kubernetes platform

Started with “Radical Agility” (radically autonomous teams, cluster-per-team) and evolved toward a shared Kubernetes platform as the cost of unconstrained autonomy became clear. A rich case study of the arc every scaling platform team eventually traverses — too much autonomy without a paved road, then a migration toward shared platform capabilities without sacrificing team ownership.

→ Henning Jacobs, A Year of Kubernetes at Zalando; Running Kubernetes in Production; engineering.zalando.com.

Monzo — platform engineering at scale

~2,000-microservice platform on Kubernetes + Linkerd + an internal RPC abstraction. Heavy use of code generation, linting, and a strong service-template approach to keep the service topology legible with a small platform team. Demonstrates how a disciplined abstraction layer (RPC + templates) lets a small platform team support a very large service count without collapsing under coordination overhead.

→ Suhail Patel, The Trillion Dollar Payment Network; Building a Modern Bank Backend; monzo.com/blog/technology.

Mercedes-Benz — self-service Kubernetes fleet

Mercedes-Benz Tech Innovation runs nearly 1,000 Kubernetes clusters for the group with a platform team of about 30. Moving from Terraform-managed clusters to Cluster API made cluster creation self-service in ~15 minutes; Backstage was later adopted as the portal on top. A European, non-web-native example of platform engineering at enterprise scale.

→ CNCF case study: Mercedes-Benz; The Backstage Chronicles (mercedes-benz.io, 2025).

Adevinta — Common Platform

Common Platform serving 50+ marketplace product teams across Europe, built on Kubernetes with a strong paved-road philosophy and explicit platform SLOs. A European marketplace case with public writing on platform evolution, SLOs, and cost as a product dimension.

→ The Journey to Building the Adevinta Common Platform; Adevinta Tech Blog; platformengineering.org talks library.

Humanitec — GCP reference architecture

A vendor-neutral reference architecture for building an IDP on GCP, published by the team behind the “platform orchestrator” pattern. The closest thing to a “textbook” answer for an opinionated GCP IDP — useful as an external check on architectural choices.

→ Humanitec, GCP Platform Reference Architecture; Kaspar von Grünberg, What Is a Platform Orchestrator?; humanitec.com/blog.

At a glance

Organisation Problem Key platform move Lesson
Spotify Nobody knew who owned what Catalogue-first portal (Backstage) Discoverability before automation
Netflix Full ownership overwhelmed teams Paved road of shared services Autonomy needs a deep platform
Zalando Cluster-per-team sprawl Shared Kubernetes platform Autonomy without a road is entropy
Monzo 2,000 services, small team Strict templates + RPC abstraction Homogeneity is a feature
Mercedes-Benz Hundreds of hand-run clusters Cluster API self-service The runtime is a product too
Adevinta 50+ product teams, many markets Common Platform with SLOs Reliability promises build trust

Common threads across all of them

  • Catalogue-first. Every successful large-scale platform puts a service catalogue at the front of the funnel. Backstage dominates the OSS choice; Port and Cortex lead the commercial space.
  • One declarative interface for tenants. Whether it is Backstage Software Templates, Humanitec manifests, Score specs, or in-house CUE files — the tenant declares intent once; the platform resolves it into concrete infrastructure.
  • GitOps for cluster and infra state. Every modern platform is GitOps-driven or converging toward it. Flux and Argo CD are the two defaults.
  • Policy and supply chain enforced at the cluster boundary, not at code review. Kyverno / OPA / cosign / SLSA enforce what humans used to eyeball in PRs.
  • Platform SLOs. Every mature team publishes reliability contracts for the platform itself — pipeline success rate, deploy time, environment provisioning time, portal availability.

The specific choices vary; the pattern is the same.

What changed in 2025–2026

The fundamentals above are stable. Five things moved:

  1. Agents became platform tenants. AI coding agents now scaffold services, open PRs and trigger platform actions. Portals expose their catalogue and actions over MCP (Backstage Actions Registry, Port, Cortex). The new rule: agents use the same contract, RBAC and audit trail as humans.
  2. DORA 2025 tied AI results to platform quality. “Quality internal platforms” is one of seven capabilities in the DORA AI Capabilities Model; AI amplifies strong delivery systems and magnifies weak ones. DORA also dropped the elite/high/medium/low tiers for seven team archetypes.
  3. Core CNCF building blocks matured. Crossplane graduated (Nov 2025), Kyverno graduated (Mar 2026), and Tekton moved from the CD Foundation into the CNCF as an incubating project (Mar 2026).
  4. The portal market split three ways. Backstage (open framework, plus hosted Spotify Portal and Roadie), Port (data model + self-service, “agentic engineering platform”) and Cortex (standards and engineering metrics). See Developer Portals.
  5. The 2nd edition of Team Topologies (2025) refreshed the vocabulary with new case studies, but the four team types and three interaction modes are unchanged.

When this discipline applies

✅ Use platform engineering when:

  • You have multiple stream-aligned teams (typically 5+) shipping software in parallel.
  • Cognitive load of cloud + Kubernetes + observability + supply chain is slowing teams down.
  • You see inconsistent reliability, security, and cost outcomes across teams.
  • You want standardisation without central bottlenecks — a paved road they can opt into, not a gate they must pass through.

❌ Don’t invest in heavy platform engineering when:

  • You have a single product team and direct tooling already works.
  • Your bottleneck is product-market fit, not delivery speed.
  • You don’t yet have the engineering volume to justify a platform team (roughly: 30+ engineers, 10+ services).
  • You’d be building before discovering — invest in 2-3 stream-aligned teams first to learn what they actually need paved.

References

Books

  • Matthew Skelton & Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, 2nd ed., IT Revolution, 2025. → itrevolution.com
  • Camille Fournier & Ian Nowland, Platform Engineering: A Guide for Technical, Product, and People Leaders, O’Reilly, 2024.
  • Betsy Beyer et al., Site Reliability Engineering & The SRE Workbook, Google / O’Reilly. → sre.google/books
  • Nicole Forsgren, Jez Humble, Gene Kim, Accelerate, IT Revolution, 2018.

Articles and talks

Frameworks and reference architectures

Reports

Engineering blogs (case studies)

Software Architecture, Platform Engineering
system-design team-building
This post is licensed under CC BY 4.0 by the author.