Kubernetes orchestrates containers across many machines — scheduling, scaling, restarting and networking them. It is genuinely powerful and genuinely heavy, and most projects that adopt it would have been better served by something simpler.
What is Kubernetes?
Kubernetes takes a fleet of machines and treats them as one pool of capacity. You describe the state you want — this many copies of this service, with this much memory — and it works to keep reality matching that description, restarting what fails and rescheduling around a dead machine.
At real scale that is enormously valuable. Below it, you have taken on a distributed system to run a website.
The pattern we see most often is a client who has been told they need it, usually by a proposal rather than a measurement. The honest question is not whether Kubernetes is good — it is — but whether the problems it solves are problems you currently have.
When we choose Kubernetes
When there are many services and a team to operate them. Below roughly ten services and a dedicated platform person, simpler tools do the job with a fraction of the burden.
When the client already runs it. Adding a service to an existing cluster is straightforward and the operational cost is already being paid.
When we do not use Kubernetes
For almost everything we build. A website, a web application, even a system with three or four services runs perfectly well on a managed container platform or a couple of VPS instances, with a fraction of the operational surface.
We will say this plainly when a client arrives asking for Kubernetes because it appeared in a proposal. Adopting it without the scale or the team to run it is the most expensive architectural mistake available in this category.
What we build with Kubernetes
Deployments into an existing cluster
Where a client already operates Kubernetes, we package the application to fit their existing conventions rather than introducing a second way of doing things.
Migrations into a client's platform
Taking an application we built and fitting it to an enterprise's existing cluster conventions — their ingress, their secrets management, their monitoring — so their platform team can operate it like everything else they run.
Right-sizing an existing cluster
Where a cluster was adopted early and now costs more than the traffic justifies. Sometimes the recommendation is to keep it and tune it; sometimes it is to move off it, and we will say which.
Cost and capacity reviews
Auditing what a cluster actually runs against what it actually needs. Over-provisioned workloads and forgotten services are common, and the saving is usually large enough to pay for the review several times over.
How we ship Kubernetes projects
On a managed service rather than a self-built cluster. Running the control plane yourself is a job, and it is not a job that helps the client.
With resource limits set on every workload, because the most common cluster failure is one service consuming everything and taking the others with it.
With health checks and graceful shutdown configured properly. A cluster that restarts a pod mid-request because a check was misconfigured produces intermittent failures that are extremely hard to trace back to their cause.
What Kubernetes costs you
The learning curve is steep and the operational burden is permanent. Someone has to understand it at 3am, and that person has to exist before you adopt it.
It is also more expensive to run than the equivalent capacity elsewhere, because the control plane and the redundancy are not free.
The cost that surprises people is not the servers, it is the attention. Certificates expire, controllers need upgrading, a node runs out of disk. None of it is hard and all of it needs someone whose job it is, which is why we ask about the team before we ask about the workload.
Kubernetes questions we get asked
Almost certainly not, unless you already run it or you have more than about ten services and someone whose job is the platform. For everything smaller, a managed container service or a couple of servers does the same job with far less to go wrong.
A managed container service, or one or two servers running Docker with a simple deployment script. Both give you reproducible deploys and easy rollback, which is what most teams actually wanted from Kubernetes, without the cluster to operate.
Roughly when you have more services than people who understand them, and someone whose actual job is the platform. Before that, the operational burden falls on developers who should be building the product instead.
Yes — we deploy into existing clusters regularly and follow the conventions your platform team has already set rather than introducing our own. Two ways of doing things in one cluster is worse than either way on its own.
Usually not at the scale being described. A single well-sized server handles more traffic than most people assume, and adding a second one behind a load balancer covers most of the rest. Kubernetes solves scaling across many machines and many services, which is a different problem from having more visitors than you used to.
Yes, and it is easier than most people expect if the application is containerised — the containers run anywhere. What you unwind is the orchestration config, not the application. We have done this for clients whose cluster cost more in attention than it returned.
Yes, and we often do. Recommending a cluster to a client with four services and no platform engineer would be selling complexity we would then be paid to manage. Our advice is usually a managed container service and a smaller bill, and it is the same advice whether or not it wins us the work.