Most teams don’t need Kubernetes. I’ve had this conversation enough times now to just come out and say it.
Here’s a quick decision framework. If you answer no to more than two of these, you should stay where you are:
- Are you running services across multiple physical machines?
- Do you have dedicated infrastructure people (at least 3-5)?
- Are you deploying dozens of services, not a handful?
- Do you need canary releases, traffic shifting, or multi-region deployment?
- Can you afford months of upskilling before you see any return?
If that’s mostly nos, Docker Compose is doing its job. Keep using it.
We talked a startup out of Kubernetes last year
A SaaS startup asked us to help them move to Kubernetes. They had 4 services and 2 developers. We talked them out of it. They’re still on Docker Compose and shipping faster than ever.
That’s not unusual. We’ve seen teams adopt Kubernetes because it felt like the professional thing to do, then spend six months fighting YAML instead of building product. The operational overhead is real: upgrades, security patches, capacity planning, debugging network policies at 2am. You’re trading application complexity for infrastructure complexity, and that trade only makes sense at a certain scale.
The middle ground everyone skips
Between Compose and Kubernetes there’s an entire category of managed container services that most teams overlook:
- ECS on AWS: define tasks and services, let AWS handle the cluster
- Cloud Run on Google: serverless containers, pay for what you use
- Fly.io: deploy containers globally with minimal ops overhead
These give you orchestration without requiring you to become a Kubernetes shop. For most growing teams, one of these is the right answer.
When Kubernetes makes sense
I’m not anti-Kubernetes. We run it for clients and it’s brilliant when the situation calls for it. That situation looks like:
- Dozens of microservices, not five
- A platform team who can own the infrastructure full-time
- High deployment frequency with real requirements around zero-downtime updates
- Multi-cloud or hybrid infrastructure
- Complex networking needs: service meshes, traffic splitting, security policies
If that sounds like your organisation, Kubernetes will pay for itself. If you’re squinting to make your setup fit that description, it won’t.
The actual risk
The biggest mistake isn’t staying on Docker Compose too long. It’s adopting Kubernetes too early and grinding your team to a halt. I’ve watched it happen. Small teams get buried in tooling sprawl: Helm charts, operators, CRDs, observability stacks, and forget they were supposed to be building a product.
Grow into Kubernetes when you need it. Not when a blog post or a conference talk makes you feel like you should.
Grow into Kubernetes when you need it. Not when a blog post or a conference talk makes you feel like you should.