Do You Actually Need Container Orchestration?

Kubernetes solves problems that mostly appear above a certain scale. Below that line it adds a full-time operational surface for benefits you were already getting. Here is how to tell which side of the line you are on.

What orchestration actually gives you

Five things: scheduling containers across machines, restarting them when they die, rolling deploys with health checks and rollback, service discovery and load balancing between them, and declarative configuration you can keep in version control. If you need all five, you need an orchestrator. If you need two of them, there is almost certainly a smaller tool.

The threshold questions

• How many machines? One, and orchestration is pure overhead. Two or three, and a process manager plus a load balancer is enough. Beyond about five machines with varied workloads, manual placement becomes the bottleneck.
• How many distinct services? Under five, docker compose on a single host genuinely works, including in production.
• Does traffic vary by more than 5x within a day? Autoscaling is one of the few features with no cheap substitute.
• Do you have someone who will own the cluster? Not "has used it" — owns upgrades, certificate rotation, node pool churn and the 3am page. Without that person, a cluster is a liability.

What Kubernetes really costs

The control plane on a managed service is a fixed monthly fee per cluster (roughly $70-75 on the major providers, sometimes free on smaller ones), plus nodes. The larger cost is human: you now maintain manifests or Helm charts, an ingress controller, cert-manager, a metrics stack, secrets management and an upgrade cadence where minor versions leave support roughly every year. Expect a quarter of an engineer's time on an established small cluster, more while learning. Managed control plane means managed control plane — everything above it is still yours.

The options between compose and Kubernetes

Docker Compose on one host — with restart policies, healthchecks and a reverse proxy that reloads on container changes, this runs a real production service. Deploy is git pull && docker compose up -d. The limitation is honest: one machine, and deploys are not zero-downtime without extra work.

Docker Swarm — multi-host scheduling, rolling updates and overlay networking with almost the same YAML you already have. Development is quiet, but it is stable and it is by far the smallest step up from compose.

Nomad — a single binary that schedules containers, plain binaries and VMs. Substantially simpler to operate than Kubernetes; smaller ecosystem.

ECS on Fargate — AWS runs the scheduler and the nodes; you write task definitions. Less flexible and cloud-locked, but the operational load is close to zero.

Platform-as-a-service — Fly.io, Render, Railway and similar. You give them a Dockerfile and they handle everything else. More expensive per unit of compute, cheaper than an engineer.

The honest test

Write down the last five production incidents. If none of them would have been prevented by automatic rescheduling, autoscaling or a faster rollback, orchestration is not your constraint. If three of them were "the server filled up and nothing restarted it", the smallest fix is a systemd unit with Restart=always and a disk alert, not a cluster.

If you do adopt it, adopt it narrowly

Use a managed control plane. Keep stateful services — databases especially — outside the cluster on managed offerings, because running Postgres in Kubernetes is a specialist skill with a bad failure mode. Start with plain manifests plus Kustomize before reaching for Helm. Set resource requests and limits on every workload from day one, since an unbounded pod evicting its neighbours is the most common self-inflicted outage.