5 Questions To Ask Before Adopting Kubernetes

Source:-https://containerjournal.com

It may seem as if these days everybody is using Kubernetes. There’s a lot of hype. But the truth is, most companies are still using virtual machines and on-premises data centers, and that’s quite fine. Before you go and adopt Kubernetes, I want to share with you some misconceptions about Kubernetes and help you understand those problems won’t be magically solved by adopting it.

Will Kubernetes Reduce Your Costs?
One of the most popular reasons to adopt Kubernetes is to reduce costs. After all, if you can magically reschedule all your workloads in a much more efficient way, won’t your cloud bill suddenly go down?

First things first—you have to understand microservices are very inefficient by nature. Every time you hand off work across the (virtual) network, you pay for serialization and deserialization costs, memory copies (which traditionally both the kernel and the runtime have been working hard to avoid) and potentially various middlewares such as service-meshes and security software.

This pattern does not offer efficiency—it offers scalability, which is quite a different beast. And it’s obviously only relevant once you pass a certain scale. If you can run much of your workload on as many cores as fit inside a single computer, you are not at that scale yet!

The truth is that Kubernetes is quite good at packing lots and lots of light container workloads into fewer nodes. But, if your workload is containerized by nature, you are probably already using Kubernetes (or Docker Swarm, or Mesos, for that matter). On the other hand, if your workload is not heavily containerized, you have little to gain by moving to Kubernetes.

Will Kubernetes Be Transparent for Your Developers?
If your domain lies in site reliability engineering or DevOps, you might be thinking that adopting Kubernetes is in your realm and has little or nothing to do with your software engineering team. The truth is quite different. While running workloads on Kubernetes won’t require every single member of the team to understand the intricacies of Kubernetes ingresses, they are definitely going to have to know their way around.

Whether it’s spinning up a development environment (local or in the cloud), running basic `kubectl` commands on it or just being able to have a bird’s eye view of the architecture, your developers are going to be a part of this journey. You better have them onboard.

Will Kubernetes Help Break Down Your Monolith?
Many companies are struggling with an out-of-date monolith (often written in Java or C#) that they are looking to revolutionize. You might be one of them. The promise of migrating to a modern cloud-native technology seems enticing.

And yet, you have to realize most migration processes tend to be more of the “lift and shift” kind. Meaning, you are gonna be stuck with the same old monolith, except it’s gonna be running inside a much more complex and hard-to-access environment, instead of a plain old VM.

Breaking down a monolith into microservices should start with the Strangler methodology and you shouldn’t worry too much about the orchestration method when getting started. As things start to take shape, Kubernetes is definitely an awesome candidate.

Will Kubernetes Allow You to Move Faster?
So many tech-savvy companies out there are using Kubernetes. And they are definitely moving fast. Won’t we be moving faster as well by adopting Kubernetes?

Unfortunately, the answer to that question is almost certainly “no.” The most common reasons I have encountered that prevent teams from moving fast are:

Slow or inadequate tests.
Lack of automated build and deployment capabilities.
Poor understandability of the application.
Each of those problems is separate, and none of them are directly related to Kubernetes. Go ahead and invest in CI, CD and understandability. Containerization may definitely help. Kubernetes might come later, or it might not. But there are almost certainly higher-priority concerns to address if increasing velocity is your goal.

Is Kubernetes Better Than What You Currently Have?
If you have read this far, you are probably not satisfied with whatever orchestration solution you already have (or you just might be reading through before you roast me in the comments). And while Kubernetes is definitely awesome, it’s a complex system with many shortcomings. To be honest, it’s quite likely to cause as many problems as it’s going to solve for you.

If you are using a remote configuration tool such as Chef, Puppet or Ansible, that just might be what’s right for you. I would definitely recommend considering containers for most of those workloads, but that can still be carried out with those simple orchestration techniques and without a dedicated container orchestration platform.

If you are using virtual machines, or even physical machines, you might not understand some of the performance benefits you are getting out of those environments (which is why many tech-savvy companies still use them for high-performance workloads). If you move to more containerized, higher-abstraction workloads, you just might encounter performance degradations you are not expecting.

Summary
Whatever your complaints may be about your current architecture, Kubernetes is certainly not magic that will fix all or even most of your problems. My advice is to keep track of what you are happy about with your existing infrastructure and test to make sure what Kubernetes will not fail you in those areas or even make existing problems worse.

The truth is that most of us aren’t Google. We don’t always need the latest trend in software engineering, whether it’s distributed tracing or serverless or, yes, even Kubernetes. To be clear, we use all of these things to some extent at Rookout, so don’t misinterpret this article as a case against Kubernetes. Kubernetes is amazing. It just may not be for you, despite the hype.