How do we avoid building a bespoke platform that becomes legacy?

Keep your layer thin and boring. Reuse open tools (Backstage, ArgoCD, Terraform/OpenTofu, GitHub Actions) and avoid custom controllers until the use case hurts repeatedly. Version everything, publish deprecation notices, and keep escape hatches documented. If your CLI is 10,000 lines, you’re re-implementing the cloud—stop.

What if a team truly needs to go off the paved road?

Make it a formal RFC with success criteria and SLO/ownership. Provide extension points: custom Helm chart under a `chart/experimental/` path, terraform `extra_*` variables, and a `policy-exception.yaml` reviewed by platform + security. Time-box exceptions and revisit quarterly.

Can we do this without Kubernetes?

Yes. The same pattern works with ECS, Nomad, or even serverless. Swap ArgoCD with CodeDeploy or Spinnaker; use Terraform modules and a reusable CI workflow. The key is defaults + GitOps-style desired state.

How do we roll out without blocking current delivery?

Start with one team and one runtime. Migrate net-new services first. For existing services, offer a migration path with tooling (`gp migrate service`) and support office hours. Make the paved road faster than the old way and adoption will follow.

What should the platform team own vs. product teams?

Platform owns the golden paths, shared modules, reusable workflows, cluster/runtime health, and policy. Product teams own their service code, SLOs, on-call, and any off-road choices they opt into via RFC.

Platform-productivity · Oct 7, 2025 · 10 minute read

Stop Making Everyone an SRE: The Paved Road That Turned 90% of Infra Tickets Into Pull Requests

Your engineers don’t want to babysit IAM roles or Helm values. Give them a paved road with sane defaults, escape hatches, and guardrails—then watch cycle time drop and infra tickets disappear.

Back to all posts

Stop Making Everyone an SRE: The Paved Road That Turned 90% of Infra Tickets Into Pull Requests

Key takeaways

Implementation checklist