Kubernetes solves real problems: scheduling across many machines, self-healing, rolling deploys, and a common interface across environments. If you have those problems it is worth its complexity. The failure mode is adopting it for a service that runs on three containers, where the complexity arrives immediately and the benefits arrive never.
01What the complexity actually costs
It is not the initial setup, which a managed service makes straightforward. It is the ongoing surface: networking policies, ingress controllers, certificate management, resource limits, autoscaling behaviour, RBAC, secrets, storage classes and cluster upgrades. Each is a thing that can break at three in the morning.
The honest measure is how much of your engineering capacity goes to running the platform rather than the product. Below a certain scale that share is uncomfortably high, and it is capacity that a simpler deployment target would have returned to feature work.
| Situation | Kubernetes fit | Usually better |
|---|---|---|
| 1-5 services, one team | Poor | Managed containers or a PaaS |
| 5-20 services, 2-4 teams | Debatable | Depends on platform capacity |
| 20+ services, many teams | Good | Kubernetes |
| Strict multi-cloud requirement | Good | Kubernetes |
| Regulated on-premise | Good | Kubernetes |
| Bursty batch workloads | Good | Kubernetes or serverless |
02The alternatives are genuinely capable now
Managed container services run containers, scale them, handle rolling deploys and integrate with the cloud provider's networking and secrets. For a small number of services that is the entire requirement, delivered without a cluster to operate.
Platform-as-a-service goes further, handling build and deploy from a repository. Teams routinely dismiss these as insufficiently serious and then spend a quarter building an internal platform that does less. The question worth asking is what specifically you need that the simpler option cannot do.
03The threshold is teams, not services
Kubernetes earns its keep when multiple teams need to deploy independently onto shared infrastructure without coordinating with each other. That is an organisational condition, and it is why service count alone is a poor signal.
One team running twenty services does not need the isolation and self-service that Kubernetes provides; they can coordinate in a chat message. Six teams running three services each do, because the coordination cost between them is what actually slows delivery.
| Signal | What it indicates |
|---|---|
| Teams blocking each other on deploys | Need for self-service isolation |
| Bespoke deploy scripts per service | Missing common interface |
| Cannot run the same setup locally | Environment drift is costing you |
| Manual scaling during known peaks | Autoscaling would pay for itself |
| Provider-specific lock-in is a real constraint | Portability has genuine value |
04If you do adopt it, adopt it properly
Use managed control planes rather than running your own. Someone must own the platform explicitly as their job, not as a side responsibility. Resource requests and limits must be set on everything, or scheduling behaviour becomes unpredictable in ways that are hard to diagnose.
And keep a plan for cluster upgrades, which arrive on the provider's schedule rather than yours. Teams that treat upgrades as an occasional inconvenience discover that an unmaintained cluster becomes a security liability and eventually an unsupported one.
05Migrating away is possible and rarely necessary
Teams that adopted Kubernetes prematurely can move back, and containerisation means the application usually does not change. What changes is deployment configuration, and the relief is often immediate.
That said, if the cluster is running and stable and nobody is fighting it, migrating away for its own sake is not obviously worth the disruption. The decision worth making carefully is the initial one, because that is when the cost of being wrong is lowest.
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer