What this is really about
Kubernetes won. It's the default answer to "how do we run containers," taught in every course and assumed in every architecture diagram. That success created a reflex: reach for Kubernetes first, justify it later.
This piece argues the opposite discipline: decide by fit. Kubernetes is a genuinely great distributed-systems platform. It's also a standing operational commitment that a large share of teams adopt before they have the scale, the team, or the problems that justify it. The question isn't "is Kubernetes good?" It's "do my workloads and my team actually need what it does, and what does it cost me every day if they don't?"
What Kubernetes actually is (and isn't)
Kubernetes is not a way to run containers. A container runtime does that. Kubernetes is an orchestration and reconciliation platform: it keeps a declared desired state true across a fleet of machines, handling scheduling, self-healing, rolling updates, service discovery, secrets, autoscaling, and network policy.
That is enormous power, and it's the right power when you have a fleet and many moving parts. But every one of those capabilities is also a concept your team must learn, operate, secure, upgrade, and debug. You don't adopt "containers"; you adopt an API surface of Deployments, Services, Ingress, ConfigMaps, RBAC, CRDs, and operators, plus the platform that runs them.
The real cost: day 2, not day 1
A demo cluster is easy. Running Kubernetes in production, for years, is not. The costs that bite are recurring:
- Expertise: you need people who genuinely understand the control plane, networking (CNI), storage (CSI), and RBAC, not just enough to paste a YAML file.
- Upgrades: clusters, add-ons, and CRDs all version and drift; upgrades are routine, tested, and never-ending.
- Security surface: RBAC, network policy, admission control, image supply chain, secrets. Misconfiguration is the norm, not the exception.
- Debugging depth: when something breaks, the fault can live in your app, the pod, the node, the CNI, the ingress, or the cloud. That's a lot of layers to reason across at 3 a.m.
None of this is a reason to avoid Kubernetes. It's a reason to make sure the value you get back exceeds this permanent tax. In many teams, Kubernetes doesn't fail technically; it fails economically, by consuming the engineering time that would otherwise ship product.
When you genuinely need it
The signals that justify Kubernetes are mostly organizational and scale-driven, not "we have containers":
- Many services and many teams: dozens of services that need a consistent, self-service deployment platform, and you have (or will fund) a platform team to operate it.
- Elastic, bursty, or heterogeneous scale: real autoscaling across a fleet, mixed workloads, bin-packing a single machine can't handle.
- Portability as a hard requirement: you must run the same way across clouds and on-prem, and that portability is worth the complexity.
- A rich operator ecosystem you'll actually use: databases, queues, and platforms delivered as operators that make the cluster pay for itself.
If several of these are true, Kubernetes isn't overkill. It's the right tool, and the complexity buys real leverage.
When you don't: what wins instead
For a large share of workloads (a web app and a database, an API, a handful of services, an early-stage product), Kubernetes is a platform you'll spend more time operating than benefiting from. The simpler stacks that usually win:
- Docker Compose on a VM (or two): a few containers, a database, a reverse proxy. Boring, cheap, trivially debuggable, and enough for a surprising amount of production traffic. The honest limit is high availability: a single VM is a single point of failure, so once you need automatic failover and zero-downtime deploys, you have outgrown it.
- A managed PaaS (Vercel, Render, Fly.io, Railway, App Platform): push code, get deploys, TLS, scaling, and rollbacks with no cluster to run. The platform team is the vendor.
- Managed container services (AWS ECS/Fargate, Google Cloud Run, Azure Container Apps): scheduling, scaling, and health checks without the Kubernetes API surface or the upgrade treadmill.
- A simpler orchestrator (HashiCorp Nomad): real scheduling across nodes with a fraction of Kubernetes' operational weight, when you need orchestration but not the whole ecosystem.
The through-line: these move the operational burden off your team. That's usually the point.
A decision framework
Quick test: if your biggest deployment problem today is "how do we ship safely," you don't need Kubernetes. If it's "how do dozens of teams ship independently," you probably do.
Before adopting Kubernetes, answer honestly:
- How many services and teams? As a rough signpost rather than a hard rule: one to ten services usually belong on Compose or a PaaS; ten to thirty fit managed container services comfortably; thirty-plus services across multiple teams is where Kubernetes starts to pay for itself.
- Who operates it? If you can't name the people (or the funded platform team) who own the cluster's day-2 life, you're not ready; a managed service or PaaS is safer.
- What's your real scale? If a couple of well-sized VMs handle your load with headroom, you don't have a fleet problem yet.
- What does it cost if the alternative fails? Often a PaaS is enough for years, and you can migrate if you outgrow it, which is cheaper than running Kubernetes prematurely.
Think of it as a complexity curve that tracks organizational scale:
- Low scale: Compose or a PaaS
- Mid scale: managed container services
- High scale with multiple teams: Kubernetes
Most teams don't have a Kubernetes problem. They have a prioritization problem.
Two pictures make the line concrete. A fintech startup running four services (API, worker, frontend, database) on two VMs will get more operational overhead than value from Kubernetes; Compose or a managed platform ships the same product faster and with far less to maintain. A company running sixty microservices across five teams is the opposite case: there, Kubernetes turns deployment into a consistent, self-service platform that no amount of shell scripts and hand-managed VMs will match.
If you're reaching for Kubernetes to look production-grade rather than solve a real problem, that's the signal.
The pragmatic path
The best part of choosing simplicity first is that it isn't a dead end. Most teams are better served by growing into Kubernetes than by starting there:
- Start on a PaaS or Docker Compose, and ship the product.
- Move to managed container services (Cloud Run, ECS, Container Apps) as traffic and services grow, gaining scaling and health checks without a cluster to run.
- Standardize on infrastructure-as-code and consistent build-and-deploy pipelines, which is the discipline Kubernetes assumes anyway.
- Adopt Kubernetes when organizational complexity genuinely demands it: many teams, many services, and a platform team to run it.
Each step is cheap to take and cheap to reverse, and each one builds the operational maturity the next assumes. Adopting Kubernetes on day one, before any of that pressure exists, is the expensive move: you pay the full operational tax for years while a simpler stack would have shipped faster.
Trade-offs & risks
Every choice trades something:
- Kubernetes buys orchestration, portability, and ecosystem, at the cost of permanent operational complexity and the team to carry it.
- PaaS and managed services buy simplicity and speed, at the cost of some control, potential vendor lock-in, and per-unit price at scale.
- Docker Compose on a VM buys radical simplicity, at the cost of manual scaling and weaker self-healing; you outgrow it eventually.
The expensive mistake is adopting Kubernetes early for a problem you don't have, then paying the complexity tax for years while a simpler stack would have shipped faster.
IT Intel's take
Kubernetes is not the starting point. It is the scaling point. Fit decides, not fashion, so choose in this order: team and scale first, portability second, résumé-driven architecture never.
Adopt it when three things are true at once: the complexity genuinely demands it, the teams need a shared self-service platform, and the organization can sustain the day-2 operation. If all three hold, Kubernetes earns its complexity and is the right long-term bet. If they don't, a managed PaaS or a managed container service almost always ships faster, costs less to operate, and lets a small team punch above its weight. You can graduate to Kubernetes when the scale actually arrives, which is far cheaper than running it before it does.
The most expensive infrastructure decision isn't picking the "wrong" tool; it's paying for capability you don't yet need. Kubernetes is worth it exactly when you would feel its absence. Until then, simplicity is not a compromise; it is an advantage.