Do you need Kubernetes?
Previously I wrote about why it’s a good idea to have a platform team for Kubernetes. I argued that Kubernetes isn't optimal for small organizations lacking the resources for a dedicated platform team. If Kubernetes is complex and needs a dedicated team, then who should use it? And if Kubernetes isn’t right for you — at least right now — what should you use instead?
What’s so great about Kubernetes anyway?
Kubernetes is very popular these days, and it’s not just hype: it provides excellent abstractions for hosting web applications of various kinds and can scale to host huge services.
If you want to provide a reliable web service to your users, you’ll need to worry about a lot of things:
What happens if a server hosting the service fails?
How to expose the service to the outside world?
How to add computing resources when needed?
How to safely deploy new versions of the software without any downtime?
You’ll need to solve these and many other problems one way or another, and Kubernetes provides good solutions. It is not the only way to solve these, but it is a pretty good one.
One key benefit is the de facto standard API: a lot of supporting software integrates with Kubernetes, so you’ll have many choices regarding monitoring, security, and other necessary tools. With many managed solutions, the easiest or even only alternative is integrating with other software in the same operator’s walled garden, introducing lock-in risks that Kubernetes does not have.
There are specific use cases for which Kubernetes is especially suitable. If your use case fits one of these, then the odds are pretty good that Kubernetes is a good choice for you:
Massive scale: if you are serving millions of daily active users, a properly architected Kubernetes setup is probably cost-effective for you. Serving a small number of users can be expensive, but as you scale up, costs don’t ramp up as much with Kubernetes as they might with some other alternatives.
Multi-cloud: if you use multiple cloud providers, Kubernetes can act as an abstraction layer that allows you to manage your applications through the same API everywhere.
Hybrid cloud: similar to multi-cloud, if you need to run things both on-prem and in a public cloud, then Kubernetes can help you manage applications the same way in both environments.
Next, let’s look at some of the alternatives. These alternatives might be better if the operational overhead of running Kubernetes is currently not justifiable for your use case. Since there are so many other options available, this will not be an exhaustive list by any means.
What are the other options?
Let’s get one thing out of the way: for greenfield projects, plain old virtual machines are not a good alternative to Kubernetes. If your organization is already familiar with VMs, it may seem tempting to use what you already know. However, you should carefully consider the long-term implications.
Matching the quality and fault tolerance of Kubernetes is difficult with a traditional virtual machine infrastructure. Your VM setup will be unique to your organization, so onboarding new employees to run it will be a lot harder. You might save yourself a lot of work by just going with Kubernetes.
Having said all that, if you already have a setup like this that works for you, then migrating to Kubernetes is a big undertaking, and it depends on your situation whether it is worth it — if it ain't broke, don't fix it.
If Kubernetes is currently overkill for your organization, consider managed platforms where the provider takes care of maintenance. For example, all three major cloud providers have services that allow you to run a containerized workload without worrying too much about where and how it’s running: Amazon has ECS, Google has Cloud Run, and Microsoft has Azure Container Instances. If you decide to migrate to Kubernetes later on, the transition is easier because you are already running your application in containers.
There are various platform-as-a-service type offerings as well; Heroku is probably the best-known example. They allow you to run your application as-is without modification, and there is no need to worry about infrastructure. These services can be an excellent way to get started quickly, but their limitations may become apparent later on, and costs can ramp up quickly as you scale.
There are also various serverless solutions like AWS Lambda or GCP’s Cloud Functions, where you just write the code and define when to run it. These can be cost-effective for specific use cases where there is little traffic with the occasional large request spike. Vendor lock-in can be an issue with serverless, but open-source solutions like Knative or the Serverless Framework ease lock-in concerns. Perhaps more than vendor lock-in, serverless has an architecture lock-in problem: migrating from serverless to other architectures can be difficult because it’s so different from other alternatives. Say you’ve been running serverless functions in a cloud and are now required to migrate the application to on-prem. It can be a considerable undertaking to either convert the application to a more traditional architecture or set up a similar on-prem serverless capability.
You could also choose to go with a mix of different options. For example, using serverless for some specific tasks while hosting the main application on more traditional infrastructure is a fairly common pattern.
It depends
Here’s a rough guideline: when your scale is small, it is more cost-effective to buy than to build, but as your scale grows, it starts to make sense to build more yourself. However, you’ll need to consider this advice in your context.
To give you an idea of how context affects the choice, let’s look at some concrete examples where Kubernetes could be a good option:
Your organization is a large corporation with many development teams. Each is responsible for one or more microservices that comprise an application with millions of daily users.
You have a startup whose application requires heavy data processing, and you expect to grow your user base steadily. In this case, managed services can get expensive quickly, or they may not have the computing power that you need.
You are required to host your application or some parts of it on-prem, but you still want to have similar features that are available on cloud platforms. If you are using Kubernetes in the cloud, it can also make sense to run it on-prem to use the same tools and ways of working everywhere.
On the other hand, Kubernetes might not be the best choice if:
You have a small startup with limited resources that needs to deliver a minimal version of its product to end-users as soon as possible.
You have an established architecture that works for you, is cost-effective, and doesn’t have any significant issues.
Your application is simple, and you never expect to scale to a large number of users.
Whatever choice you make, it’s essential to keep your architecture flexible. That enables you to pivot if your circumstances change. For example, if you use containers, it will be easier to migrate to Kubernetes if you decide to adopt it. Some services are also specifically designed to make it easy to migrate to Kubernetes later on, like Google’s Cloud Run.
Conclusion
Before using Kubernetes, you should always have a clear idea of the exact problems you are trying to solve. There’s no correct answer to whether you should run it or not, and you know your own context best to make the optimal decision for you. Hopefully, this blog post has given you insights about what to take into account when considering using Kubernetes.
Risto Laurikainen is a DevOps Consultant with a decade of experience in building cloud computing platforms.