Why should you use Kubernetes in 2022? Or why not? Kubernetes

It seems like a great time to deal with the question that everyone seems to be asking: “To K8s, or not to K8s?” (K8s is short for Kubernetes). I bet you faced it already. It is hard nowadays to get near the “cloud” and not hit the “K8s” sign if you are not careful.

For those who are new to it, Kubernetes is a container orchestration platform – you can read more about it here: Kubernetes.io. What I observe is an uptick in interest when it comes to using the Kubernetes platform in applications.

Another thing I noticed is that not many people ask: “Why should we use it?” and “What should it solve for us?” Here is my personal, and biased of course, attempt to give you a guide – when to do K8s and when is it not a good idea?

Ready? Let’s dive in.

Is Kubernetes a buzzword?

Buzzwords are all around us. In IT we are especially prone to using them. We fall in love with new technology, frameworks, architecture, tools… you name it. Deep inside, we are geeks (and it is not a bad thing).

And so every new idea at some point becomes a buzzword. It is how the world fueled by marketing (among other things) works. Every technology is a buzzword at some point. It gains traction and people talk about it.

The question is – does it stay a buzzword, or does it become “a thing”?  Here’s my take – technology is a buzzword in your context if you can’t answer these questions:

• Why are you using it? (and “Because everybody else is”, is not a good answer!)
• How does it help you to deliver on your user needs?
• Is it a good tool, practice or method to deliver on this particular user need in this solution? (There’s no “one size fits it all!”)

And by the way: First, you need to answer the question of “Who is your user and what need are you solving?”.

Even if it is on everyone’s lips but it does the job for you and builds your advantage, it might be a solution for you. The key point is that you know why you are using it and what it gives you.

There is no better way to illustrate this point but this ironic, yet very true thread by Simon Wardley. Just substitute “data lake” with “Kubernetes”:

Source: @swardley on Twitter

My point: Even if it is a buzzword, it might be a good solution for you if you use it for the right task and in the right context. “Let’s do it on Kubernetes because everyone is doing it” is neither the right task nor the right context. Do your due diligence here.

Let’s separate containers from Kubernetes

It is hard to do, but I think it is good to spend a few lines on it. Containers != Kubernetes. Yes, Kubernetes is by far the most popular platform to manage and orchestrate solutions based on containers. They won the war on it (sorry if you bet on something else).

Want to know more about containers? Check out this introductory video

Containers are a way to package and deliver the application code. They simplify the developers’ workflow and the process of solution delivery to the environment (dear god, all the dependencies in the local OS to manage…).

They are here to stay. At least there is no real contender right now, other than the serverless approach to running code. You can use containers in many places without Kubernetes. Build a web application based on it, deliver code for Azure Functions packaged as a container image.

Kubernetes steps in if you build a solution based on containers at scale. You need to deploy and scale multiple instances of containers, operate multiple services, and scale them up and down. Here’s where the orchestration platform steps in, and now K8s is the tool of choice if you need it.

The questions are:

• Do you need it?
• What else do you need besides it?
• Do you have to do it on your own?

My point: Containers are here to stay as a form of packaging and delivering the software. Kubernetes is an orchestration platform, you need it if you want to run containers at scale.

The greatest mistake you might do now – build your own Kubernetes in your own data center. Unless…

Really. It is all in this headline. Building your own Kubernetes infrastructure, in your own data center, might be one of the worst decisions you can make right now.

“Might” because there are some niche needs where you will have to do it, or it is your core business.

What are the have-tos:

• Local market regulation, which does not allow you to go for public cloud (those will change, architect for a quick change!)
• You are in the business of providing the infrastructure, e.g. you are a data center provider on a specific market (risky business, but there is a niche in it), or it is really crucial for your business.
• You are in real need of avoiding dependency on specific providers (geopolitical reasons, market competition – those will be niche cases).

There is one interesting case from online services, where a company chose to run it on their own to support smaller providers. It is Basecamp and their new e-mail service, hey.com. It is their decision, however, it also falls into the second point above – it is crucial for them as a service.

That’s it. I can’t think of anything more. If you have another example, happy to hear it from you – just leave a comment. For all the rest, getting someone to run your Kubernetes infrastructure for you is the right thing to do.

Why?

One of my greatest surprises recently in the social media sphere was the result of this poll done by one of my friends:

LinkedIn poll screenshot

OpenShift is an alternative to Kubernetes with a focus on on-premises or hybrid deployment, run and operated by your team.

Really! We are past this already. Don’t do it unless you really have to. Why? Because it is complicated and hard to do! And it really doesn’t matter for your product whether you run it on your own or not.

My point: In the majority of cases, you are better off running Kubernetes as a service on one of the platforms. Our pick is Azure Kubernetes Service (AKS) from Microsoft but pick your own. AWS and GCP offer them as well.

See how Grundfos speed up app development with Kubernetes

Why Kubernetes? Or why not?

Let’s get to the point. Running containerized applications is a thing right now. I will always encourage a company to do an analysis of the target architecture before deciding to go with Kubernetes and containers:

• What are the alternatives? Can it be PaaS-based? Can we do it serverless?
• What will be the cost of operations vs other alternatives?
• What will be the speed of development in different architecture models?

And here are what might be good reasons to go with a containerized application and K8s as a platform:

1. You need to scale and quick scaling up/down depends on the workloads

If you architect a solution that targets infrastructure and VMs, doing it on K8s might be a better choice. This is especially true if it consists of multiple services, and requires scaling up and down depending on different factors. In such scenarios, containers provide an easy way to scale your application, compared to VMs.

If you are going to use K8s based on this requirement, it might be useful to get to know KEDA – https://keda.sh/ – the Kubernetes-based Event-Driven Autoscaler. Check it out.

2. Your application consists of multiple services and you need to be able to scale them

Your application consists of multiple, independent services and you need to host them at scale. Managing those with a solution like Kubernetes is easier than with a traditional infrastructure. Why? Besides the container management layer, there is also the Kubernetes API which lets you automate a lot of tasks related to resource provisioning and management.

Interesting point here: it is a visible trend to use the K8s API to manage other types of workloads. One day we might wake up with K8s API being used in the cloud without container orchestration, just as a management API.

3. Resilience for container-based workloads

Kubernetes is good at doing what it is made for – keeping container workloads up-and-running. If you have code that you will want to run in containers eventually, it will do a great job of keeping it operational and managing the container instances and pods for you.

4. Prepare your workloads to move to the cloud

If you can’t build for the cloud at the moment and you are working on-premises, building on top of containers and Kubernetes might be a good way to prepare for the future move to the cloud.

Be aware that it won’t be like “flip of the switch” and seamless migration. However, it will be much better than building on VMs or direct infrastructure, and then moving to a cloud IaaS.

5. Consistent deployment management

A Kubernetes deployment has one advantage – it is based on a declarative state of the environment delivered through APIs. It is how the entire cloud should be. But in this case, with proper DevOps practices and CI/CD pipelines, we can focus on the description of the desired state of the application and quick deployments or roll-backs if needed, based on the declarative state.

Be prepared that things might go south! And one day they will.

Remember: there are other choices. Kubernetes is not a default option (although I know it is for some of you).

For example – you can go serverless and you don’t have to scale the infrastructure at all. You do not pay when it is not working, as it is handled by the platform, however, those are different architectures.

Here are some examples of architectures where Kubernetes services were part of the solution, and for good reasons – click the links to read the articles:

• Building a banking app in the cloud made simple with Azure
• How to build a powerful IoT solution in Azure?

What do others think about Kubernetes?

That’s me. But to make this update less biased, I asked a friend of the house, Lukasz Kaluzny, Microsoft MVP and cloud expert at Protopia, about his three points on when to do K8s and when not to do it. Here are Lukasz’s points (not synchronized with mine beforehand).

As you can see, we have a similar point of view, and we have not discussed it upfront.

Things to remember before going with Kubernetes

If you decide to go with Kubernetes for your solutions, there are the things you need to remember:

• Your team needs skills, and it is a complex technology with a lot of moving parts. There is an entry barrier to cross. Give your team the time and resources for it.
• Security is hard and it is not a given. Kubernetes is not solving it as a magic wand, it actually adds to the complexity of things. Make sure to address it from the beginning.
• You will need some additional tools and make decisions to select tooling for deployments, observability, management, security. Do your due diligence here!
• Cloud Native Computing Foundation provides a lot of great tools. They come with a price of you building a solution out of them. If you go for a managed cloud, look for these tools integrated and provided by your cloud vendor.
• To build, run and operate Kubernetes on your own, you really need a good reason. Make sure you have one.

I hope you enjoyed this one and it gave you a point of view on this matter. Remember – the final choice is yours.