Kubernetes Is Worth It Only If You Need What It Does
Container orchestration solved a set of real problems for organisations running many services across many machines. It then became a default for organisations running three services on two machines, where it solves nothing they had and introduces several they did not. The technology is not the issue; the mismatch between its assumptions and the situation it is deployed into is. Deciding well requires being specific about which of its capabilities you actually need.
What it genuinely provides
Declarative desired state, so the platform reconciles reality toward a specification rather than executing steps. Automatic rescheduling when a node fails. Rolling deployments with health checks and automated rollback. Horizontal scaling driven by observed load. Service discovery and internal load balancing. A consistent deployment interface across a large number of teams. Platform teams who document their reasoning, such as those cited at the platform coverage on this site, generally justify adoption on the last two points more than on any of the others.
That final capability — a single interface across many teams — is the strongest argument and the most frequently overlooked. Orchestration is fundamentally a coordination technology. Its value scales with the number of independent teams that need to deploy without talking to each other, which is why it pays for large organisations and not for small ones.
What it costs
- An operational surface that requires genuine expertise: networking, storage, ingress, certificates, upgrades
- A control plane to run and upgrade, or to pay a provider to run
- Debugging that spans several abstraction layers, each with its own failure modes
- Configuration sprawl, and the templating tooling that emerges to manage it
- A permanent need for someone on the team who understands it deeply
That last cost is the one that sinks small deployments. A cluster nobody fully understands is fine until an upgrade breaks something, at which point the organisation discovers it has taken on an operational dependency it cannot service.
Reasonable alternatives
For a handful of stateless services with modest traffic, a managed container service that handles scheduling without exposing cluster internals delivers most of the benefit at a fraction of the operational cost. Serverless functions suit event-driven and bursty workloads, particularly where idle time dominates. Straightforward virtual machines behind a load balancer, deployed by a pipeline, remain entirely respectable for stable applications with predictable traffic, and are far easier to reason about at three in the morning.
The honest test is whether you can name a specific problem the orchestrator solves that your current approach does not. "Everyone uses it" and "it will help us scale later" are not problems; they are anxieties. Migrating to orchestration when the need appears is a project of weeks, and running it for two years before the need appears costs considerably more.
If you do adopt it, adopt it properly
Use a managed control plane unless you have a compelling regulatory reason not to; running your own is a specialist undertaking with little differentiating value. Keep configuration in version control and apply it through a pipeline rather than by hand, since the declarative model's benefit disappears the moment the cluster diverges from the repository. Set resource requests and limits on everything, because a workload without them will eventually starve its neighbours. And plan upgrades as routine scheduled work rather than as events, since versions move faster than most organisations expect and falling behind turns a routine step into a migration.
The cost profile is not what people expect
Orchestration is often adopted partly on efficiency grounds — better bin packing, less idle capacity — and the saving is real at scale and easily swallowed at smaller sizes. A cluster requires baseline capacity for the control plane, system components, monitoring agents and headroom for rescheduling, and that baseline is a fixed cost regardless of how little is running on it. For a small deployment it frequently exceeds the waste it was meant to eliminate. The efficiency argument becomes genuine once the cluster is large enough that the fixed overhead is a small fraction of total capacity, which is another way of saying that most of the benefits appear at the same scale as the operational costs are absorbed.
Stateful workloads deserve extra caution
Running databases on an orchestrator is possible, increasingly well supported, and still the area where mistakes are least forgiving. Storage semantics, failover behaviour, backup integration and upgrade procedures all become more complex than their managed equivalents. Unless there is a specific reason — an unusual engine, a strict data locality requirement — a managed database service is almost always the better trade for anything holding data you cannot afford to lose.
Autoscaling rarely works out of the box
Scaling on processor utilisation is the default and frequently the wrong signal, because many services are constrained by connections, queue depth or downstream latency rather than by compute. A workload that saturates a database at forty per cent processor use will never trigger a threshold set at seventy, and adding instances when it finally does will make the database problem worse. Choose a signal that reflects the actual constraint, allow enough headroom that scaling begins before saturation rather than after it, and remember that new capacity takes time to become useful — image pull, startup, warm-up, health checks. For traffic that arrives faster than instances can start, scheduled scaling ahead of known peaks is more effective than any reactive policy.
The organisational prerequisite
Adopting orchestration successfully generally means creating a platform capability: a small group responsible for the cluster, the deployment interface and the documentation, so that application teams consume a product rather than each learning the underlying system. Organisations that adopt the technology without that role tend to end up with every team independently discovering the same problems, which produces the complexity of a platform with none of the leverage. If nobody will own it, that is a strong signal to choose something simpler and revisit the question when the organisation is larger.
