- Cloud
Do you really need Kubernetes?
Kubernetes earns its keep above a certain number of services and with a team able to operate it. Below that, a managed application service costs less and breaks less often.
· 4 min read · AzerOps
Kubernetes has become the default answer to "how do we deploy our applications". It is an excellent tool, and it is also the most frequent source of unnecessary complexity we encounter at clients.
What Kubernetes actually solves
It solves four specific problems: orchestrating many heterogeneous services, fine-grained autoscaling, portability across environments, and standardising deployment in an organisation where several teams ship independently.
If you have those four problems, Kubernetes is probably the right choice.
What it costs
It costs a permanent skill. Not an initial training course: a continuously available skill, able to diagnose a network problem between pods, to understand why a pod was evicted, to handle cluster version upgrades every few months.
That skill is rare and expensive. When it rests on one person in the team, you have replaced a deployment problem with a continuity problem, often without noticing.
It also costs a considerable configuration surface. Network policies, access control, resource quotas, readiness probes, secret management: each of those is an opportunity for misconfiguration, and misconfigurations in containerised environments are a frequent cause of security incidents.
The three-question test
How many distinct services do you deploy? Below ten, orchestration is not your problem.
How many people can diagnose a cluster incident today, in your organisation? If the answer is zero or one, you are not ready, whatever the number of services.
Does your load vary by a significant factor across the day? If it is stable, fine-grained autoscaling adds nothing that correct sizing does not already give you.
If all three answers do not clearly argue for Kubernetes, a managed application service — App Service, Cloud Run, ECS, App Runner depending on your provider — meets the need with a fraction of the operational surface.
The vendor lock-in objection
The classic argument for Kubernetes is portability: not depending on one provider.
That is true in theory and partial in practice. A real cluster uses its host's load balancer, storage, identity provider and image registry. Migration remains possible but it is not free, and the operating cost paid every month to preserve that option often exceeds the cost of a migration that may never happen.
What we most often recommend
Start with a managed application service, with clean containerisation. Containerisation is the real portability investment: it is cheap, it makes a later move to Kubernetes straightforward, and it requires no additional operational skill.
Move to Kubernetes when the number of services and the size of the team justify it, not before. It is advice that shortens our assignments, and it is the one that leaves clients most satisfied two years later.