We run Kubernetes for plenty of clients and we like it. So it surprises people when our first recommendation on a greenfield project is often a single VM with systemd, or a managed container service like Cloud Run or ECS. The cluster can wait.
What you are actually buying
Kubernetes solves bin packing across many machines, rolling deploys, self healing, and a uniform API for networking and storage. Those are real problems. The catch is they are problems of scale and team size, not problems every app has on day one. If you have three services and two engineers, the control plane is overhead you pay daily for benefits you collect rarely.
- You need to run dozens of services across many nodes with real bin packing pressure
- You have more than one team shipping independently and stepping on each other
- You already speak YAML, RBAC and have someone who can debug a CrashLoopBackOff at 2am
- Your traffic is spiky enough that node level autoscaling actually saves money
If you cannot tick at least two of those, the cluster is a hobby disguised as infrastructure. We have seen four person startups spend a quarter on their platform instead of their product.
A cluster nobody on the team can debug at 2am is not infrastructure, it is a liability you pay rent on.
The cheaper paths we reach for first
Most early stage apps fit comfortably on a managed PaaS or a couple of VMs behind a load balancer. You get deploys, logs and metrics without an etcd to babysit. The honest test: would your on call be quieter next month if you had a cluster? If the answer is not an immediate yes, you are early.
- Managed container runtimes (Cloud Run, ECS Fargate, App Runner) for stateless HTTP work
- A boring VM with Docker Compose for internal tools that ten people use
- Serverless functions for genuinely bursty, event driven jobs
When to revisit
Migrate when the managed option starts fighting you: per service cold starts, no control over networking, or a bill that scales worse than a few reserved nodes. That is a good problem. It means you grew into Kubernetes instead of cosplaying it. We would rather help a client move at that point than untangle a cluster they adopted out of resume anxiety.