While Kubernetes dominates the jobs space, Docker Compose will do the trick on VPS for most products out there. The honest assessment of when the complexity of k8s will pay off.
Question to the question
Whenever a small team considers whether they should use Kubernetes, their underlying question is probably more along the lines of "will we have regrets that we didn't use it in the future?". This makes teams implement orchestration far earlier than necessary out of fear of future migration, while paying the price of complexity every week in advance for an operation that may never take place.
This comparison tries to be practical in terms of what each solution offers and what it actually costs a team of 1-10 engineers.
What Kubernetes delivers
Kubernetes is justified in its complexity when you have to do real things like: scheduling among many nodes, automatic scaling based on metrics, self-healing even when the node goes down, advanced rollouts (canary, blue-green, traffic shifting), and a declarative API which larger teams can build on.
Every single one of these features relies on the assumption of scale – many nodes, many services, several teams. On a single node, all of these features turn out to be overly complex implementations of things you can already do with Docker.
What Compose on a single host offers
Docker Compose, along with the underlying platform, offers quite a lot of similar capabilities in the case of a single node deployment:
YAML-based declarative service descriptions: yes, compose files
Self-healing: restart policies will start the containers after a failure; health checks will identify stalled containers
Zero-downtime deployment: platform-controlled rolling replacement via proxy with health checks as a gating factor
Service discovery: every service has a DNS name because of Docker networks
Secrets and configuration: injection of configuration from the encrypted storage
What is really missing: multi-host scheduling, autoscaling, and surviving node failures
The real price of Kubernetes for a small team
Even Managed Kubernetes (EKS, GKE, DOKS) requires a stack of decisions and maintenance that have nothing to do with your product: ingress controller selection and configuration, cert-manager for TLS, external-dns, a secrets management solution, an observability stack (as kubectl logs won't scale anymore), tuning of resource requests and limits, and quarterly control plane updates that sometimes break your workloads.
Costs come second but still exist: control plane costs + minimal sane node pool will start at $75-$150 monthly before your first application. Time is the first problem: expect someone to spend several hours per week on managing the cluster, which is not an insignificant cost for a team of five people.
On the other hand, the one-VPS limit is much higher than most teams think. $40 dedicated vCPU instance (8 cores, 32GB) handles millions of requests per day for the average web app. Vertical scaling gives years of free headroom, and an additional server for the database or staging doubles it again without using an orchestrator.
When to actually adopt Kubernetes
Load is persistently more than can be handled by one or two large servers
Namespace isolation & RBAC are required for multiple teams working in shared infrastructure
There is a compliance or platform engineering requirement that dictates usage of Kubernetes API as organisational standard
You deploy applications as Helm packages which assume Kubernetes as their operating environment
Until that time: containerised applications running on Compose move to Kubernetes with minimal hassle
The Pragmatic middle path
Containerise all from day one. The decision is yours to make and will preserve all future options for you. Use it on an orchestrator such as Peon which automates Compose style deployments using VPSes. Reconsider the orchestrator question only when a tangible limit becomes apparent (a server you cannot scale up or down, a development team you can’t segregate) and never on account of some keynote speaker freaking you out.
Top comments (0)