Kubernetes is one of the most powerful pieces of infrastructure software ever built — and one of the most over-adopted. It solves a genuinely hard problem: running many services reliably, at scale, across many machines. The honest question for most teams is not whether Kubernetes is good. It is whether you have the problem Kubernetes solves. Usually, you do not — yet.
This is not an argument against Kubernetes. It is an argument for adopting it when the need is real, and for being clear-eyed about the cost of adopting it before then.
What Kubernetes actually does
Kubernetes is a container orchestrator. Once you have an application split into containers, Kubernetes decides which machine each container runs on, restarts containers that fail, scales them up and down with load, handles networking between them, manages rolling updates, and keeps the whole system in the state you declared. For an organisation running dozens or hundreds of services across a large fleet of machines, that orchestration is indispensable — doing it by hand would be impossible.
That is the key phrase: dozens or hundreds of services, at real scale. Kubernetes was built by and for organisations operating at that size. Its design assumes that problem. Used to solve that problem, it is superb.
The cost nobody mentions in the demo
Kubernetes is not free to adopt, and the price is not the hosting bill. The real cost is complexity and the expertise to manage it. A Kubernetes setup has many moving parts — the cluster itself, networking, ingress, storage, secrets, configuration, security policies — and each is a thing that can break in a way that needs genuine Kubernetes knowledge to diagnose.
For a large organisation, that cost is absorbed by a dedicated platform team whose job is to run the cluster. For a small team without one, the cost lands on the product engineers, who now spend time operating infrastructure instead of building the product. That is the trade that often goes unexamined: Kubernetes can quietly turn a team of product engineers into part-time infrastructure operators.
What most teams actually need
Most teams — a startup, a growing product, an internal application — have a handful of services, modest and reasonably predictable traffic, and a small team. For that situation, there are simpler options that deliver the reliability and scaling teams actually want, with a fraction of the operational weight.
A managed platform-as-a-service runs your application with almost nothing for you to operate. A managed container service runs your containers, handles the scaling and the health checks, and hides the orchestration entirely. Serverless removes the servers from the picture altogether. Each of these gives a small team automatic scaling, self-healing, and reliable deployments — the things people actually adopt Kubernetes for — without the cluster to run. For most teams, one of these is the right answer for years.
Does managed Kubernetes change the answer?
A fair objection at this point: the major clouds all offer managed Kubernetes — services that run the cluster’s control plane for you. Does that not remove the complexity argument?
It reduces it. Managed Kubernetes takes the hardest, most failure-prone part — operating the control plane — off your team’s plate, and it is genuinely a large improvement over running Kubernetes entirely yourself. If you have decided you need Kubernetes, you should almost always use a managed offering rather than self-managing the whole thing.
But it does not make Kubernetes simple. The application-level complexity remains: the networking, the ingress, the storage, the configuration, the security policies, the resource definitions, the version upgrades. Your engineers still have to understand Kubernetes to deploy to it, debug it, and run it day to day. Managed Kubernetes lowers the floor; it does not change the fact that you have taken on a Kubernetes-shaped system. The question of whether you need that system in the first place is exactly the same.
When Kubernetes genuinely earns its place
There is a real point at which Kubernetes becomes the right call, and it is worth naming honestly. You are running many services — not three, but dozens — at a scale where simpler managed options become limiting. You have, or are ready to fund, a platform team that will own and operate the cluster properly. You have genuinely complex requirements — multi-cloud, specialised workloads, fine-grained control — that the simpler options cannot meet. When several of those are true, Kubernetes stops being overhead and starts being the tool that holds the whole system together. At that point, adopt it without hesitation.
The cost of adopting it too early
Adopting Kubernetes before you need it is not a harmless bit of future-proofing. It is a real and recurring tax. The team moves slower, because every deployment and every change runs through more machinery. The system breaks in more ways, because there are more parts to break. Hiring is harder, because you now need Kubernetes expertise. And the product gets less attention, because engineers are spending their time on the cluster. “We might need it later” is a poor reason to pay that tax now — especially because migrating to Kubernetes later, when the need is real, is a well-trodden and manageable path.
How to actually decide
The decision is not about Kubernetes’ merits — they are real. It is about your situation. Ask three honest questions. How many services are you running, and at what scale — truly, today? Do you have a team that can own the cluster, or would operating it fall on your product engineers? And what specifically do you need that a managed container service or serverless cannot give you? If the honest answers are “a few, modest”, “no dedicated team”, and “nothing specific” — you do not need Kubernetes yet, and choosing a simpler option is the more sophisticated decision, not the less. Revisit it when the answers change. They might, and that is fine; that is when you adopt it.
Common questions
Is Kubernetes overkill for a small team?
In most cases, yes. Kubernetes was designed to orchestrate many services at real scale across a large fleet of machines, and it carries the operational complexity that problem requires. A small team with a handful of services and modest traffic does not have that problem, and adopting Kubernetes anyway means paying its complexity cost without using its power. A managed container service, a platform-as-a-service, or serverless gives a small team the scaling and reliability they actually want with a fraction of the operational weight. That is usually the right call for years.
What can I use instead of Kubernetes?
For most teams, a managed alternative does the job with far less to operate. A platform-as-a-service runs your application with almost nothing for you to manage. A managed container service runs your containers and hides the orchestration — you get scaling and health checks without a cluster. Serverless removes servers from the picture entirely. Each of these delivers the automatic scaling, self-healing, and reliable deployments that teams actually adopt Kubernetes for, without the cluster to run. The right choice among them depends on your workload, but any of them is simpler than Kubernetes.
When does a team genuinely need Kubernetes?
When several things are true at once: you are running many services — dozens, not a handful — at a scale where simpler managed options become limiting; you have, or are ready to fund, a platform team to own and operate the cluster; and you have genuinely complex requirements, such as multi-cloud or specialised workloads, that the simpler options cannot meet. When that describes you, Kubernetes stops being overhead and becomes the tool that holds the system together. The mistake is adopting it before those things are true, not adopting it when they are.
Is it hard to migrate to Kubernetes later?
It is real work, but it is a well-trodden and manageable path — and crucially, it is far cheaper than running Kubernetes for years before you need it. If your application is already containerised, which it should be regardless, the move to Kubernetes when the need is genuine is a planned project, not a rewrite. This is exactly why “we might need it later” is a weak reason to adopt it now: the later migration is straightforward, while the cost of premature adoption is a recurring tax on every deploy, every incident, and every hire in the meantime.
Does using Kubernetes make my app more reliable?
Not on its own — and this is a common misconception. Kubernetes provides mechanisms for reliability, such as restarting failed containers and rolling updates, but a Kubernetes cluster that is misconfigured or run by a team without the expertise to operate it can easily be less reliable than a simple managed service. Reliability comes from sound architecture, good observability, tested deployments, and capable operations — not from the orchestrator. A managed container service gives a small team strong reliability defaults with far less that can go wrong.
Wondering whether Kubernetes is right for your team?
Tell us about your services, your scale, and your team. We will tell you honestly whether you need Kubernetes — or whether something far simpler will serve you for years.