2021-08-05

You don't need Kubernetes

Everyone using kubernetes, even they don't have to, which adds additional complexity. In this article we will discuss when we need Kubernetes, and when we don't, and what's the alternative?

When you need Kubernetes?
  1. If you have lot of teams (>3) and services, it's better to use Kubernetes or any other orchestration service to utilize your servers
    Why? because that way they can deploy each services independently, and service mesh management is far easier if using orchestration.
    Alternative? use Nomad or standard rsync with autoreloader (eg. overseer if you are using Golang) or if you are using dynamic languages (or old CGI/FastCGI) that are not creating own web server usually you don't need an autoreloader since source code on the server anyway and will be autoreloaded by the web server
  2. If you have more than 3+ powerful servers, it's better to use Kubernetes or any other orchestration service 
    Why? with orchestration service we can binpack and fully utilize those servers better than creating bunch of VMs inside the servers
    Alternative? use Ansible to setup those servers, or Nomad to orchestate, or create a script to rsync to multiple servers
  3. If you need canary or A/B deployment
    Why? creating canary-like deployment manually (setting up load balancer to send a percentage of request to specific nodes is a bit chore)
    Alternative? use Nomad and Consul service registry
  4. When you are using slow programming language implementation that the first bottleneck is not database but your API/Web requests implementation
    Why? normally if you code using compiled programming language, the bottleneck is not the network/number of hits, but the database, which usually solved with caching if it just read, or CDN if static files. But when you are using slow programming languages (eg. Ruby, Python, PHP5, etc), you mostly will hit bottleneck on the API/Web requests side first before the database. So you'll need to spawn additional pod to handle those requests.
    Alternative? Amazon AutoScaling, Google Cloud AutoScaling Group, Azure AutoScale, or just do a capacity planning and scale up/out manually before the peak season (eg. Black Friday, Christmas,  discount day, etc) and scale down/in after peak season ends.
When you don't need Kubernetes?
  1. When you only have a little <=3 or bunch of least powerful servers that are utilized well.
    Seriously you don't need it, just a simple rsync script (either manual or in CI/CD pipeline) or ansible script would be sufficient
  2. When you are alone or in a small team (no other team), writing modular monolith is fine until it's painful to build, test, and deploy it, then that's the moment that you will need to split to multiple services.
  3. When you only have production and test environment without A/B or canary deployment.
    Again, Kubernetes will be totally overkill in this case.
    1. always cache reads
    2. prepare for nth server when it's already 70% load (you need to provision nth node anyway if kubernetes also hit the load), either manually or use cloud providers' autoscaler
    3. put slow tasks/computation as background job, so web services could always respond fast. Even when you have autoscaler for APIs/web services, if the bottleneck is the database or I/O (which is more likely than the processor/computation), it would be totally useless.
  4. When you don't want Kubernetes to be the 30% overhead your servers, use lightweight orchestration and service discovery instead, like Nomad and Consul.
Well, for the last part, you are mostly don't need Kubernetes, don't be eaten by the hype, especially if you deploy databases on the pod, it's unstable AF, you don't need to automatically scale out/in the databases anyway (usually scale up if the database product is quite hassle to scale out), it would be a crazy thing to move around gigabytes of data because the automatic scaling. I hope this article could help people that started to build their startup to start provision with proper capacity planning and releasing instead of prematurely optimize their architecture and infrastructure with Kubernetes.

FAQ

So, what are your qualification saying this?
I worked for small companies (<7 engineers) and huge companies (700+ engineers) that are both using Kubernetes, and I realized the difference why one is a must, and why the other one is just decision based on hype.