Kubernetes is everywhere. Every infrastructure job posting lists it. Every DevOps conversation references it. Somewhere along the way it became the default answer to “how should we deploy our application” - regardless of whether the question actually called for it.
We've set up Kubernetes clusters for teams that genuinely needed them. We've also helped teams evaluate whether it was the right fit for their situation - and sometimes it wasn't. Here's the honest version of that conversation.
What Kubernetes actually is
Kubernetes is a container orchestration system. It manages the deployment, scaling, networking, and health of containerised applications across a cluster of machines.
When it's the right tool, it's genuinely impressive. Services scale automatically under load. Failed containers restart themselves. Deployments roll out with zero downtime. When it's the wrong tool, it's a full-time operational job that produces no user-facing value.
The real cost nobody talks about
Pods, nodes, deployments, services, ingress controllers, config maps, secrets, persistent volumes, namespaces, RBAC, Helm charts - this is the vocabulary of a system you now own and maintain. Every engineer on the team needs to understand it at least partially.
Clusters need upgrades. Node pools need management. Certificates expire. Networking configurations drift. Something will break in a way that requires genuine expertise to diagnose. That person needs to be available when it happens.
A production-grade managed Kubernetes setup on AWS or GCP typically starts at several hundred dollars a month before your application handles a single request.
When Docker Compose is genuinely enough
If your application is a backend service, a frontend, a database, and maybe a background worker - Docker Compose on a well-specced VM will handle more traffic than most teams expect, cost significantly less, and be understood by every engineer on the team quickly.
We have teams running meaningful production workloads on exactly this setup. They ship faster because they spend no time on infrastructure maintenance. They debug faster because the system is simple enough to fully understand.
Simple infrastructure that your team understands completely is worth more than sophisticated infrastructure that nobody fully understands.
When Kubernetes earns its complexity
Multiple independent services that need to scale at different rates. High availability requirements where downtime has a direct, measurable cost. A dedicated infrastructure engineer or DevOps team who will own the cluster as part of their actual job. Traffic that's genuinely unpredictable at scale and can't be economically overprovisioned.
When these are true, Kubernetes is the right answer. The complexity has a home and the benefits are real.
A simple way to decide
Before choosing Kubernetes, ask honestly: do you have more than a few independent services that need to scale differently? Do you have someone whose job includes owning the cluster? Does your SLA require high uptime with real consequences? Is your deployment pain coming from orchestration complexity - or from something simpler?
If most answers are no - start with Docker Compose or a managed platform. Migrate to Kubernetes when the pain of not having it becomes specific and measurable, not theoretical. You can always move up. You can't get back the time spent on complexity you didn't need.
The most impressive infrastructure decisions we see aren't always choosing the most sophisticated option. Sometimes they're knowing exactly when not to - and spending that saved time shipping things users actually experience.
