Why Kubernetes isn't always the answer

Kubernetes is excellent at a specific class of problems: many services, many teams, and a need for a consistent control plane. It is a poor default for a single application that needs a boring, recoverable runtime.

The hidden cost is not cluster fees. It is the program: networking, identity, deployment contracts, observability, and the people who keep those contracts true. If that program is underfunded, Kubernetes becomes a source of incidents rather than a platform.

A useful test: would a managed runtime, a small VM fleet, or a batch scheduler meet the reliability and delivery requirements with less surface area? If yes, the architecture is probably simpler without a cluster.

When Kubernetes is the right answer, treat it as a platform program. Landing zone, GitOps path, environment promotion, and a clear owner for the control plane. The cluster is not the product. The delivery contract is.

CIFL’s advice is consistent: pick the simplest architecture that can carry the required scale, then automate that architecture. Complexity is not a proxy for seriousness.