Kubernetes: when you need it, and when you don't

Kubernetes gets adopted by a lot of teams that don't need its complexity, and skipped by some teams that genuinely would benefit — here's how to actually make that call.

What Kubernetes actually solves, precisely

Kubernetes earns its complexity when you have: multiple services that need independent scaling based on different load patterns, a genuine need for self-healing infrastructure (automatic restart and rescheduling of failed containers across a cluster), and enough operational scale that manual container orchestration would be a real bottleneck. If you have one or two services with fairly predictable, uniform load, Kubernetes solves a problem you don't have yet, at a real ongoing operational cost.

The operational cost that's easy to underestimate

Running Kubernetes well — not just standing up a cluster, but operating it reliably in production — requires ongoing expertise: understanding resource requests and limits well enough to avoid both waste and instability, managing cluster upgrades without downtime, debugging networking issues that are genuinely more complex than a simpler deployment model. For a small team, this can mean either dedicating meaningful engineering time to platform operations rather than product work, or paying for a managed offering (EKS, GKE, AKS) that reduces but doesn't eliminate this overhead.

The simpler alternatives that often fit better

For workloads that don't need Kubernetes's full feature set, we regularly recommend simpler alternatives: AWS ECS or Fargate for container orchestration without the full Kubernetes API surface and operational complexity, or even simpler platform-as-a-service options (Render, Railway, AWS App Runner) for teams that want deployment simplicity over infrastructure control. These trade some flexibility for meaningfully lower operational burden — a real tradeoff, but often the right one at smaller scale.

A concrete decision framework we actually use

We evaluate against a few concrete questions: Do you have 5+ services that need independent scaling? Does your team have existing Kubernetes expertise, or is a multi-month learning curve acceptable? Is your traffic pattern variable enough that auto-scaling based on real-time load matters, versus fairly predictable? If the answer to most of these is no, we typically recommend against Kubernetes even when a client initially requests it, because we'd rather deliver a simpler system that's reliably operated than a more "modern" one that becomes a maintenance burden.

A concrete example of each direction

For a client running a single monolithic web application with predictable traffic, we recommended against a planned Kubernetes migration and instead optimized their existing ECS Fargate setup — cutting their planned migration timeline from an estimated 4 months to about 3 weeks of configuration work, with equivalent reliability for their actual traffic pattern. For a different client running 14 microservices with genuinely independent, spiky scaling needs (some services 20x traffic during specific hours), Kubernetes was the right call, and we built out EKS with proper resource management and autoscaling — a case where the operational investment paid for itself in infrastructure efficiency within the first year.

How Ndakum approaches it

We're deliberately not Kubernetes-first in our Cloud Engineering recommendations — the architecture follows your actual workload shape and team capacity, not a default toward the most complex option.