11.6 Platform Engineering & Developer Self-Service

11.6 Platform Engineering & Developer Self-Service

Quick Answer: Platform engineering is the discipline of building an Internal Developer Platform (IDP) on top of Kubernetes so that application teams get golden paths — opinionated, self-service, paved routes to production — instead of being handed raw YAML and a cluster endpoint. Backstage (CNCF incubating) provides the developer portal; Crossplane (CNCF graduated) turns the cluster into a control plane for cloud infrastructure; the DORA metrics tell you whether any of it is working.

This matters to KCNA because it explains why the ecosystem keeps producing abstraction layers. Kubernetes is a platform for building platforms, not an end-user product.

---

1. The Cognitive Load Problem

To ship one service safely on raw Kubernetes, a developer must produce and understand:

Deployment · Service · Ingress or HTTPRoute · ConfigMap · Secret · ServiceAccount
Role + RoleBinding · NetworkPolicy · HPA · PodDisruptionBudget · resource requests
readiness/liveness/startup probes · securityContext · topology spread · Helm chart
CI pipeline · image scanning · signing · GitOps application manifest · dashboards
alert rules · SLOs · runbook

That is a full-time specialism, and asking every product engineer to master it produces three predictable outcomes: copy-pasted manifests nobody understands, wildly inconsistent quality between teams, and a platform team that becomes a ticket queue and therefore a bottleneck.

Platform engineering treats this as a product problem: the platform team's customers are internal developers, and the product is a paved path.

---

2. Golden Paths

A golden path is the supported, opinionated route to production for a common case — "a stateless HTTP service in Go" or "a scheduled batch job". Choosing it should give you, without a ticket:

• a repository scaffolded with a working build,
• a CI pipeline that already scans, signs, and publishes,
• manifests generated from a template with sane defaults for probes, requests, PDBs, and NetworkPolicy,
• a GitOps registration so it deploys,
• dashboards, alerts, and an on-call routing entry created automatically.

The defining characteristic is that a golden path is the easy option, not the mandatory one. Teams with genuinely unusual requirements can step off it and take on the extra work themselves. A platform that forbids deviation gets routed around, and shadow platforms are worse than no platform.

---

3. Backstage

Backstage, contributed to the CNCF by Spotify and currently an incubating project, is the most widely adopted developer portal. Three capabilities carry most of the value:

A plugin architecture surfaces CI status, Kubernetes workload health, cost data, security findings, and on-call rotation on the same component page — one pane instead of eight browser tabs.

The catalogue is described by a YAML descriptor committed alongside the code:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payments-api
  annotations:
    backstage.io/kubernetes-id: payments-api
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: checkout
  dependsOn: [component:postgres-orders, component:auth-api]

---

4. Crossplane

Applications need more than Pods: a managed database, an object storage bucket, a message queue, a DNS record. Crossplane — CNCF graduated — extends the Kubernetes API so that cloud infrastructure is managed as Kubernetes objects, reconciled by the same control loop as everything else.

The pattern is the one from section 5.3, applied to infrastructure:

1. A provider installs CRDs for a cloud's resources (RDSInstance, Bucket, SQSQueue).
2. A platform team authors a Composition and a CompositeResourceDefinition that bundle those primitives into a simple, opinionated claim.
3. A developer creates the claim; Crossplane reconciles the real infrastructure and writes the connection details into a Secret.

apiVersion: platform.example.com/v1alpha1
kind: PostgresInstance          # a claim defined by the platform team
metadata:
  name: orders-db
spec:
  parameters:
    size: medium
    version: "16"
  writeConnectionSecretToRef:
    name: orders-db-conn

Those eight lines expand, behind the scenes, into a VPC-attached managed database with encryption, backups, a parameter group, and an access policy — all chosen by the platform team once. The developer never writes Terraform and never opens a ticket. Because the claim is a Kubernetes object, it also inherits RBAC, GitOps, and audit logging for free.

---

5. Where Abstraction Layers Fit

A useful heuristic: expose the smallest surface that still lets a team do their job, and make the next layer down available when they need it. Abstractions that cannot be opened up become the thing everyone fights.

---

6. Measuring the Platform: DORA

The four DORA metrics from the DevOps Research and Assessment programme are the standard evidence that a platform is helping:

The first two measure throughput, the last two stability, and the central research finding is that they are not in tension: teams that deploy more often also fail less often, because small changes are easier to verify and to reverse. That result is the empirical justification for continuous delivery, progressive rollouts, and platform investment. A fifth measure, reliability, is often added to capture whether the service actually meets its SLOs.

Platform teams increasingly track developer experience alongside DORA — time to first deploy for a new engineer, time waiting on the platform team, and satisfaction surveys — because a platform can improve deployment metrics while making engineers miserable.

---

7. Common Failure Modes