Kubernetes for the small team: worth it?

Kubernetes has won. It is the industry-standard way to orchestrate containers, every cloud offers a managed version, and the conference talks make it sound mandatory. So a small team building a Rails app feels the pull: surely we should be on Kubernetes too? This post is an honest attempt to answer that — what Kubernetes genuinely gives you, what it genuinely costs, and whether a small team actually needs it. The short version, which I will then justify: probably not yet.

What Kubernetes actually gives you

Kubernetes is real and impressive engineering, and its benefits are genuine. It is a declarative container orchestrator: you describe the desired state of your system (run 3 copies of this container, give it this much memory, expose it here, connect it to that), and Kubernetes works continuously to make reality match — the same desired-vs-actual reconciliation idea from the EC2 post, raised to a whole platform. Concretely:

Self-healing. A container crashes, Kubernetes restarts it. A node dies, it reschedules the work elsewhere. The system continuously repairs itself toward the declared state.
Declarative scaling. Change “3 replicas” to “10” and Kubernetes makes it so; autoscaling can do it based on load.
Rolling deploys and rollbacks are built in, with health checks gating the rollout.
A consistent abstraction across clouds. Your deployment is described the same way whether it runs on AWS, GCP, or your own hardware.

For an organisation running many services at real scale, these are transformative. The question is not whether Kubernetes is good — it is whether your situation needs what it offers, at the price it charges.

What it actually costs

Here is the part the conference talks underplay. Kubernetes is operationally heavy, and the cost is paid continuously, not once:

A steep, broad learning curve. Pods, services, deployments, ingresses, configmaps, secrets, volumes, namespaces, RBAC — Kubernetes has a large vocabulary and a lot of concepts, and you must understand a fair chunk of them before you can deploy and operate an app safely. That is weeks of learning that is not building your product.
It effectively wants a platform team. Running Kubernetes well — networking, ingress, secrets management, monitoring, upgrades of the cluster itself, debugging when a pod won’t schedule — is close to a full-time specialism. For a small team, the people maintaining Kubernetes are the same people who should be building features, and Kubernetes can quietly consume a large share of their time.
More moving parts, more failure modes. You have added a large, complex distributed system underneath your application, and it has its own failure modes that you now have to understand and debug — on top of your app’s. When something breaks, “is it my app or is it the cluster?” is a new and frequent question.
Managed Kubernetes helps, but does not erase this. A managed control plane (EKS, GKE) removes some of the burden, but you still own the workloads, the networking config, the YAML, and the operational knowledge. It lowers the floor; it does not make Kubernetes simple.

The honest summary: Kubernetes trades operational simplicity for operational power. That trade is excellent when you need the power and have the people; it is a bad trade when you need neither.

Does a small team need it?

The clarifying question is not “is Kubernetes good?” but “what problem am I solving, and is Kubernetes the simplest thing that solves it?” For a small team with a Rails app and modest scale, the honest answer is usually no, not yet, because the problems Kubernetes solves are mostly problems you do not have at that size:

You probably run a handful of services, not hundreds — so the orchestration of many services is power you are not using.
You probably do not need to autoscale across a fleet of nodes — a couple of appropriately-sized servers handle your load.
Your deploy needs (atomic release, easy rollback, health checks) are real, but achievable far more simply.

The cost, meanwhile, is paid in full regardless of your size — the learning curve and operational burden do not shrink because you are small. So a small team adopting Kubernetes often pays the full cost for a fraction of the benefit, and spends time operating a cluster that should have gone into the product.

The simpler alternatives

What a small team should usually reach for instead, in rough order of increasing control:

A PaaS (Heroku and friends). For many small teams this is the right answer for years: git push to deploy, the platform handles the servers, scaling is a slider, and you operate almost nothing. The premium you pay in hosting is far less than the salary cost of operating Kubernetes yourself.
A managed container service that is simpler than full Kubernetes — run your containers without hand-managing an orchestrator.
A couple of well-configured servers (the Ansible/Capistrano approach from earlier posts) with containers, which is more than enough for a great many apps and which you fully understand.

Each of these gives you containers, deploys, and rollbacks without the cluster, and you can move to Kubernetes later if and when you genuinely outgrow them.

When Kubernetes does become worth it

To be fair to it: there is a real point where Kubernetes becomes the right call. When you are running many services (a real microservice architecture), when you have genuine large-scale autoscaling needs, when you need multi-region or hybrid-cloud portability, and — crucially — when you have the people to operate it (a platform/infra team or strong DevOps capacity), Kubernetes earns its complexity and becomes a genuine asset. The signal is that you are feeling the pain Kubernetes solves — not that you read it is what serious teams use.

Verdict

Kubernetes is excellent engineering that solves real problems — orchestrating many containers at scale, declaratively and self-healingly — but it solves them at a steep, continuous operational cost that does not shrink for small teams. For a small team building a Rails app at modest scale, adopting Kubernetes usually means paying the full price for benefits you are not yet using, while a PaaS or a couple of well-run servers would deliver deploys, rollbacks, and reliability far more simply. Choose infrastructure by the problem you actually have, not the one the industry says you should aspire to. Reach for Kubernetes when you genuinely feel the pain it solves and have the people to run it — and until then, keep your infrastructure as simple as your scale allows, and spend the saved time on the product. The most sophisticated choice is often the simplest one that works.