Kubernetes is an orchestrator that will ease deployment and automatically manage your application's state. It has become the go-to solution for a lot of companies. However, Kubernetes is quite costly to set up and administrate. As a result, it will most likely not be cost-effective for new projects but may become so once your product starts growing.
During this article, we aim to showcase the main feature of Kubernetes and the use cases in which it is, or not a good idea to go with it.
If you are not familiar with Kubernetes, you can read the first few chapters of my previous article, presenting the global architecture and main concepts. For this article, you need to know that Kubernetes will manage your deployed applications through a control plane, which is basically a few nodes specialized in the orchestration of applicative nodes.
The Advantages of Kubernetes
Once set up, Kubernetes offers you a lot of features right out of the box that would cost a lot more to implement on other systems. We will take a look at those features so that you will be able to determine if investing time in Kubernetes will be worth it for your next project.
1. Self-Healing and Load-Balancing
As an orchestrator, Kubernetes primarily brings self-healing and load-balancing to your deployed applications. It will automatically restart the pods that are not in a stable state and make it simple to scale your application by design.
2. Configurable and Reproducible Build
Thanks to its definition files being written in YAML, a declarative language, Kubernetes is adapted to GitOps by design, enforcing a highly configurable and reproducible build. Those definition files also bring abstraction around concepts that could be complex to implement otherwise, such as update strategies (rolling release, blue/green, canary, ...).
The Primary Cost of Kubernetes: Its Complexity
As with any technology that brings a lot of abstraction and features to the table, there is a steep learning curve to correctly use Kubernetes. Among the operations required to start using Kubernetes, bootstrapping and administering the cluster, with the right ecosystem (OpenShift, Helm, ArgoCD, Istio…) may be the most costly. Of course, if you already know the technology or the tools, you can of course mitigate the costs.
Self-Administered vs Managed Cluster
It is possible to install a Kubernetes cluster from scratch, and the exercise is quite forming. (Incidentally, if you aim to master Kubernetes, I can recommend you to follow the tutorial kelseyhightower/kubernetes-the-hard-way). However, setting up your own cluster is quite complex and brings maintenance. Fortunately, nowadays most cloud providers offer managed Kubernetes services that will abstract away the Control Plane (Azure AKS, Google GKE, Amazon EKS, Scaleway Kapsule, ...). As a result, you will be able to deploy applications quickly and efficiently, which almost annihilates the first issue we listed before.
Settling for an Ecosystem
A lot of tools around Kubernetes can enhance your experience by adding automation to the deployments (ArgoCD), extra monitoring and interfaces (OpenShift), or even more features (Helm, Istio). However, they will require additional investment to understand their place in the ecosystem and design the right architecture.
Watch out for Stack Complexity
Incidentally, using Kubernetes will also affect the general performance, like any other abstraction layer. In the general case, your Pods will host multiple Containers, running on a Node. This Node will most likely be a virtual machine hosted on a bare-metal server. Each layer brings latency to network or disk requests and burns a bit of CPU and memory to run. This will be harmless for most applications but maybe impactful for operations heavily using a component of your system.
Use Cases
Each project is different, but we will try to cover the most likely scenarios that may happen through 3 uses cases. During these, we consider that you do not already know Kubernetes but are interested in using it in the long run. So that there is a cost to the migration but a potential return on investment later.
1. Starting a New Project
For a starter, let’s say that you are exploring using Kubernetes for a brand new application. In this scenario, the technological state of your project is not impacting the choice, as you can shape it around your decision. As a result, the central decision point becomes the complexity of your application. For instance, if you want to host a mostly static website or with low traffic, some specialized platforms (e.g. Heroku) may be cheaper and easier to maintain. On the other side of the spectrum, if you are creating a computational heavy service, you may need to reduce overhead brought by abstraction layers, which could reduce the interest of Kubernetes.
2. Migrating Containerized Services
Kubernetes is working with containerized applications. As a result, If you already have a set of containerized services, the migration can be quite easy and may even reduce your costs in the long run by reducing the amount of manual maintenance required. Watch out for stateful applications that use disk volumes, however, as they are much more complex to reliably configure than their stateless counterparts.
3. Migrating a Monolyth
Finally, and that could be the case of numerous companies, you may have a monolithic application that you want to separate as microservices, and use Kubernetes to host those. This is a good idea but maybe a hassle to do so in one operation. As a result, depending on your available resources, you may consider integrating less complex container-based technologies such as Docker Compose or Docker Swarm. It can help you grasp concepts that are essential to Kubernetes, with an acceptable go to production time.
Conclusion
Kubernetes is very good for projects built around atomic services that aim to scale and require high availability. It provides you with a fully dynamic environment able to heal automatically at need.
The only reason why you may not want to use Kubernetes right away would be in the cases where the return on investment is not interesting enough. For instance, in the case when:
Your project is trivial and will not take advantage of most of the features provided by Kubernetes.
Your project is very complex and would require extra investment to keep acceptable performances.
You have limited resources and missing a deadline may be harmful to your activity.
The following chart is a summary of the points above, aiming to help you in your decision:
...
Want more Kubernetes content? Check out the trailer for our new documentary!
