Part 5 · 2 chapters · ~16 min
Platform Engineering
The internal platform as a product: the problem it solves, paved roads and golden paths, the developer portal and catalogue, declarative self-service, scorecards and adoption; then running it like a product: users, measured pain, thin slices and migration, scalable support, anti-patterns, and the team's shape.
11
Paved roads, golden paths and the portal
the platform as a product teams choose
- The problem: every team builds its own stack, and infrastructure turns into a ticket queue.
- Paved road: the supported way, owned by the platform. Going off-road is allowed, and you own what you build there.
- Golden path: from nothing to a deployed, observed service in minutes.
- The portal: catalogue, templates, scorecards and live status in one place.
- Self-service through declarative APIs that encode the policy.
- Scorecards and adoption metrics, used instead of mandates.
code
# catalog-info.yaml: every service registers itself in the portal
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payments
description: Transfers, payouts and payment provider routing
annotations:
github.com/project-slug: acme/payments
pagerduty.com/service-id: P7X2Q1
grafana/dashboard-selector: "service=payments"
tags: [node, fintech, tier-1]
spec:
type: service
lifecycle: production
owner: team-payments
system: money-movement
dependsOn: [component:ledger, resource:payments-db, component:paystack-adapter]
providesApis: [payments-api]the frontend paved road
The same idea for frontends: a template that creates an app with the design system, the RUM SDK, the CI with size and Lighthouse budgets, preview deployments and flags already wired in. The Big-company FE and Design courses describe what goes on that road. This part is how it gets built and adopted.
THE INTERNAL PLATFORM AS A PRODUCT
paved roads, golden paths and a portal, built for product teams who could choose not to use them
swipe the figure sideways, or tap expand for full screen
1/6
the problem
The problem it solves: without a platform, every team assembles its own pipeline, Terraform, dashboards, alerts and runbooks; cognitive load grows with every tool; the same mistakes repeat in 40 places; and the infrastructure team becomes a ticket queue that every launch waits on.
12
Running the platform like a product
product practice, applied inward
- Know the users: product engineers, tech leads, on-call engineers, governance.
- Measure the pain: DORA, DevEx surveys and the platform's own telemetry.
- Thin slices: one team first, then the default, then migrate everyone, then retire the old way.
- Support that scales: docs, a channel, office hours, embedded engineers.
- Avoid the anti-patterns: mandates, ivory towers, ticket queues, abstractions that go too far.
- The team: small, with a PM, a roadmap, SLOs and an on-call rota.
| DORA metric | what it measures | elite (typical benchmark) | what the platform changes |
|---|---|---|---|
| deployment frequency | how often you ship to prod | on demand, many per day | pipelines, progressive delivery, small changes |
| lead time for changes | commit to running in prod | under a day | pipeline speed, review flow, automated promotion |
| change failure rate | deploys causing incidents | 0 to 15% | canaries, analysis, tests, flags |
| time to restore | incident to recovery | under an hour | rollback, observability, runbooks |
RUNNING THE PLATFORM LIKE A PRODUCT
users, research, a roadmap, a support model and the anti-patterns that kill platform teams
swipe the figure sideways, or tap expand for full screen
1/6
users
Users and their jobs: the platform's users are product engineers (shipping features), tech leads (owning services), on-call engineers (fixing them at night), security and finance (governing them). Each has jobs and pains; interviews, shadowing a deploy, and reading the support channel find them better than guessing.