loading...

Do you really need Kubernetes in your company/startup?

anortef profile image Adrián Norte ・2 min read

Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.

Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.

You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops

And of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?

Docker-Compose

Its a tool written in Python that let you define environments using YAML.

The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.

The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.

Docker Swarm

It's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.

In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
You can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.

The only problem is that it lacks good observability when reaching a good size.

Kubernetes

Kubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.

The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.

The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.

My Conclusions

The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.

Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.

All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.

Discussion

pic
Editor guide
Collapse
skatkov profile image
Stanislav(Stas) Katkov

I would even say, that you don't really need Docker at all. Just use some reasonable PaaS platform in the beginning - Heroku, Convox (my favorite), Cloud66.

Collapse
anortef profile image
Adrián Norte Author

The problem with PaaS is that they are not really friendly towards the local environment for development and QA.

Collapse
skatkov profile image
Stanislav(Stas) Katkov

They also don't consume gigabytes of memory, like docker client does on my Mac machine.

I also don't really need a resemblence with production environment on my local machine, if my architecture is simple enough.

More then that, if system becomes complicated - there is declarative NixOS.

Thread Thread
petermbenjamin profile image
Peter Benjamin

All good points.

Just worth clarifying:

  • Docker itself is not that resource intensive. I have Docker running on Raspberry Pi Zero (512mb ram + single 1ghz arm cpu) hosting a few small home automation projects without a problem. The resource consumption on macos and Windows comes from the virtual machine that Docker manages to host the Docker daemon.
  • Even for small/simple product architecture, you can benefit from Docker in the development workflow, even if your whole architecture is a web app + database.
  • Kubernetes developer tooling is getting better. Now, there are tools that allow you provision lightweight Kubernetes clusters locally (in VMs, or in containers, or directly on Linux hosts)

But, I agree. With all that, you may not need Kubernetes.

Collapse
cescquintero profile image
Francisco Quintero 🇨🇴

Why not? I've used Heroku for tons of Rails apps and also for handful of SPA ones that were developed locally. :thinkingface:

Thread Thread
anortef profile image
Adrián Norte Author

The good thing about a local environment that resembles production to the maximum extent possible is that you are integrating and facing problems that will not be faced in prod. PaaS services just reduce the length of similarity between your environment and the one your app will run on when your clients use it.

Thread Thread
cescquintero profile image
Francisco Quintero 🇨🇴

Ok. Now I see your point and agreed with it. Giving a second thought to the apps I've deployed to Heroku, they're small ones or in their initial stages. Once they get to be used by real users, they're moved to AWS or Linode.

Collapse
theodesp profile image
Theofanis Despoudis

In general, once you tried Kubernetes in production, you won't go back to Docker Swarm or Docker

Collapse
anortef profile image
Adrián Norte Author

I do not deny this, but the key is to be able to answer the "why". So, why do you think so?

Collapse
theodesp profile image
Theofanis Despoudis

What's not to mention. Ecosystem tooling, support from the community, stability of the platform, all the greatest minds passionate about it, real business value, stress-less rollouts etc.

Thread Thread
anortef profile image
Adrián Norte Author

Docker also has a very rich ecosystem tooling, support from the community, stability and great minds being passionate about it and can do everything you say.

What I try to say is to not take things at face value because that is how you get operational costs through the roof.

Thread Thread
theodesp profile image
Theofanis Despoudis

Costing with Kubernetes is not an issue. For example with Azure you pay for what nodes you use and it can be as little as 30 euro per month. With DO it can be even cheaper. In addition Kubernetes has advanced scheduling algorithms making ideal for parallel jobs or resource optimization problems. You just need to declare the resource constaints for each deployment and Kubernetes will find the best fit. It will work even if a node dies.

Try to do that with Docker and you will find yourself reinventing the wheel and probably with a heftier bill.

Collapse
bzon profile image
Bryan Sazon

You are correct, Kubernetes is very complex. I would only recommend this to a startup or a small company if the following conditions are met:

  • Your system is designed to be scaled into multiple services.
  • You have the budget to learn Docker and Kubernetes.
  • You have the budget to learn and maintain deployment tools for Kubernetes.
  • You have a developer that is experienced and well-versed in Kubernetes OR you have the budget to hire a DevOps K8s expert to maintain your cluster and train your engineering team!

For example, in my current team, I'm their backend developer and also their DevOps guy. I have 3 years of experience in Kubernetes but I still find it hard to teach Kubernetes to developers especially for those that have no experience in containers (Docker).

Collapse
xlebenny profile image
Benny Leung

You haven't Ingress and StorageClass in localhost
:(

Collapse
anortef profile image
Adrián Norte Author

In Kubernetes there is a StorageClass for local volumes and you can always try to put Traefik for the Ingress using Helm.

Collapse
ajnasz profile image
Lajos Koszti

if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you only need a webserver

Collapse
anortef profile image
Adrián Norte Author

You would be surprised with the amount of "preparation" some folks do, like prepare to scale to millions with one user while neglecting other things.

Collapse
flakesrc profile image