I frequently get asked on LinkedIn if Kubernetes is complicated. In this post, I'll walk through the arguments and answer. I'll also explain you when you do and don't need Kubernetes.
Before looking at the complexity of Kubernetes itself, we need to look at Docker containers, as they add complexity too. Is that complexity worth it?
Almost everyone will agree that even when you decide not to use Kubernetes, you still should use Docker. It also isn't hard to deploy a Docker container to AWS or another cloud provider without Kubernetes. You just need to setup a virtual machine running the Docker daemon.
The main benefit of Docker containers is that they are self-contained bundles. They decouple your application's environment from the machine it runs on. You no longer need to care what library or Python version is present on the host, because the Dockerfile makes your dependencies explicit. If it works on your own machine it will work on any machine. Docker is not quite infrastructure as code, but Dockerfiles do let you define an application runtime as a simple file in your git repository.
One more benefit of Docker containers is that they are distributed application bundles, designed for a world of immutable infrastructure. In other words, they were designed to be state-free. Containers are ephemeral by nature. It's OK if they die and are rebooted.
You don't need Kubernetes when the following four conditions are true:
In other words, if you have simple requirements then there is a simpler alternative to Kubernetes. You can deploy containers directly to Docker daemons running on a few virtual machines.
You do need Kubernetes when you have the usual set of real-world requirements that every fast growing team eventually runs into:
For the above requirements, you need "Docker container infrastructure", meaning infrastructure that is optimized for deploying Docker containers, at scale, dynamically, and connecting them all to one another and to other cloud services like storage.
The most popular form of that infrastructure is Kubernetes. Why not run Kubernetes if those are your requirements? Sure it is complex, but every solution that satisfies those requirements will have similar complexity.
At least with Kubernetes the complexity is open source and standardized in the form of declarative Kubernetes APIs. This is superior to other public cloud or in-house solutions.
Here is a typical claim by a hater:
Kubernetes and Docker are unnecessary because autoscaling is easy, systemd does self-healing, the cloud provider has APIs for persistent volumes, backups should be done with cronjobs on the host, secrets are done with MyFavoriteSecretVault, Consul does configuration management, service discovery is DNS, health checks aren’t necessary, and a dude on Reddit wrote a 3000 line Perl script for rolling updates at his last company so clearly Kubernetes is unnecessary.
To these people, I can only say good luck. Also, you’ve re-invented Kubernetes.
The biggest disadvantage of Kubernetes is that it front-loads a lot of the complexity. The complexity is justified, but there is a lot to learn up-front.
We're trying to improve that with Robusta.dev by providing a single pane of glass that identifies in real-time common Kubernetes errors and suggests fixes. Best of all, you can get notifications about problems like CrashLoopBackoffs in Slack and MS Teams. If that sounds useful to you, please check it out!