Kubernetes is not a goal

Kubernetes is an excellent tool. It is also the most frequently misunderstood one. We regularly see clusters running three containers, maintained by two people, costing more than the application on top of them.

The honest question before any cluster

Not “can we do Kubernetes?” but: what happens when this service falls over at three in the morning, and who looks at it?

If the answer is “an alert, a runbook, a restart”, you do not need an orchestrator. If the answer is “twelve services have to come back in the right order, with rolling updates and zero downtime”, then you do.

When Kubernetes earns its keep

• Several teams deploy into the same environment independently of each other.
• Load spikes are unpredictable and scaling has to happen automatically.
• Compliance demands reproducible, declarative infrastructure with an audit trail.
• There are people who operate the cluster, not only use it.

When it does not

• One application, one database, one team.
• Traffic is known and fits on a well-sized machine.
• Nobody on the team has time for upgrades, network policies and certificates.

In those cases a VM with systemd, a reverse proxy and a clean deploy script is not backward. It is the right size. If you want the decision backed by numbers, we have worked through what a cluster costs at Swiss providers, including the operational effort that appears on no price list. The numbers do not make the decision harder, they make it easier: they force you to name the goal before choosing the tool.

What we build first instead

Cluster or VM, three things always come first:

1. A deployment anyone can trigger. One command, one result, no knowledge living in one person’s head.
2. Observability you actually read. Few metrics, clear alerts, logs with context.
3. A rollback faster than the analysis. Roll back, then understand.

A team with those three can grow from a VM into a cluster whenever it needs to. A team without them just has a bigger problem with Kubernetes.