Platform engineering: golden paths and self-service
Teams waiting on tickets for environments, pipelines and access.
Self-service golden paths with security, observability and cost built in.
Faster delivery with fewer incidents and less platform toil.
Platform engineering treats the internal platform as a product with developers as its users. Golden paths are opinionated, supported routes from idea to production: templates, pipelines and environments that already include security, observability and cost controls.
The business problem
Each team builds its own pipelines and infrastructure in its own way. Simple requests such as a new service, environment or database go through tickets and take days. Security and operations standards are applied inconsistently, and the platform team spends its time on requests rather than improvements.
Constraints
- Teams with different languages, frameworks and maturity.
- Security and compliance requirements that cannot be optional.
- A small platform team relative to the number of product teams.
- Existing workloads that cannot all be migrated at once.
Architecture
- Templates · service, data pipeline and AI app starters
- Environments · on demand, from code, with expiry for previews
- Delivery · CI pipelines and GitOps deployment
- Guardrails · security scanning and policy checks in every pipeline
- Observability · logs, metrics, traces and dashboards by default
- Cost · tags and a cost view per service from day one
- KubernetesShared, multi-tenant clusters
- Serverless and managedFunctions, queues, databases
- Data and AIWarehouse, vector stores, AI gateway
Key decisions and trade-offs
- Platform as a product: a roadmap driven by developer needs, with adoption measured rather than mandated.
- Paved, not walled: golden paths are the easiest option, with a supported way to step off them for genuine exceptions.
- Start with the highest-volume path: usually a standard web service or API, before data, AI or legacy patterns.
- Policy as code in the path: security and compliance checks run automatically, so reviews focus on exceptions.
- Thin portal, strong APIs: the portal is a front end; templates and automation work equally well from a pull request.
Measures of success
- Time for a new team to first production deploy
- Lead time and deployment frequency
- Change failure rate and time to restore
- Share of services on a golden path
- Platform tickets per team per month
Common pitfalls
- Building a portal before the underlying automation works.
- Mandating the platform before it is better than the alternatives.
- Too many options, so every path is half-supported.
- No product owner, so the platform drifts towards the platform team's preferences.