The "Kubernetes everywhere" phase ended. The mature take is more interesting and more useful.
For half a decade Kubernetes was the assumed answer to "where do we run this?" That phase has passed. The ecosystem learned what Kubernetes is good at and what it is not, and the result is a more pragmatic toolkit.
When Kubernetes is the right answer
- You run 50+ services across multiple regions and need uniform deployment, rollout, and rollback patterns.
- You have an SRE or platform team to operate it. Kubernetes has an operational complexity floor that small teams cannot pay.
- You need workload portability across clouds — Kubernetes is genuinely the same on AWS, GCP, and Azure.
- You run stateful data workloads (databases, queues) and need StatefulSets with persistent volumes.
When Kubernetes is overkill
- You run 1-10 services and a single team owns them. Use Fly.io, Render, Railway, or just Docker on a VM.
- Your workload is request-response with auto-scale needs. Use Lambda, Cloud Run, or Azure Functions.
- Your team is small and does not have on-call SRE coverage. The Kubernetes failure modes will eat you.
The middle path
Many teams that started on Kubernetes are migrating to Cloud Run, ECS Fargate, or App Runner. These are managed container runtimes that give you 90% of the Kubernetes experience without the cluster operations. For most workloads this is the right level.
What we recommend in 2026
- Tier 1 (startups, small teams): Cloud Run / Fly.io / Render.
- Tier 2 (mid-stage, single team): ECS Fargate or Cloud Run with a CI/CD pipeline.
- Tier 3 (enterprise, platform team): Kubernetes (EKS / GKE / AKS) with proper Argo CD GitOps and a dedicated SRE function.
What we no longer recommend
Self-managed Kubernetes on EC2 / GCE for any team that is not Google or Spotify. Even with managed control planes, the cognitive load is real. Spend the engineering hours on your product, not on etcd backups.