"Infrastructure as a Product"
In the Platform model, SREs don't touch application code at all. Instead, they build and maintain the Internal Developer Platform (IDP) — the shared infrastructure that all product teams use.
What the platform includes:
- Kubernetes clusters with standardized deployment manifests
- CI/CD pipelines (e.g., a standard GitHub Actions workflow that any team can adopt)
- Centralized observability: metrics (Prometheus), logs (Loki or Elasticsearch), traces (Jaeger or Tempo)
- Self-service databases, queues, and secret management
- A "Golden Path" — an opinionated, well-documented way to deploy a new service that works correctly out of the box
The customer relationship:
Platform SREs treat product developers as their customers. They write internal documentation, run office hours, and measure their success by developer adoption and satisfaction — not by uptime of any single service. A Platform SRE team might publish an internal SLA: "Our Kubernetes clusters will have 99.9% API availability. Our CI/CD pipelines will complete builds in under 10 minutes."
Why it scales:
A team of 5 Platform SREs can support 500 developers if the platform is automated enough. Each improvement to the platform benefits every team simultaneously. This is the highest-leverage model for growing organizations.
The context gap — the critical failure mode:
Platform SREs may not understand why a specific application is behaving badly in production. If the Payments team's service is crashing, the Platform SRE can tell you the pod is OOMKilled, but they may not know that the Payments team's code has a memory leak triggered by a specific transaction pattern. This is why mature organizations combine Platform SRE with either Embedded or Consulting SREs for their most critical services.
A common interview question is: "What's the difference between a Platform Engineering team and an SRE team?" The honest answer is that the boundary is blurry and org-dependent. A strong response: "Platform Engineering focuses on developer experience and self-service tooling — the 'paved road.' SRE focuses on reliability outcomes — SLOs, error budgets, incident response. In practice, a Platform SRE team does both: they build the platform AND define the reliability standards that run on it. The key distinction from traditional Ops is that both are engineering disciplines, not ticket-processing functions."