Internal Developer Platform (IDP) / golden paths

The product that platform-engineering builds — named here for the first time. An IDP is the self-service layer that gives application teams a paved, pre-integrated way onto the underlying kubernetes/CNCF stack, so they don’t each re-assemble (and re-pay) the kubernetes-integration-tax. First grounded by project-as-a-service (Belastingdienst).

Core ideas

• Golden paths — “making the ‘right way’ the easiest way to build software.” The platform encodes the integrated, compliant default (provisioning, RBAC, quotas, observability wiring) so the path of least resistance is also the correct one. This is the structural cure for the integration tax: pay the integration cost once, centrally, then hand teams the result.
• Platform-as-a-product — the platform is run for its internal users (developers as customers), with enablement over support (build self-sufficiency, not a ticket queue) and adoption as the success metric — not just “the cluster exists.”
• Self-service provisioning — a declarative request (e.g. one YAML) yields a ready environment via an operator/reconciler (project-as-a-service‘s opr-paas); a gitops-shaped loop applied to projects, not just app config.

Where it sits among the pillars

The IDP is the build/standardize counterpart to the other platform-ops pillars: observability tells you what’s happening, site-reliability-engineering keeps it reliable, and the IDP makes the integrated platform itself a consumable product. It reframes platform-engineering from “assemble ~20–30 tools” to “productize the assembly so teams don’t have to.” Distinct from gitops (a mechanism the IDP uses) and from a cloud provider’s managed-K8s (cloud-wiki) — an IDP is the org’s own paved road over whatever substrate.

Measured, and it cuts the other way

dora-2024-report (T2, Google Cloud / DORA, 39,000-professional program, 2024) is the first source here that measures an IDP against outcomes rather than describing what one is for. 89% of respondents use one. Using one, individuals report being 8% more productive and teams 10% better — and software delivery throughput falls ~8% while stability falls 14%, meaning change failure rate and rework rate both rise. Where the platform is mandatory for the whole app lifecycle, throughput drops a further 6%. Instability combined with a platform is also linked to higher burnout, which DORA states carefully as a combination rather than a cause.

So the productivity case and the delivery case come apart. The people using the paved road feel faster and the changes arrive slower and break more. DORA leaves three readings open: the platform adds handoffs, each one “an opportunity for time to be introduced”; the platform gives teams confidence to ship freely, so instability is a symptom of experimentation; or the platform is simply not ensuring change quality — possibly running automated tests that exercise only whatever tests the application already had.

The exclusivity number is the one this page had already predicted. The golden-cage caveat below was written from first principles in June; DORA puts −6% throughput on it.

Open caveat

“Golden path” can harden into a golden cage if the platform’s defaults lag team needs — the enablement/self-service framing is partly what keeps it a path, not a mandate. Evidence here is qualitative (project-as-a-service); onboarding-time / adoption metrics are the quantification gap.

Related

project-as-a-service · platform-engineering · kubernetes-integration-tax · gitops · platform-ops · site-reliability-engineering