Platform Engineering and Internal Developer Platforms
Here’s the problem that platform engineering actually solves. You’ve adopted Kubernetes, CI/CD pipelines, cloud-native tooling, and DevOps practices – and now your developers are slower than before, not faster. Every new service requires learning a dozen tools, filling out manual security forms, and coordinating with an infrastructure team that’s swamped with provisioning requests. Platform engineering fixes that by building an internal developer platform (IDP): a self-service layer that gives your application teams a path from code to production without making them infrastructure experts.
The Internal Developer Platform Flow
IDPs reduce cognitive load on developers — they get a self-service path to production without learning Kubernetes internals.
The core of an IDP is a service catalog and a workflow engine. Backstage – originally built at Spotify and now a CNCF project adopted by companies like Zalando, Expedia, and American Airlines – is the leading open-source framework for building IDPs. It gives teams a central portal to register services, view ownership and dependencies, access documentation, scaffold new services from templates, and track production health in one place. Above the catalog, ArgoCD and Flux handle GitOps-based continuous delivery, and tools like Crossplane manage infrastructure provisioning through Kubernetes-native APIs (so your developers can request a PostgreSQL database the same way they request a Kubernetes Deployment). Score is worth watching too – it’s an emerging platform-agnostic YAML standard that lets developers describe what a workload needs, and the platform figures out how to provision it for Kubernetes, Docker Compose, or cloud resources.
DORA Metrics: Before vs After Internal Developer Platform
Elite performing teams (DORA elite) deploy on-demand multiple times per day — IDPs are the tooling investment that makes this reproducible.
The organisational model matters as much as the tooling – in practice more. Platform teams that treat their IDP as a product (running user research with developer teams, maintaining SLAs for platform APIs, prioritising based on adoption data) consistently outperform teams that just shipped a Backstage instance and called it done. The metric that actually matters is “cognitive load”: how much infrastructure knowledge does a developer need to deploy a service? Teams that measure this seriously report that onboarding a new service to production drops from weeks to hours, compliance checks get automated into the golden path rather than bolted on at the end, and senior infrastructure engineers stop spending 80% of their time on manual provisioning requests.
Frequently Asked Questions
What is an internal developer platform?
An IDP is a curated set of tools, workflows, and self-service interfaces that application developers use to build, test, deploy, and operate their services. It hides infrastructure complexity – Kubernetes, cloud APIs, security scanning – behind standardised templates and automated pipelines so developers focus on writing product code.
How is platform engineering different from DevOps?
DevOps is a cultural philosophy about shared responsibility between development and operations. Platform engineering is a specific organisational pattern where a dedicated team builds the tooling that makes DevOps practices practical for everyone else. Platform engineers are the team that enables DevOps at scale.
What is Backstage and why has it become so popular?
Backstage is an open-source developer portal framework created by Spotify and donated to the CNCF. Its plugin-based architecture lets you build a central hub for service catalogs, documentation, CI/CD pipelines, and software templates. It’s popular because it solves a universal problem – scattered tooling and missing documentation – with a flexible, extensible framework rather than a prescriptive product.
What metrics show that a platform engineering investment is paying off?
The most meaningful metrics are DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore service), time to onboard a new service to production, and developer experience surveys measuring cognitive load. A reduction in infrastructure-related support tickets is also a strong signal.
