What is context switching?
Ever come across context switching? Even if you haven’t heard the term, you have likely experienced it at some point. ...
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.
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:
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”:
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.
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:
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.
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:
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.
One of my greatest surprises recently in the social media sphere was the result of this poll done by one of my friends:
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
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:
And here are what might be good reasons to go with a containerized application and K8s as a platform:
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.
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.
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.
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.
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:
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).
When to do K8s in your project:
When not to do K8s in your project:
As you can see, we have a similar point of view, and we have not discussed it upfront.
If you decide to go with Kubernetes for your solutions, there are the things you need to remember:
I hope you enjoyed this one and it gave you a point of view on this matter. Remember – the final choice is yours.
Read other similar articles