Kubernetes: When It's the Right Choice (And When You're Just LARPing)
K8s for a 5-engineer team is almost always wrong.
Kubernetes is a phenomenal tool for the right problem. It is also, in my experience, the most over-adopted tool in our industry. Here's a sharper decision framework.
Kubernetes solves a hard problem: scheduling many containers across many machines with declarative configuration, self-healing, rolling deploys, etc.
If that's not your problem, K8s is wrong for you.
When K8s is right
- You have 50+ services
- You have meaningful platform engineers (1+ FTE on infra)
- Your scaling profile is variable (auto-scaling actually does work)
- You need multi-cloud or on-prem flexibility
- Your team has K8s expertise already
When K8s is overkill
- Fewer than 10 services
- No dedicated platform person
- Static load (you don't scale)
- AWS-only or GCP-only and willing to embrace native services
- Your team's K8s expertise is "watched some YouTube videos"
What I recommend instead
For most startups (under 50 engineers, under 20 services):
- Vercel for the web tier (Next.js or whatever)
- Cloud Run (GCP) or App Runner (AWS) for backend services
- Managed Postgres (RDS, Neon, Supabase)
- Managed Redis (ElastiCache, Upstash)
You give up zero capability you actually use. You save 1-2 platform engineers worth of operational overhead.
When you've outgrown that:
- ECS Fargate is the gentle on-ramp from "managed PaaS" to "container orchestration." Less powerful than K8s but 5x easier to operate.
- EKS / GKE come into play when you need K8s-specific features (operators, custom controllers, cross-cloud)
The hidden cost of K8s
Operating K8s is a full-time job for ~1 person at any company below 200 engineers. Networking, RBAC, ingress controllers, storage classes, node upgrades, certificate rotation, monitoring stack - it's a lot.
If you can't articulate the dollar value K8s is generating for you above what Cloud Run / App Runner would give you, you're paying that operational tax for no return.
The harder truth
A lot of K8s adoption is about hiring brand and resume-padding, not engineering need. Be honest with yourself about why you're considering it. The right answer for your team is rarely the same as the right answer for Google.