Learn to build reliability as a self-service product - golden paths, internal developer platforms, paved roads, and reliability SLAs that scale your impact across every team.
Imagine a senior SRE at a large fintech platform. She has fixed the checkout service's cascading failure problem, added circuit breakers to the payments team's code, and personally reviewed the production readiness review for three new services this quarter. She is exhausted, and there are 140 more services she has not touched. This is the ceiling every senior SRE eventually hits. One person, however skilled, cannot manually review, fix, and babysit hundreds of services. Fixing one team's reliability problem by hand does not fix the same problem for the next 50 teams who will make the exact same mistake next month. **Platform engineering** is the discipline of building reliability into reusable, self-service tooling and paved paths so that every team gets good defaults automatically, instead of needing an SRE to intervene manually every time. Think of it like city planning versus emergency response. An emergency responder saves one person at a time, one crisis at a time - vital work, but it does not stop the next crisis from happening. A city planner who designs proper drainage, wide roads, and fire-resistant building codes prevents thousands of future emergencies without ever showing up at any of them. Senior SREs doing platform work are becoming city planners. > 📌 **Remember:** The shift from senior to staff-level impact is the shift from "I fixed this service" to "I made it structurally hard for any service to have this problem." ### Why this is different from what you have already learned Earlier modules in this roadmap taught you the tools - Kubernetes reliability, SLOs, chaos engineering, incident response. This module teaches something different: how to package all of that knowledge into something 50 teams can consume without ever talking to you. It is the horizontal-impact layer sitting on top of everything you already know. ---
### What a golden path really is A **golden path** (also called a paved road) is a pre-built, opinionated, well-supported way to accomplish a common task - deploying a service, setting up monitoring, provisioning a database - that is deliberately easier to use than doing it manually. The key word is *easier*. A golden path that is merely "the approved way" but harder to use than going around it will be ignored. A golden path that is genuinely the path of least resistance gets adopted without anyone being forced to use it. Good: `## Designing Golden Paths That Teams Actually Want to Use` ### The three properties every golden path needs 1. **Opinionated** - it makes the reliability decisions for the team (probes configured, PDB set, resource limits sane) so they do not have to know the theory 2. **Faster than the alternative** - `platform new-service payments-api` in 30 seconds beats writing 200 lines of YAML by hand 3. **Not mandatory, but obviously better** - teams can still go off-road, but the golden path is so much less friction that almost nobody does > 💡 **Tip:** If your golden path requires a design review meeting to use, it is not a golden path yet. It should be closer to running an installer than requesting permission. ### A concrete example - the service scaffolding golden path At a company like Razorpay, a new service team might run one command that generates a fully reliability-compliant service skeleton: ```bash ## Scaffolds a new service with reliability defaults baked in platform new-service --name payments-refund-api --team payments ## Behind the scenes this generates: ## - Deployment with liveness/readiness/startup probes pre-configured ## - PodDisruptionBudget set to sane defaults ## - Resource requests/limits based on team's historical usage profile ## - ServiceMonitor wired to Prometheus automatically ## - PagerDuty escalation policy scaffolded from a team template ``` > **Note:** A `PodDisruptionBudget` is a Kubernetes object that limits how many pods of a service can be voluntarily taken down at once during maintenance, protecting availability during routine operations like node drains. This was covered in depth in the Kubernetes Reliability module - the platform engineering layer's job is making sure every service gets one automatically, not teaching what it does again. The engineer running this command never had to learn what a PodDisruptionBudget is to get one. That is the entire point - the platform embeds the expertise so individual engineers do not need to hold it in their heads. ### Golden paths are not one-size-fits-all A stateless API service and a Kafka consumer have different reliability needs. A single golden path trying to cover every workload type becomes a confusing pile of conditional flags nobody understands. +------------------+ +------------------+ +------------------+ | Golden Path: | | Golden Path: | | Golden Path: | | Stateless API | | Async Worker | | Stateful Service | +------------------+ +------------------+ +------------------+ | HPA + PDB | | KEDA scaling | | StatefulSet | | Readiness probe | | Dead letter queue | | PVC + backup job | | Rate limiting | | Retry + idempotency | | Failover runbook | +------------------+ +------------------+ +------------------+ Build a small number of golden paths for your most common workload shapes rather than one golden path trying to serve everyone. > 🔴 **Common Mistake:** Building a golden path that is more complex than the manual process it replaces, because it tries to be infinitely configurable. A golden path with 40 optional flags is not a golden path - it is documentation with extra steps. Keep the defaults strong and the required inputs minimal. ---
### What an IDP actually is An **internal developer platform** (IDP) is the collection of self-service tools, APIs, and interfaces that let engineering teams provision infrastructure, deploy services, and get observability without filing a ticket or waiting on a platform team to do it for them. The analogy is a hotel versus a construction site. A construction site requires you to bring your own tools, know the building codes, and coordinate every step with specialists. A hotel gives you a room that already has electricity, water, and safety compliance built in - you just walk in and use it. An IDP is the hotel; manually configuring Kubernetes YAML by hand every time is the construction site. ### Why IDPs exist - the problem before them Without an IDP, every team either: * Waits in a queue for the platform/SRE team to provision what they need (slow, does not scale past a handful of teams) * Learns Kubernetes, Terraform, and observability tooling themselves (inconsistent quality, duplicated mistakes across teams) Neither scales past roughly 20-30 engineering teams. An IDP is what lets a platform team of 8 people support 150 product teams without becoming the bottleneck for every single deployment. ### Core components of a typical IDP | Component | What it does | Example tool | |:---|:---|:---| | Service catalog | Central registry of every service, owner, and dependency | Backstage | | Self-service provisioning | Request infra without a ticket | Crossplane, Terraform modules | | CI/CD templates | Pre-built pipelines with security and quality gates | Reusable GitHub Actions/GitLab CI templates | | Observability wiring | Auto-instrumented dashboards and alerts on deploy | OpenTelemetry auto-injection | | Environment management | Spin up/tear down test environments on demand | Preview environments per pull request | > **Note:** Backstage is an open-source framework, originally built at Spotify, for building a service catalog and developer portal. It is mentioned here as a concrete example - the concept of a service catalog matters more than any specific tool. ### The service catalog as the platform's foundation Every IDP needs one source of truth answering: what services exist, who owns them, what do they depend on, and what is their current reliability status. +------------------------------------------+ | SERVICE CATALOG | +------------------------------------------+ | payments-refund-api | | Owner: payments-team | | SLO: 99.9% availability | | Depends on: auth-service, ledger-db | | PRR status: PASSED | +------------------------------------------+ | notification-service | | Owner: growth-team | | SLO: 99.5% availability | | Depends on: user-service, sms-gateway | | PRR status: NOT STARTED | +------------------------------------------+ Without a catalog like this, "which services depend on the ledger database" becomes a Slack archaeology exercise during every incident instead of a five-second lookup. > 📌 **Remember:** As covered in the Incident Management module, defining blast radius quickly is critical during an incident. A service catalog with dependency mapping is what makes blast radius something you can look up in seconds instead of guessing under pressure. ---
### Why the platform team needs its own SLA If platform engineering is a product, the teams consuming it are customers, and customers need to know what they can rely on. A **platform SLA** is a commitment the platform team makes to the teams building on top of it - build pipeline availability, provisioning turnaround time, on-call response time for platform-caused incidents. Without this, the platform team is trusted informally until the first time it fails someone during an incident, at which point trust collapses and teams start building workarounds that duplicate the platform's own tooling. Good example platform SLA commitments: * CI/CD pipeline availability: 99.5% measured monthly * New service provisioning: complete within 10 minutes of request * Platform-caused incident acknowledgment: within 15 minutes during business hours > 💡 **Tip:** Treat the platform team's own SLOs with the same rigor taught in the Observability module - define SLIs, set error budgets, and alert on burn rate for the platform itself, not just for the product services it supports. ### Making the reliable way the easy way The core cultural goal of platform engineering is captured in one sentence: the reliable way should require less effort than the unreliable way, not more. If following best practice means writing 200 extra lines of YAML while skipping it means shipping in 5 minutes, most engineers under deadline pressure will skip it - not because they do not care about reliability, but because the incentive structure rewards speed. A good platform inverts this, making the golden path the fast path. > 🔴 **Common Mistake:** Platform teams that gate golden paths behind mandatory manual reviews for every use, turning what should be self-service into another queue. This defeats the entire purpose - the review belongs in the platform's automated checks, not in a human approval step for every request. ---
A platform that nobody uses has failed regardless of how well-engineered it is. Track adoption and impact deliberately, the same way you would track SLO compliance for a product service. | Metric | What it tells you | |:---|:---| | Golden path adoption rate | Percentage of new services using the paved road vs going off-road | | Time to first deploy | How long a new team takes to ship their first service | | Toil hours saved per quarter | Direct link back to the toil elimination concepts from earlier in this roadmap | | Platform-caused incidents | Whether the platform itself is becoming a reliability risk | | Developer satisfaction score | Quarterly survey - are teams choosing the platform or avoiding it | > **Note:** As covered in the Toil Elimination module, toil is measured directly in hours saved per week. Platform engineering is one of the highest-leverage ways to eliminate toil at scale, because a single golden path improvement removes the same toil for every team that adopts it, not just one team. ---
Complete these steps in order to build a working golden path scaffold for a stateless API service. 1. Create the project structure for a scaffolding CLI tool. ```bash ## Set up an isolated environment for the platform CLI project mkdir platform-cli && cd platform-cli python3 -m venv venv source venv/bin/activate pip install click pyyaml ``` 2. Write the scaffolding script that generates a reliability-compliant Kubernetes manifest from minimal input. ```python ## scaffold.py - generates a Deployment with reliability defaults baked in import click import yaml def build_deployment(name, team, replicas=3): """ Generates a Kubernetes Deployment manifest with reliability defaults already applied, so the requesting team does not need to know the theory behind probes, PDBs, or resource limits. """ return { "apiVersion": "apps/v1", "kind": "Deployment", "metadata": { "name": name, "labels": {"team": team, "managed-by": "platform-cli"} }, "spec": { "replicas": replicas, "selector": {"matchLabels": {"app": name}}, "template": { "metadata": {"labels": {"app": name}}, "spec": { "containers": [{ "name": name, "image": f"registry.internal/{team}/{name}:latest", # Sane defaults so a new engineer doesn't need # to know what values are safe to pick "resources": { "requests": {"cpu": "100m", "memory": "128Mi"}, "limits": {"cpu": "500m", "memory": "512Mi"} }, "readinessProbe": { "httpGet": {"path": "/healthz", "port": 8080}, "initialDelaySeconds": 5 }, "livenessProbe": { "httpGet": {"path": "/healthz", "port": 8080}, "initialDelaySeconds": 15 } }] } } } } @click.command() @click.option("--name", required=True, help="Service name") @click.option("--team", required=True, help="Owning team") def new_service(name, team): """Scaffold a new service with reliability defaults pre-applied.""" deployment = build_deployment(name, team) filename = f"{name}-deployment.yaml" with open(filename, "w") as f: yaml.dump(deployment, f, default_flow_style=False) click.echo(f"Generated {filename} with reliability defaults for team '{team}'") if __name__ == "__main__": new_service() ``` 3. Run the scaffolder to generate a manifest for a sample service. ```bash python scaffold.py --name payments-refund-api --team payments ## Expected output: Generated payments-refund-api-deployment.yaml with reliability defaults for team 'payments' ``` 4. Inspect the generated file to confirm the reliability defaults are present. ```bash cat payments-refund-api-deployment.yaml ``` 5. Validate success - open the generated YAML and confirm it contains `readinessProbe`, `livenessProbe`, and resource `requests`/`limits` without the user having specified any of them manually. This is the entire value proposition of a golden path in miniature. > ✅ **Validation:** If the requesting engineer only typed a name and a team, and the output file already has correct probes and resource limits, the golden path is doing its job - it embedded the reliability expertise so nobody has to hold it in their head. ---
Imagine a senior SRE at a large fintech platform. She has fixed the checkout service's cascading failure problem, added ...
What a golden path really is A golden path (also called a paved road) is a pre-built, opinionated, well-supported way to...
What an IDP actually is An internal developer platform (IDP) is the collection of self-service tools, APIs, and interfac...
Why the platform team needs its own SLA If platform engineering is a product, the teams consuming it are customers, and ...
A platform that nobody uses has failed regardless of how well-engineered it is. Track adoption and impact deliberately, ...
Complete these steps in order to build a working golden path scaffold for a stateless API service. Create the project st...
Term What it solves Where it lives Golden path Making the reliable way the fast way CLI scaffolds, service templates Int...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.