Kubernetes: what founders discover after the migration
An honest look at the operational and financial realities of Kubernetes for mid-sized companies - what the container adoption presentations leave out.
Kubernetes has become the de facto standard for running containerised applications. Large cloud providers offer managed services that remove the operational complexity of running the cluster. Conferences and blogs are full of success stories. The impression is that for any serious product, it is an obvious choice.
I want to add to that picture what usually stays off screen - the realities companies discover six to twelve months after migrating to Kubernetes.
The first surprise: the cloud bill went up
Kubernetes adds its own layer of resource consumption. Cluster system components - control plane, monitoring, logging, network plugins - require resources that do not work directly on your applications. In managed services this is partially hidden, but it is not free.
The more significant problem is resource over-allocation. Kubernetes operates on resource requests and limits that teams set for their services. In practice, requests are often set with a comfortable margin. The result is cluster nodes running at twenty to thirty percent utilisation instead of sixty to seventy, while the company pays for all the allocated hardware.
This is not a Kubernetes problem - it is a problem of missing resource planning discipline. But Kubernetes makes it visible and scalable.
The second surprise: specialised expertise is needed
"Managed Kubernetes removes operational complexity" - this is true, but not the whole truth. You do not need to manage the cluster. But you still need to understand how Kubernetes works in order to diagnose problems.
When a service restarts periodically - you need to understand liveness probes and resource limits. When a deployment stalls - you need to understand what is happening with rolling updates and pod disruption budgets. When cluster costs unexpectedly rise - you need to read metrics and find where resources are being wasted.
This is a separate discipline. A good backend developer is not automatically a Kubernetes specialist. If there is no one on the team with this expertise, operational problems will accumulate.
The third surprise: the complexity does not disappear, it moves
Before Kubernetes: "how do we deploy a change to production?" After Kubernetes: "how do we configure the helm chart correctly, why isn't the pod starting, how does ingress work, how do we set up the horizontal pod autoscaler?"
The complexity does not decrease - it shifts from the operating system and server configuration level to the Kubernetes abstraction level. For an experienced team this is an improvement. For a team without that experience, it is a different kind of the same problem.
When Kubernetes is justified
A few situations where Kubernetes provides real value:
- Many independent services (ten or more) that need to be deployed and scaled differently.
- You need the ability to scale a specific service under load without affecting the others.
- Multiple teams deploy independently, and you need to manage isolation and resource allocation.
- You have engineers with real Kubernetes experience, or budget to bring them in.
When these conditions are absent, simpler infrastructure - managed services, PaaS, containers without an orchestrator - often better fits the need and is cheaper to operate.
Questions before deciding on Kubernetes
- How many independently deployable services do you have today and in two years?
- Are engineers with real Kubernetes experience available on the team or in the market?
- What is the cost of training the team or hiring the needed specialists?
- What specifically does not work in the current infrastructure - and will Kubernetes fix it?
- Is the total cost of ownership calculated: not just the cluster, but the engineering time to operate it?
Kubernetes is an excellent tool for the tasks it was designed for. But "Kubernetes because that is what big companies do" is not a technical decision.