The Platform Engineering Movement and Internal Developer Platforms

Every growing engineering org eventually builds the same thing twice: the product, and a private PaaS that only its own platform team understands. Platform engineering is the discipline that says the second thing should be designed like a product — with users, a roadmap, and measurable outcomes — and the Kubernetes ecosystem is where most of those designs now land, because Kubernetes exposes exactly the extension points a self-service platform needs.

The pitch is simple. Developers want to ship; infrastructure is complicated; a platform team packages the complicated parts behind a paved road. The failure mode is equally simple: a platform nobody uses, maintained by a team that measures its own output instead of its users’ time-to-production.

Extending Kubernetes is the substrate

The Extending Kubernetes documentation defines the toolbox, and it falls into three families:

1. Extending the API — CustomResourceDefinitions and the aggregation layer. A CRD turns your domain concept (Environment, Database, ModelEndpoint) into a first-class API object with validation, versioning, and RBAC.
2. The operator pattern — a controller that reconciles those custom resources toward reality. This is where “self-service” becomes executable: a developer creates an Environment CR, and the operator provisions namespace, quota, secrets, and GitOps wiring without a ticket.
3. Compute, storage, and networking extensions — device plugins, network plugins (CNI), and CSI drivers. Usually platform-team territory, not developer-facing, but they define the capabilities the platform can offer.

A minimal taste of (1) and (2) together:

apiVersion: platform.example.com/v1
kind: Environment
metadata:
  name: payments-staging
  namespace: team-payments
spec:
  tier: staging
  ttlHours: 336          # operator deletes idle environments automatically
  gitops:
    repo: acme/payments-deploy
    path: environments/staging

The operator behind it does the boring, error-prone work — namespace creation with ResourceQuota and LimitRange, certificate provisioning, OIDC group binding, Argo CD application generation, TTL-based cleanup. Crucially, it encodes policy as code: the developer cannot request an environment that violates the org’s security baseline, because the CRD’s schema and the admission policy make it unrepresentable.

This is the same pattern behind Crossplane (infrastructure claims), External Secrets Operator, cert-manager, and Argo CD — the IDP is not a new system, it is a composition of Kubernetes extension APIs with a developer-facing facade.

Backstage: the developer portal

Backstage, open-sourced by Spotify in 2020 and a CNCF project, is the dominant portal implementation. Its three core ideas:

• Software Catalog. A registry of services, APIs, resources, and owners — the answer to “what runs in production and who do I page?” It is populated automatically from annotations (backstage.io/kubernetes-id) rather than maintained by hand.
• Software Templates (the scaffolder). Golden-path templates that create repositories, CI pipelines, and catalog entries from one form. “Create a new service” becomes a two-minute operation with the right defaults pre-applied — this is where onboarding time actually collapses.
• TechDocs. Documentation-as-code, published beside the service it describes, so docs version with the code instead of drifting in a wiki.

Around that core sit plugins for Kubernetes, Argo CD, PagerDuty, Grafana — and the catalog becomes the integration point where “extend Kubernetes” meets “what should a developer see.” Backstage does not replace your platform; it is the storefront. The operators and GitOps pipelines behind it remain the machinery.

Golden paths, not gates

The term Golden Path (popularized by Spotify’s platform work) describes a supported, documented route through the organization’s technology choices — a template, a default architecture, a blessed pipeline — that teams are permitted to leave, at a cost they can see. This distinction matters: a golden path with an escape hatch gets adopted; a mandate gets worked around.

Team Topologies (Skelton and Pais) gives the org design behind it: a platform team exists to reduce cognitive load on stream-aligned teams, interacting with them primarily through an X-as-a-Service model (you consume the platform), with enabling teams on hand when a team must go off the path. If your “platform team” spends its days in collaborative ticket triage with every product team, you have the interaction modes backwards.

Self-service environments are the clearest test of the model. Done well:

• A developer creates a preview environment from a pull request and gets a URL, without asking anyone.
• The environment is a namespace with quota, network policy, and an TTL — the operator cleans up what the developer forgets.
• Promotion between environments is a Git commit, reviewed like code, not a runbook executed by a human.

Measuring outcomes, not output

A platform team that reports “we shipped 14 templates this quarter” is measuring the wrong thing. The useful metrics are developer outcomes:

Metric	What it tells you
Time from repo creation to first production deploy	Does the golden path actually work end-to-end?
Percentage of services on the paved road	Adoption — the real ROI signal
Ticket deflection / self-service success rate	Is the platform replacing toil or adding a layer?
DORA metrics for consuming teams	Deployment frequency, lead time, change failure rate, MTTR downstream
Platform NPS / internal survey	Do developers want to use it?

Notice what is absent: velocity of the platform team itself. The platform’s output is other teams’ throughput.

Anti-patterns

• The platform as a ticket queue. If every request becomes a Jira ticket for the platform team, you have not built self-service — you have renamed the ops team. Measure the ratio of automated to human-mediated requests.
• Building a bespoke PaaS from scratch. Kubernetes already provides scheduling, RBAC, networking, and extension APIs. Teams that ignore the CRD/operator toolbox end up maintaining a private cloud with worse reliability than the public one.
• Catalog-first adoption. Buying Backstage (or any portal) and expecting adoption is like buying a map and expecting the roads to be built. The portal surfaces the platform; it does not create it.
• Golden paths as compulsion. Mandating a path without supporting exceptions pushes teams to shadow IT — the exact problem you set out to solve.
• Ignoring the enabling role. Some teams genuinely need to run something non-standard (an ML training rig, a hardware-adjacent service). A platform with no escape hatch forces them around it.
• Measuring vanity output. Template counts, cluster counts, plugin counts. None of these correlate with whether shipping software got easier.

Start with one painful workflow

The pragmatic entry point is not a portal — it is one workflow that hurts today. Pick “provision a staging environment” or “create a new service,” write the CRD and operator (or the Backstage template) that automates it end to end, measure the before/after time, and publish that number. The platform grows from demonstrated wins, each one extending Kubernetes a little further in service of developers who can then answer, without opening a ticket: is my code running, and how do I ship the next change?

References

• Kubernetes — Extending Kubernetes (cited source)
• Kubernetes — Operator pattern · Custom Resources
• Backstage · Backstage Software Templates
• Team Topologies — four team types and interaction modes
• DORA — Accelerate State of DevOps metrics
• CNCF — What is platform engineering?