Kubernetes: when it actually pays off for an SMB — and when it's a liability

Kubernetes is the default answer to a question most small companies never asked. Somewhere a CV or a conference talk convinced someone that "real" infrastructure runs on Kubernetes, and now a five-person team is maintaining a control plane to serve three containers that a single VM would have run without complaint. We deploy and run Kubernetes where it earns its place — and talk clients out of it where it does not. Here is the honest line between the two.

What Kubernetes actually gives you

Strip the hype and Kubernetes buys four concrete things: self-healing (a dead container or node is replaced automatically), declarative scaling (up and down, by rule), rolling deployments and rollbacks as a first-class feature, and a uniform way to run many services across many machines. Those are real and valuable — *if you have the problem they solve*. The catch is that all four are answers to problems of scale and multiplicity, and most SMBs have neither.

The cost side, honestly

Kubernetes is not free even when the software is. It costs:

• •Operational complexity. A cluster is its own system to run — upgrades, networking (CNI), ingress, storage classes, secrets, RBAC, certificates. Something in that list breaks in a way that has nothing to do with your application, and someone has to understand it.
• •A real bus factor. "We run Kubernetes" too often means one engineer understands the cluster and everyone else prays. That is the same single-point-of-failure risk we flag for outsourced DevOps — a platform nobody else can operate is a liability, not an asset.
• •The 3am question. When the cluster misbehaves at night, can your team debug it? If the honest answer is no, Kubernetes has moved your risk, not reduced it.

When it does not pay off

For a large share of SMBs, the right answer is something simpler:

• •A few long-running services, one or two servers → Docker Compose on a VM (or two, with a load balancer) is enough, and a fraction of the operational load.
• •A handful of containers, want some resilience → Docker Swarm or HashiCorp Nomad give clustering and failover with a small fraction of Kubernetes' concepts.
• •A web app and a database → a managed platform (a PaaS, or managed app + managed database) removes the infrastructure question entirely.

None of these is "not real infrastructure." They are correctly-sized infrastructure, and correctly-sized is the whole game.

When it genuinely pays off

Kubernetes earns its complexity when you actually have its problems:

• •Many services (a real microservice estate, not three containers) that benefit from a uniform deployment, scaling and networking model.
• •Variable or bursty load where automatic scale-up and scale-down saves real money or prevents real outages.
• •Genuine need for self-healing HA across nodes, where a minute of manual recovery is unacceptable.
• •A team — or a partner — that can actually operate it, so the platform is an asset with more than one person behind it.

If two or more of those are true, Kubernetes stops being cargo-cult and starts paying for itself.

Managed vs self-hosted — and the lightweight middle

If you do need it, you still have a choice that changes the cost enormously:

• •Managed Kubernetes (EKS, AKS, GKE, or a provider's managed offering) hands the control plane to someone else — the right default when you want Kubernetes' capabilities without operating its hardest part.
• •Lightweight distributions — k3s and k0s — give you a genuine, conformant Kubernetes with a fraction of the footprint, ideal for small clusters, edge, and on-prem where a full managed service is not an option.
• •Full self-managed Kubernetes is for teams with a real platform function and a specific reason to control everything. For most SMBs it is the expensive way to acquire the 3am problem.

The decision, in one line

Do not choose Kubernetes because it is the industry default; choose it because you have multiplicity, scale, or HA needs that simpler tools cannot meet — *and* someone who can run it. If you cannot name which of those problems you have, you do not have them yet, and Compose on a well-run VM will serve you better and cheaper until you do.

What we do

We run both ends of this for clients as part of DevOps as a Service: Kubernetes — managed or k3s/k0s on your own infrastructure — where the workload justifies it, and deliberately simpler setups where it does not. We will tell you honestly which side of the line you are on, because the worst outcome is a small team saddled with a cluster it cannot operate to run workloads that never needed one. Right-sized beats impressive every time.