Why Does Everybody Want to Use Kubernetes?
What’s the big deal?
To be honest, I’m a Kubernetes lover. Kubernetes is a considerable step forward in software development. When I met it, I thought “that’s the way to bring containers in production.” I didn’t have any hesitation. Like me, thousands of architects have successfully embraced this technology.
Let’s look at how Kubernetes can solve most of the issues deploying applications to the cloud, supporting our infrastructure to meet the requirements of cloud transformation.
Remember Your Goals
In the cloud transformation era, there are some targets for all companies.
These prerogatives are:
- Move to the cloud asap (cloud migration).
- Reduce sysadmin cost, infrastructure cost, time of people (cost reduction).
- Reduce the time needed to complete projects (time to market).
- Have reliable systems with good performance (improve quality).
With these goals in mind, we can land on the cloud and ask “Well, what next?”
It’s easy to get lost in the wealth of solutions, especially for those approaching the cloud for the first time. To make the situation even worse, you cannot fail. We’re not joking. Cloud or not, a project has to work today and tomorrow, when it will require double the functional requirements and integrations.
That’s why cloud transformation is hard — you have to bet on the right horse and you cannot lose. In the next steps, we’ll learn why Kubernetes is the right horse and why everybody should bet on it. Everybody needs Kubernetes!
Why Containers?
Before asking why we want Kubernetes, we have to wonder why we need containers. Containers are a big revolution in software development because they bring the production to our local environment. No more worry about Linux or Windows compatibility. With containers, all issues are easily reproducible in all workstations. Moreover, each environment is portable with no extra effort. Developers have the power of package application and this is good because they know how the application should work. On the DevOps side, containers are beautiful because each deployment system handles only one kind of artifact: containers. Moreover, all build processes can be described in Dockerfile on the dev side, and this means that you will use only one way to build things, the same in local dev and continuous integration.
Container means fewer things to maintain, no differences between environments, and less friction.
Container images can be built and pushed to a registry. From here they can be pulled and deployed anywhere — your desktop, virtual machine (on-premises or in the cloud), or serverless solution, like Heroku. The real advantage of containers compared to virtual machines is that they virtualize the operating system, not resources. This translates to a lighter, easier and economical way to host applications.
Managing containers for production is a demand.
Why Kubernetes?
The previous section explains why everybody has moved to the containers, but not why we should need Kubernetes. Anyway, it’s a fact that we must use containers. This introduces a new need. How can I manage them? How I can reliably orchestrate them? The answer to these questions is Kubernetes.
With Kubernetes, you just need to push images to a docker repository and wait. All the deployment part is managed by Kubernetes, so there is no more worry about infrastructure.
Kubernetes is the leading container orchestration solution. It’s open-source and derives from the Google experience. Its infrastructure allows orchestration of containers and integrates with old-way systems. This means you can install it on-prem or cloud and even in hybrid-cloud solutions.
So — the reasons for using Kubernetes are that it is a stable, reliable, easy-to-use solution. Simply, it’s the best way to deploy containers.
Is Kubernetes Serverless?
Is Kubernetes serverless? Kubernetes and serverless are very different terms of comparison, I agree. Serverless is more a philosophy while Kubernetes is a tool. Let me come back to the initial goals, just for a moment. We stated that we need to reduce dependency on the operating system and effort of maintenance — this is serverless.
So the question is, does Kubernetes achieve this goal? The short answer is yes, it does. Here’s the long answer:
The strict meaning of serverless is to deploy something without asking who is running this code and, even if Kubernetes abstraction hides the most complexity, there is something you have to know about the server part. You still have dependencies on the OS of every single container, for example. There’s the dependency from the specific version of Kubernetes running under the hood. This means that, theoretically, Kubernetes is not serverless.
Anyway, let’s see some serverless solutions.
Heroku relies on containers. You can also deploy a container to it. Most of the lambda functions have containers under the hood.
There’s a reason why we can consider a cloud version of Kubernetes to not be serverless: because it’s based on containers and depends on an operating system, while Heroku or lambda services that do the same are considered serverless.
That’s why I consider Kubernetes to be a serverless solution, even if the strict definition tells the opposite. The real world is not black or white and the level of abstraction and independence from the operating system, resources that a cloud version of Kubernetes gives to me, are enough.
I don’t want to be too precise. Regardless of labels (serverless or not), Kubernetes is a good way to go cloud easily, reduce sysadmin cost, infrastructure cost and reach, and improve quality. So don’t worry too much about labels and pick what will help you.
Advantages of Kubernetes
Kubernetes is a great platform to exit safely the traditional virtual machine shield and go to the cloud. It brings dynamism, reduces the sysadmin cost and pushes the service to a level of quality that would hard to achieve in any other way. Many traditional issues like networking and data protection can be overcome by the advanced configuration of Kubernetes itself.
Here’s a list of benefits this solution brings“:”
- Scalability. You only have to deploy a container. Then, without any effort, you can set the scaling policies. The only thing you have to worry about is having enough money on your credit card.
- Transparency. Each container does one thing. All relation between containers is mapped onto configuration files. There’s no way to miss something or hide some behavior.
- Time savings. The process is extremely simple. Any steps are easy to reproduce.
- Version control. By design, each deployment is versioned. With little effort, you can map your infrastructure in a source file you can version on Git.
Among other possibilities, Kubernetes simplifies all the DevOps stuff, bringing you very near to a NoOps configuration. The friction between dev and operation teams is reduced because there is a clear separation of responsibility and transparency.
Some other cherries on the cake:
- Horizontal autoscaling. Kubernetes can scale automatically, adding nodes to the cluster and adjusting the physical resources available. Moreover, it can scale the logical resources, augmenting the number of pods for a given service.
- Clever updates. Each time you update a container image, the release is done with love. The old pod is available until the new one comes up and only then destroyed. This translates into zero-downtime deployments.
- On-prem or cloud. Is there another option than the cloud? Yes. I will always prefer the full cloud solution but if you’re in a scenario that requires an in-house deployment there are no issues.
- Vendor lock-in. Kubernetes is Kubernetes on every public cloud. This means that if you’re not satisfied with your vendor you can move with little effort.
- No development caveat. Every containerizable software can be deployed in a click. This means your dev doesn’t have to learn new things.
What to Take Home
The flexibility of Kubernetes is immense, clear, and you can manage with low effort, using a cloud solution. When I discovered it I marked it as a working and safe solution to reduce work and responsibility. You can have all the pros of a classic infrastructure, setting us a NoOps process with a small effort, without rewriting the application. Compared with many other glittering solutions, like serverless, it sounds more concrete. Serverless is good, but in complex scenarios, it’s not so easy to employ. Logically, you need a big mind change to employ edge technology like lambdas. And forcing a mind change on devs is not easy, as we know.
Reducing effort on the sysadmin side, having easy deployment and infrastructure that does the hard work for you is a requirement these days. Kubernetes does that.
If I had to design an architecture tomorrow, especially for an enterprise solution, I would play with containers and Kubernetes as the first choice. Maybe using Kubernetes in the cloud, to reduce sysadmin cost. Maybe with DevOps pipeline based on configuration files hosted on Git.
This solution has few dependencies from OS, few dependencies from vendors, and all the infrastructure leans on code.
Somebody could tell it is not fully NoOps and not fully serverless. But it is stable, modular, scalable and satisfies the most important design goals. So the question is, why not use Kubernetes?
Can we do better? Yes. Can we make more effort reducing? Yes. We can always do better, we can always have more.
But, in the end, Kubernetes is a good compromise. In most cases, it’s a guarantee of success.
