I’ve seen enough docker setups to know that a lot of people reach for Kubernetes before they’re ready for it.
It doesn’t mean Kubernetes is bad. It's a solid platform and makes a lot of sense in the right environment. But for many teams, particularly smaller teams, the real question is not if Kubernetes is powerful. It’s a question of whether the team has the bandwidth to run this thing without slowing down everything else.
I have seen this in practice, not in theory. When I was dealing with containerized deployments, Azure VM setups, Keycloak in Docker, and even NLP pipeline packaging, the toughest problems were never about orchestration as a concept. The challenges were about basic operational friction: container permissions, image size, missing model files, HTTPS requirements, disk space and deployment behavior that needed careful debugging. Kubernetes would not have made those problems go away. In some cases it would have put another layer over them.
That’s the part people don’t get. The use of machines is not expensive (Kubernetes). It is expensive because someone has to understand the cluster, the networking, the access model, the upgrade path, the deployment workflow and the failure modes. That's a lot to ask from a small team still trying to get a product out.
The “we need Kubernetes for scale” argument is also played up a lot. Most early-stage systems aren't managing multiple teams with dozens of services. They are running one API, one worker, maybe a DB, and a few background jobs. “That’s a deployment problem, that’s not a platform-complexity problem.
In that setup I tend to think simple is better. A well-managed Docker Compose deployment, PaaS, ECS Fargate or Cloud Run can handle surprising amounts of real traffic without requiring the team to maintain a whole orchestration layer. That trade off often makes more sense than adding Kubernetes just for the sake of being more “serious”.
So when does Kubernetes start to make sense? When the organization actually grows into it: multiple teams deploying independently, real scheduling complexity, platform level networking needs, portability concerns, or workloads that actually benefit from orchestration at scale. At that point the operational overhead is easier to justify because the team is big enough to carry it.
I think the simplest question still is the cleanest: does the pain of not running Kubernetes outweigh the pain of running it, with the team you actually have right now?
If the honest answer is “not really, but we think we should,” that’s usually not a technical reason. It’s pressure, it’s habit, it’s comparing to the bigger company’s stack. And that’s a very expensive reason to adopt infrastructure.”
Top comments (0)