What makes Kubernetes so popular in my humble opinion

Since I started work as Site Reliability Engineer I heard a lot about Kubernetes and how it magically solve tons of operational and scalable problems. However, as a Lifelong Learning student and because of my background as professor, I was always asking me what was those problems.

In my life I found that people learn in two ways, or experiencing someone else fails or failing by itself. In both cases you will learn, but in different proportions. Even if in the first we could understand the whole story, the problem, the solution, just "listening" what happened is not enough to really understand all choices and side effects of each one.

So, here I'll try to explain what is Kubernetes by my viewpoint and tracking it with other experiences that I had.

In https://kubernetes.io/ we can find a short definition for Kubernetes:

Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.

Let's decompose this definition at small pieces:

Kubernetes is an open-source system …

Here we found that Kubernetes is an open-source system, which means that, nowadays, it's developing is continuous through the community efforts. Even if Kubernetes is a "fork" of the google's project Borg, it's developing is open for the community.

Here we have our first understanding of why Kubernetes quickly widespread through the community. Tools with big sponsors, such as google, are easily accepted by the technical community. Also, being open-source, it enables the knowledge share, fast feature development and evolution and bug fix.

Another benefit of being easily accepted by the community is the amount of people knowing how to deal with this technology. Only those who have had the experience of recruit someone for a senior or specialist position knows the difficult to found people for these positions (I include myself here). In other words, be a trending technology is good because encourage others to learn this technology, growing either the offers as demands of professional in this area.

Kubernetes is an open-source system for automating deployment …

As a SRE, one of my jobs is to delivery the developer's code into production ensuring a safe, fast and reliable process. For me is here that Kubernetes stands out.

I had experience with Amazon Elastic Container Service which is also a system for automating scaling and management of containerized applications and, of course, the good old copy and paste .jar into the server. In these both scenarios (yes, the second still in use more than we think) the big problem remains in the process, in how to provide that safe, fast and reliable moving into production.

With Kubernetes we have naives concepts such as rolling update which performs an easily and intelligent update ensuring to move to next step only if the last one was successful.

This new viewpoint turns Kubernetes, once it's already deployed and functioning as expected, an easily tool to take care of an application lifecycle.

Kubernetes is an open-source system for automating deployment, scaling …

I used to be developer in my career and I remember to learn how to code an application and deal with a bunch of requests. However, in a real world scenario, we are talking in hundreds or thousands of requests per second (in a common web application). I don't know about you but I wasn't taught to deal with it, and here, again, Kubernetes has a simple and efficient solution.

Dealing with the idea of decoupling our application into small pieces (PODs), Kubernetes provide a variety of scaling trigger for you, such as CPU or memory consumption, or even custom metrics.

Using this simple tool, anyone can have its applications scaling when needed, without any manual intervation. This simple flexibility reduces a lot the operational team headache (trust me…).

Here I don't want to discuss about scale oriented developing against traditional developing, however, it's important to notice that as much as you scale your application, the same will occurs to your billing (if you use some public cloud provider), and here that things starts to get bad…

As an SRE I just want to put a light here saying that the best solution (in my humble opinion, of course) would be a really strait connection between operation team and developer team. Working together, developing to scaling and scaling only when it’s really necessary, could solve a lot of headache.

Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.

As already said, Kubernetes defines a POD as smallest deployable units of an application. Inside a POD you can define all images of your workload (or application).

Dealing with PODs instead of .jar or wherever other extension that your application may have, provides an easily and efficient management system. Tools like kubectl are silver bullets here. It works has a Swiss Army Knife and is the connection tool between you and the Kubernetes cluster.

Kubernetes cluster can encapsulate nodes and PODs in your workload, performing easily and automatically tasks such as move your applications through nodes, scale it up or down, applying rolling updates and so on and so forth. These tasks can be very helpful for operation teams and developers.

So… does Kubernetes worth?

Kubernetes is more than a tool, it is an entire development philosophy. The choice of use or not Kubernetes can't rely only to developer or operational team. This technology can change the entire lifecycle of your business as well as can broke your bill if you do not calibrate your cluster.

I think that the movement to Kubernetes depends of the maturity of your company and the moment that you are. Migrate from another containerized tool to Kubernetes should be easily then migrate from virtual servers with scheduled manually deploys. Moreover, this migration should add the costs of training the operational and developer team and all the downtimes (trust me, will have a lot until your cluster works fine) in this course.

When I was working in a company that used AWS ECS we had a lot of other problems then migrating to Kubernetes, so we decide to postpone it. We invested our time and efforts to improve our reliability, reduce costs and ensure the accomplishment of our SLAs before start to surf in a new technology. This decision helps us to provide more outcomes to the entire company turn them our sponsor for whatever next move we desire in future.

In sum, to use or not use Kubernetes depends more of your ecosystem than your personal desires. I really think that we should use new technologies as soon as we conclude that it make sense for our team, our business and our company.