Platform Engineering: From Backstage to Golden Paths

Platform Engineering has moved past the hype cycle. The 2024 Puppet State of DevOps report shows that organizations with a mature platform team report a 6x improvement in deployment frequency and measurably lower burnout among application developers. The thesis is simple: stop asking every product team to reinvent CI/CD, secrets management, observability and Kubernetes manifests. Build an Internal Developer Platform (IDP), pave golden paths, and treat developers as customers.

But between the Gartner slides and a working IDP lies a lot of YAML. Here is a pragmatic view of what a modern platform looks like, what to build, and where Backstage fits in.

What an IDP actually is (and isn't)

An Internal Developer Platform is not a single product. It is a curated self-service layer built on top of your existing infrastructure (Kubernetes, AWS/GCP, GitHub, Vault, Datadog…) that exposes opinionated workflows to developers.

A useful mental model from Humanitec is the Platform Orchestrator pattern: developers declare what they need (a service, a database, a queue), and the platform decides how to provision it per environment.

What it is not:

• A wiki of Confluence pages explaining how to deploy.
• A Jira queue where the platform team fulfills tickets manually.
• A reskinned PaaS that hides everything (developers still need an escape hatch).

The four pillars worth investing in

| Pillar | Purpose | Common tools (2025) | |---|---|---| | Developer Portal | Discovery, catalog, docs, scaffolding | Backstage, Port, Cortex | | Service templates | Golden paths, scaffolding | Backstage Software Templates, cookiecutter | | Workload abstraction | Decouple app spec from infra | Score, Crossplane, KubeVela | | Observability glue | Unified signals per service | OpenTelemetry, Grafana, Datadog |

Start with one pillar. Most teams over-engineer by trying to ship all four at once.

Backstage: powerful, but not free

Backstage (open-sourced by Spotify, now CNCF graduated as of 2024) is the de facto developer portal. It gives you:

• A software catalog with ownership metadata
• Software Templates for scaffolding new services
• TechDocs (Markdown rendered from each repo)
• A plugin ecosystem (200+ plugins: ArgoCD, Kubernetes, PagerDuty, Snyk…)

The honest part: Backstage is a TypeScript/React monorepo you have to run, upgrade, and customize. Plan for at least one dedicated engineer maintaining it, or consider managed offerings like Roadie or Spotify Portal if you want the value without the operational tax.

A minimal golden path: scaffolding a new service

Here is a trimmed template.yaml for a Backstage software template that provisions a Go microservice with CI, a Helm chart, and a registered catalog entry:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: go-microservice
  title: Go Microservice (Golden Path)
  tags: [recommended, go, kubernetes]
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service details
      required: [name, owner]
      properties:
        name: { type: string, pattern: '^[a-z0-9-]+$' }
        owner: { type: string, ui:field: OwnerPicker }
  steps:
    - id: fetch
      action: fetch:template
      input:
        url: ./skeleton
        values: { name: ${{ parameters.name }} }
    - id: publish
      action: publish:github
      input:
        repoUrl: github.com?owner=acme&repo=${{ parameters.name }}
    - id: register
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

In under 60 seconds, a developer goes from "I need a new service" to a Git repo with CI wired up, a registered owner in the catalog, and a deployable Helm chart. That is what a golden path looks like in practice.

Golden paths, not golden cages

The biggest failure mode of platform teams is enforcing a single way of doing things. Golden paths must be opinionated defaults, not mandatory rails.

A good test: can a senior engineer opt out of the platform for a specific component without filing a ticket? If the answer is no, you have built a cage. Teams will route around you, and shadow IT will reappear.

Pattern that works:

• 80% of services use the golden path (Go/Node template, standard CI, standard observability).
• 20% diverge with documented justification, still registered in the catalog.

Measuring DevEx without theater

DORA metrics are necessary but insufficient. They tell you about delivery, not about how painful it feels. Add at least two signals from the SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency):

• Time to 10th commit for a new joiner (efficiency)
• Quarterly DevEx survey with 5-7 questions (satisfaction)
• Change failure rate per golden path (performance)

If your platform team cannot show the trend on these after two quarters, you are building features, not solving problems.

A pragmatic 90-day rollout

1. Weeks 1-3: Interview 10 developers. Find the top 3 pain points (usually: bootstrapping a new service, accessing logs, getting secrets).
2. Weeks 4-8: Pick one pain point. Ship one golden path end-to-end with Backstage + a software template. Onboard 2 pilot teams.
3. Weeks 9-12: Measure (time-to-first-deploy, NPS), iterate, then expand the catalog. Only then add a second golden path.

Do not start by importing 400 services into the Backstage catalog. Nobody will look at it.

Key takeaways

• An IDP is a product, not a project. Staff it with a product manager and treat developers as users.
• Backstage is the standard, but expect real maintenance cost. Managed alternatives exist for a reason.
• Golden paths beat golden cages: opinionated defaults with documented escape hatches.
• Measure DevEx with DORA + SPACE, not just deployment counts. Survey developers quarterly.
• Start narrow: one pain point, one golden path, two pilot teams. Expand only after measurable wins.