The Kubernetes Tipping Point

One of the most repeated pieces of advice in DevOps is also one of the most reasonable:

“Don’t use Kubernetes. It’s overkill. Just use a VPS and Docker Compose.”

For a genuinely simple application, that advice is excellent. If you are running a single service on one machine, with a small database and very little operational risk, Kubernetes is probably the wrong tool. A cheap VPS, Docker Compose, and a reverse proxy can take you surprisingly far.

For a long time, I accepted that advice almost as a rule. Kubernetes was for hyperscalers, for large platform teams, for systems already operating at serious scale. Everyone else, I thought, should stay far away from it.

But the deeper I got into learning how modern multi-service systems are actually operated, the less convincing that distinction felt. The more I looked at real production setups, the more I noticed that the hard part was not company size. It was coordination. At some point, it became hard to ignore a simple idea: many teams are already dealing with distributed systems problems long before they think of themselves as “big enough” for Kubernetes.

That is the Kubernetes tipping point.

The complexity is already there

What many teams still call a small production app already looks something like this: a frontend, an API, a database, Redis, a worker, maybe a webhook consumer, maybe scheduled jobs, maybe object storage, and usually more than one environment. At that point, the discussion is no longer about whether you are dealing with distributed systems concerns. You already are, at least operationally. The real question is whether you want to manage those concerns explicitly through a platform, or manually through scripts, conventions, and memory.

The argument for Docker Compose is usually framed as an argument for simplicity. In practice, it is often an argument for delaying platform formalization.

That distinction matters.

Once your application is made up of several cooperating services, you inherit a set of operational problems, whether you acknowledge them or not. Services need to find each other. Processes need to restart when they fail. Traffic needs to be routed correctly. Secrets need to be injected safely. Deployments need to happen in the right order. Configuration needs to stay consistent across environments. Logs and metrics need to tell you what broke and where.

You can absolutely manage all of that without Kubernetes. Many teams do. But when they say their setup is simpler, what they often mean is that the tooling is simpler to start with, not that the operational model stays simpler over time.

There is a big difference between avoiding complexity and hiding complexity.

A lot of hand-managed infrastructure feels simple because the complexity is dispersed. It lives partly in a Compose file, partly in a shell script, partly in an Nginx config nobody wants to touch, partly in CI, partly in systemd, partly in .env files, and partly in one engineer’s head. Nothing looks overwhelming in isolation, but the overall system becomes fragile because no single layer owns the coordination problem cleanly.

Kubernetes does not magically remove that complexity. What it does is force it into the open and give it a consistent vocabulary.

That is not a small thing. In many teams, that is the real value.

Manual operations stop being cheap sooner than people think

Running multiple services manually often creates a slow operational drift. At first, it is manageable. Then the exceptions start accumulating.

A service needs to come up after another one. A worker needs a restart policy. TLS certificates need renewal. A server gets replaced, and some configuration was never documented. A background job quietly stops consuming messages. One environment is “almost” like production, except for three differences nobody remembers until deployment day. A second node gets introduced, and now placement, networking, and failover stop being abstract topics.

This is the point where many teams are already paying the orchestration tax, just without calling it that.

They are already solving for service discovery, deployment coordination, health management, scaling decisions, secret distribution, and traffic routing. They are just solving each problem separately, often with different tools and varying levels of discipline.

Kubernetes is not attractive because it makes these problems disappear. It is attractive because it standardizes them.

Instead of inventing your own deployment mechanics, your own restart behavior, your own service registration model, and your own conventions for exposing workloads, you adopt a shared control plane and a declarative contract. You describe the desired state, and the platform works to maintain it.

That declarative loop is the part many teams underestimate.

This is the same argument that won in infrastructure as code

The easiest way to understand Kubernetes is to compare it to a shift the industry has already gone through.

There was a time when provisioning infrastructure manually through the cloud console felt pragmatic. It was fast, direct, and easy to justify for small environments. Over time, we learned what that convenience really costs. Manual infrastructure was hard to reproduce, hard to audit, hard to review, and easy to drift.

Infrastructure as code became the answer because it turned operational intent into something explicit, versioned, and repeatable.

Kubernetes extends that mindset beyond machine provisioning and into workload operations.

Terraform can declare that a VM should exist. Kubernetes declares what should run on top of it, how many replicas should exist, how those replicas are exposed, how they recover from failure, and how they are updated. In other words, it carries the declarative model closer to the runtime behavior of the application.

That is why Kubernetes often feels like a natural next step for engineers who already believe in IaC. If you accept that infrastructure should be described and reconciled declaratively, it is not a huge leap to ask the same of application operations.

The discipline should not stop at the hypervisor.

The anti-Kubernetes argument is not wrong, just incomplete

To be fair, the criticism of Kubernetes exists for a reason.

Kubernetes introduces real complexity of its own. You need to understand pods, services, ingress, persistent volumes, resource requests and limits, namespaces, RBAC, and the debugging model of a cluster rather than a single machine. You will likely add Helm, Kustomize, or some other packaging layer. You may eventually add GitOps tooling. There is more abstraction, more YAML, and more moving parts.

For many workloads, that overhead is not worth it.

This is why “just use a VPS” remains good advice for a genuinely small system. If your application is a single binary, with minimal traffic, no meaningful background processing, and a very small operational surface area, Kubernetes is probably solving tomorrow’s problem with today’s complexity.

But that is exactly the point: the decision should be made based on operational shape, not on a reflexive assumption that Kubernetes is only for hyperscale companies.

The moment your team is spending meaningful time stitching services together, keeping environments aligned, and manually compensating for process coordination, you are already in platform territory. You may not need Kubernetes specifically, but you probably need something more structured than ad hoc host management.

The modern on-ramp is much better than people remember

A lot of resistance to Kubernetes is based on an older mental image: self-managed control planes, painful cluster bootstrapping, rough defaults, and too many sharp edges too early.

That memory is not entirely unfair, but it is no longer the only way in.

Today, a far more reasonable adoption path exists.

You can start with managed Kubernetes and avoid running the control plane entirely. You can keep your database managed rather than forcing stateful workloads into the cluster on day one. You can run a lightweight local distribution such as K3s for development and keep your production model close to what you use on your laptop. You can adopt the platform incrementally, beginning with stateless services and treating persistence, observability, and policy as later layers once the basics are stable.

That does not eliminate the learning curve. It just makes it more proportional.

And importantly, that learning is reusable. Once a team understands the core model, the same patterns tend to apply across services and across environments much more cleanly than hand-built conventions do.

A better rule of thumb

The real dividing line is not company size. It is not whether your system is “enterprise.” It is not whether you have millions of users.

The better question is this:

Are you still operating one application, or are you now coordinating a small ecosystem of services?

If you are coordinating several services with independent lifecycles, different failure modes, asynchronous work, shared secrets, and repeated deployment choreography, you are already paying for orchestration somehow. The only open question is whether you are paying for it through a standardized platform or through custom operational glue.

That is where Kubernetes starts to make sense.

Not when you want to impress people with cloud-native jargon. Not when you want to copy what hyperscalers do. And not because every project needs a cluster.

It starts to make sense when manual coordination stops being the simpler system.

The bottom line

Kubernetes is not the default answer to every deployment problem. A small VPS can still be the right tool. Docker Compose can still be the right tool. Simplicity is real, and it should be preserved when it is genuine.

But simplicity has a half-life.

Once your stack has become a set of cooperating services spread across environments, servers, or nodes, operational complexity does not disappear just because you have avoided Kubernetes. More often, it reappears in a less visible and less standardized form: scripts, one-off fixes, fragile conventions, and late-night recovery knowledge.

That is the tipping point.

Kubernetes is not valuable because your system is massive. It is valuable because, at a certain stage, you are tired of being the control plane yourself.