Kubernetes has become the default answer to "how should we run this?" in many technical discussions. It is a capable system, built to run very large numbers of services across many machines. Whether a team of five with one product needs it is a separate question, and the honest answer is usually no, or not yet.
What it actually does
Kubernetes takes containers and decides which machine each runs on. It restarts them when they fail, replaces machines that disappear, adds or removes copies as load changes, routes traffic between services and rolls out new versions gradually. All of this is controlled through a consistent, declarative configuration.
These are real benefits for an organisation running dozens of services with several teams deploying independently.
What it costs
The cost is complexity. There is a large set of concepts to learn before anything can be run safely. Networking, storage, permissions and secrets each have their own model. The cluster itself needs upgrades several times a year, and each upgrade can affect what runs on it. When something fails, the cause may sit in any of many layers.
A managed service from a cloud provider removes part of this work, not all of it. Someone on the team still has to understand it well enough to diagnose problems at a bad moment. For a small team, that person's time is the real price.
When it is the right choice
- You run many services that are deployed separately by different teams.
- Load varies widely and you need to add and remove capacity automatically.
- You must run across several regions or in a customer's own environment in a standard way.
- You already have people with solid experience of operating it.
When it is not
A single application with a database, a background worker and a cache does not need an orchestrator. Neither does a product with steady, predictable traffic, or a team where nobody has run a cluster before. In these cases Kubernetes adds operational risk in exchange for capabilities that will not be used.
What to use instead
A few servers with containers. Docker Compose on one or two well-maintained virtual machines runs a surprising amount of traffic. It is easy to understand, and the whole setup fits in one file.
A managed application platform. Several providers will run your container and handle scaling, certificates and deployment for you. You give up some control and gain a great deal of time.
Managed services for the hard parts. A managed database with automatic backups and failover removes the piece that is most painful to operate yourself, whatever runs the application.
These options are not second best. For most small and medium products they are the better engineering decision.
Reliability without an orchestrator
The things that keep a simple setup dependable are not exotic. Build the application as a container image so that every environment runs the same thing. Deploy through an automated pipeline. Let the process manager restart a container that crashes. Monitor from outside and alert a person. Keep tested backups. Describe the servers in code so that one can be rebuilt quickly. With these in place, a small setup recovers from most failures fast.
Keep the door open
Choosing simplicity now does not prevent a move later. An application that already runs in containers, keeps its configuration in environment variables, stores no state on the local disk and exposes a health check can be moved to Kubernetes with modest effort when the need is real. Those habits are worth having on any platform.
Signs you have outgrown the simple setup
- Deployments of different services regularly get in each other's way.
- You are adding and removing servers by hand to follow the load.
- The number of services has grown past what one file and one person can keep track of.
- Customers require deployment into their own infrastructure.
A common trap
Technology is sometimes chosen because it is interesting to work with or looks good on a profile. That is an understandable motive and a poor basis for a production decision. The right question is what the product needs over the next year or two, and what the team can operate confidently.
Summary
Kubernetes fits organisations with many services, variable load and people to run it. Most small teams are better served by containers on a few servers or a managed platform, built so that a later move stays possible. Helping teams choose the smallest setup that works is part of our cloud and DevOps service. If you are weighing this decision, talk it through with us.