Kubernetes is great, but you don't always need it

What does Kubernetes do?

An application can be packaged in a container with the software it needs to run. Kubernetes manages those containers across a group of machines. You can tell it how many copies of an application you want running, for example, and it will try to keep that number available.

If a container fails, Kubernetes can restart it. If a machine fails, Kubernetes can create replacement workloads elsewhere, provided there's enough capacity and the application and its storage are set up to allow it. It also gives you ways to control how applications share resources and decide where they run.

I like the consistency this brings when there are lots of workloads to manage. You can describe how an application should run and use the same general approach across different environments. There is still plenty to configure, though, and Kubernetes won't fix an application bug or make a database resilient on its own.

When might Kubernetes be a good fit?

I'd consider it when an organisation has several applications or teams that need a consistent way to deploy and run software. If every service has a different deployment process, or teams spend a lot of time managing individual machines, a shared platform could make life easier.

It can also help when different parts of a system need to scale independently. You might have an API that gets much busier during the day and a background worker that needs more capacity overnight. Kubernetes can manage those workloads separately, although you still need to understand how each one behaves under load.

Our multi-region setup at work is an example of an environment where consistency across clusters matters. It has also shown me how much sits around Kubernetes itself. Cross-region failover needs careful design and operation, including consideration of how traffic and application dependencies behave when a region is unavailable.

Sometimes simpler is better

A managed application service can be a good choice when you want to deploy an application without maintaining the machines underneath it. The provider handles more of the infrastructure, leaving your team to focus on the application. Before committing, check the service supports what you need and that its pricing makes sense for your expected usage.

Running a container on a virtual machine gives you more control and can be perfectly reasonable for a small setup. You'll need to maintain the server, arrange deployments and monitoring, and know how to recover if it fails. Whether that's a good trade depends on the experience and availability of the people doing the work.

Managed Kubernetes takes some cluster responsibilities off your hands and can make sense when you need its capabilities. Your team will still have applications and platform components to maintain, and the exact split of responsibilities depends on the provider. Running Kubernetes yourself gives you more control again, but also more responsibility for keeping the cluster secure, available and up to date.

I'd compare these options against the actual needs of the project. A system doesn't have to use Kubernetes to be reliable, and a managed service isn't necessarily the cheapest option once you understand the workload and the pricing.

Two examples

Imagine a small business with one web application, a database and a small team. Traffic is fairly predictable, and the team wants to spend most of its time improving the product. I'd first look at a managed application service and a managed database, with a plan for deployments, backups and monitoring. If the business later runs into a limitation that those services can't handle, there would be a reason to reassess.

Now imagine a product with several teams deploying multiple services. Each service has a different deployment process, and maintaining those differences is taking up more and more time. I'd want to find out where the problems are before suggesting a solution. Managed Kubernetes might provide a useful shared foundation, but the team would also need to account for migration and decide who would maintain it afterwards.

I've made these examples up to show how I'd approach the decision. In a real project, I'd want to understand the application and talk to the people who build and support it before making a recommendation.

A closer look at autoscaling

Autoscaling is often mentioned as a reason to use Kubernetes. It can adjust the number of application copies based on metrics such as CPU usage, but there are a few things to think through before relying on it.

The application needs to work properly with multiple copies running. If a user logs in and their session is stored only in the memory of one copy, what happens when their next request reaches another? You'll also need a suitable metric and, when scaling on CPU utilisation, appropriate resource requests and a working metrics source.

Starting another copy takes time, and there needs to be enough capacity available for it to run. Adding copies can also put more pressure on the database or another service the application relies on. It's worth testing under load so you can see where the bottlenecks are and how long the system takes to respond. The Kubernetes autoscaling documentation is a good place to start if you want the technical detail.

Who looks after it?

When comparing hosting options, I'd look beyond the monthly infrastructure bill. The time people spend deploying changes, investigating problems and maintaining the system is part of the cost too. Those responsibilities don't disappear because a service is managed, although the provider may take on some of them.

For any production application, I'd want to know how changes are deployed and rolled back, how the team finds out something is wrong, and who responds. There should also be a clear plan for access, security updates and backups, including testing whether those backups can actually be restored. With Kubernetes, you also need to understand who is responsible for the cluster and any additional tools running on it.

Anyone can start learning Kubernetes, and I'd encourage them to. My homelab has given me space to experiment, break things and work out how they fit together without the pressure of a production incident. You don't need to know everything before you start learning, but a production system does need people with enough time and support to maintain it.

Questions I'd ask before deciding

When I'm considering a platform for an application, these are the kinds of questions I'd want to work through with the team:

• What's difficult or unreliable about the current setup?
• How many applications need to be deployed independently, and who deploys them?
• How much downtime can the business tolerate, and how quickly does it need to recover?
• How does demand change, and what do we know about the application's current limits?
• Who will maintain the platform and respond when something breaks?
• Is there anything a simpler managed service can't provide?
• What will each option cost in infrastructure and engineering time?
• How could we test an approach before committing to a migration?

The answers give you a basis for comparing the options and explaining the decision to the people who will pay for, use and maintain the system. If you're working through that decision yourself, or wondering whether your existing setup is still right for your team, get in touch. I'd be happy to hear what you're trying to solve.