Kubernetes is excellent at problems many organisations do not have. Here is a straight test for whether you are one of the ones that does.
Kubernetes solves scheduling and lifecycle management for many services across many machines, with declarative configuration, self-healing and a consistent deployment interface. At sufficient scale it is the best answer available.
It also gives portability across providers and a very large ecosystem, which matters to organisations running substantial platform teams.
A cluster is infrastructure that needs upgrading, securing, monitoring and debugging. Networking, ingress, storage classes, RBAC and admission control all become things somebody owns.
That cost is fixed regardless of how many services you run on it, which is precisely why it is a poor trade for small estates.
If most answers point the other way, managed container services or serverless will deliver the same outcome with far less to run.
Use a managed control plane rather than running your own. Keep everything in version control, use a single deployment mechanism, and set resource requests and limits from the start — unset limits are the most common cause of mysterious cluster behaviour.
Then invest in observability early. A cluster without good visibility is very difficult to debug under pressure, and that is exactly when you will need to.
Many teams do not choose Kubernetes; they inherit it. The first task is establishing what is actually running, how it was deployed and whether the configuration exists in version control.
Only after that is it worth deciding whether the cluster should continue to exist. Consolidating onto managed services is a legitimate outcome.
For event-driven and bursty workloads, often yes there is nothing to operate and you pay for use. It fits less well for long-running processes, heavy in-memory state or workloads sensitive to cold starts.
Yes, and it is usually the right sequence. Containerised applications with configuration in environment variables move to Kubernetes without rewriting.
Managed control planes remove much of the operational burden but not all of it. You still own upgrades, networking decisions and workload configuration.
Keep reading
The overspend is rarely caused by the cloud itself. It is usually set in motion by three decisions taken in the first few weeks, often by people who did not realise they were making them.
All four run the same workloads competently. The decision usually follows existing commitments, data residency and the skills already in your team.
A meaningful share of cloud spend on a typical estate is recoverable without changing the architecture at all. Start there.
