Platform engineering

Product teams should spend their attention on the product. In a microservices world, they instead drown in YAML for CI, deploys, observability, IAM, networking, secrets, autoscaling, and tickets to a central ops group. Platform engineering reverses that. It offers an internal developer platform (IDP) that makes the easy path the safe path. It does not assume every company needs a homegrown Heroku.

A platform is not the Kubernetes cluster, and it is not the DevOps team. It is a product. It has curated capabilities, documentation, support and adoption metrics, and its customers are internal engineers. Done well, it cuts the time from an empty repository to a production-ready service from weeks to hours. Done badly, it becomes a mandatory bottleneck with a private PaaS that nobody can debug.

Walking through the topic

The first two pages explain why platforms exist and what a golden path is. The last four cover the product, the catalog, the build-or-buy decision and the guardrails.

Common mistakes

• Treating the platform as "ops with a new name". It needs a product owner, a roadmap and users.
• Building a portal before the paved roads. Empty chrome does not help anyone.
• Measuring tools built. Measure adoption and time to a safe deploy.
• Underfunding a custom layer. It becomes the homegrown PaaS trap.

Key takeaways

• Platforms exist to cut cognitive load and repeated toil. They are products for internal engineers.
• A golden path gets a new service to production in hours, not in a ticket maze.
• Catalogs make ownership real. Portals are the interface on top of working paved roads.
• Default to thin platforms built from upstream tools, and avoid underfunded custom dialects.
• Use scorecards for visibility and guardrails for the few baselines that matter.

Interview angle

If asked how to roll out a platform in a 40-engineer company, start with the template, then the catalog, and leave the portal's chrome for last. To judge whether it works, track time to deploy, the share of services on the path, and interviews with the teams. Be ready to say what you would not build yet, and why a thin platform beats a private PaaS at that size.

Further learning

Spotify's KubeCon talk covers evolving from spreadsheets to Backstage, from the people who open-sourced it. A second talk covers Backstage as a developer experience layer.

Backstage documentation, what is BackstageWhat is Backstage? | Backstage Software Catalog and Developer Platformbackstage.io Team Topologies key conceptsExplore key concepts of Team Topologies: four team types, interaction modes, platform-as-a-product, and more. Tools and practices included!Team Topologies - Organizing for fast flow of value