Somewhere around 2019, Kubernetes stopped being a choice and became a default. We regularly meet three-engineer teams running one monolith and a cron job on a managed cluster, with a Helm chart nobody fully understands and an upgrade that has been "on the backlog" for eight months. Ask why Kubernetes, and the honest answer is usually some version of "it seemed like the serious option."
It is a serious option. That is the problem. Serious tools have serious costs, and this one's costs are routinely left off the estimate.
What it's genuinely good at
Kubernetes earns its keep in three situations.
First, a real fleet of services. If you have twenty, forty, a hundred deployable things with different scaling profiles, dependencies, and owners, the scheduler and the declarative model do work you would otherwise be doing by hand or by wiki page. Bin-packing, rollout strategy, restarts, service discovery: at fleet scale this is genuinely hard, and Kubernetes is a good answer to it.
Second, autoscaling that matters. Bursty workloads, batch jobs, spikes where the difference between scaling in forty seconds and scaling in ten minutes shows up in revenue or in the bill. Paired with something like Karpenter, it is the best in the business at this.
Third, standardization across an organization. When six teams have each invented their own deploy pipeline, a platform team offering a paved road on Kubernetes can replace six bespoke messes with one shared one. Often a good trade. Note who it's for, though: organizations with six teams and a platform team. Not you and your co-founder.
The bill nobody itemizes
Here is what running Kubernetes costs, beyond the control plane fee.
Upgrades. A new minor version roughly every four months, with a support window that will eventually force your hand, or an extended-support fee that quietly multiplies the control plane cost. Each upgrade means reading deprecation notices, checking API removals against every manifest and chart, rolling node groups, and hoping the ingress controller keeps up. Skip it for a year and the compounding gets ugly.
Nodes. A managed control plane is not a managed cluster. Someone owns AMI rotation, instance sizing, disruption budgets, and the pod that gets stuck evicting at 2 a.m.
Plumbing. Ingress controller, external-dns, cert-manager, a CSI driver, probably a service mesh someone installed in 2022. Each is another component with its own release cycle, its own CVEs, and its own way of breaking DNS.
Access and observability. RBAC that maps to how your teams work. Metrics scraping, log shipping, dashboards per namespace. None of it exists until someone builds it.
And the quiet line item: a human on call for the cluster itself, distinct from being on call for the apps. If nobody on the team can debug a CrashLoopBackOff caused by a misbehaving admission webhook at midnight, you do not operate Kubernetes. You cohabit with it.
The common mistake is counting only the first cost. The cluster comes up in an afternoon of Terraform, everyone is impressed, and the real bill arrives over the next two years as a steady tax on every sprint.
What small teams should run instead
The alternatives are not embarrassing fallbacks. For most small teams they are the correct engineering decision.
A managed PaaS (Heroku, Render, Fly.io) if you are pre-product-market-fit. You pay a premium per compute hour to make an entire category of work disappear. Early on, that premium is trivial next to an engineer-week.
ECS on Fargate, Cloud Run, or App Service if you are already on a cloud and want containers without a control plane to babysit. Here is a claim you can disagree with: for a team under ten engineers running under fifteen services, ECS beats EKS in almost every case, and choosing EKS anyway is the most common infrastructure over-purchase we see. You give up the ecosystem and some portability theater. You get deploys that survive with nobody watching.
Plain VMs with good automation still deserve a mention. A boring autoscaling group, an image pipeline, systemd. Unfashionable and extremely debuggable. For a monolith with steady traffic, this can outlive several platform rewrites.
The trade-off is real. These options are less flexible, and a genuinely unusual workload (GPU scheduling, multi-tenant isolation, operators managing stateful systems) will hit their walls. Most teams never get near those walls.
A plain heuristic
Kubernetes is probably the right call when most of these are true:
- You run more than roughly fifteen or twenty deployable services.
- More than one team ships to production independently.
- You have, or are funding, at least two engineers whose job is the platform rather than the product.
- Something about the workload (burst scale, GPUs, an operator-managed system) genuinely does not fit the managed options.
One out of four means you are early. Zero out of four means the decision is made.
The résumé cluster
The failure mode worth naming plainly: clusters adopted for hiring optics. The theory is that good engineers expect Kubernetes, so running it attracts them. In practice you get a candidate pool selected for wanting to operate Kubernetes, pointed at a company that did not need it. The cluster becomes a hobby with a pager attached. Eighteen months later that engineer moves on, and the team inherits a distributed system nobody asked for.
We have migrated companies onto Kubernetes and off it. The off-migrations are usually faster, and nobody has ever asked for the cluster back.
If you're mid-decision, this is the question our infrastructure work starts with, and "no" is a common answer.