Kubernetes Is Often the Wrong Starting Point

Kubernetes became the default answer before most teams had the problem it solves.

That is the issue. Not Kubernetes itself. The issue is starting there because it feels like the serious option.

Kubernetes adds a lot of operational weight. You are not just deploying an app. You are taking on cluster management, networking, storage, secrets, observability, rollout behaviour, and a much bigger debugging surface. Sometimes that is justified. A lot of the time, it is not.

I get why people go there. I did too. If you care about infrastructure, Kubernetes looks like the right destination. The mistake is treating the destination like the starting point.

What changed for me was simple. I stopped asking, “Should I use Kubernetes?” and started asking, “What do I need that simpler tools cannot do?” Most of the time, the honest answer was not much. I needed reliable deployments, easy rollback, basic service discovery, and something I could debug without turning every problem into platform work.

So now I start with the simplest thing that does the job. For small projects, that is often Docker Compose. For lightweight multi-node setups, Docker Swarm still does more than people admit. For a lot of workloads, a single VM is enough. Not because these tools are perfect. Because they solve the problem in front of you without creating a bigger one.

There are tradeoffs. You give up some ecosystem depth and some scaling flexibility. Fine. If you really need complex scheduling, clear boundaries between teams, or a shared platform across a lot of services, Kubernetes earns its place. But those should be real requirements, not guesses about the future.

Most developers do not need Kubernetes first. They need something they can run, debug, and maintain. Start there. Add complexity when the system makes it necessary. Not before.