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). You've probably 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 we observe is an uptick in interest when it comes to using the Kubernetes platform in applications.Another thing we noticed is that not many people ask: "Why should we use it?" and "What should it solve for us?" Here is our 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 our 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. The 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 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). 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 (oh dear, 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?
The 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 centre 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 email 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. Nothing more. For all else, getting someone to run your Kubernetes infrastructure for you is the right thing to do. Why? One of recent social media sphere surprises was the result of this poll: 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. The 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.
Why Kubernetes? Or why not?
Let's get to the point. Running containerised applications is a thing right now. We 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 containerised 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 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?
To make this update less biased, we 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 synchronised with ours beforehand).
Expert tips
When to do K8s in your project:
- Use it if you know how to deliver an application with a good engineering approach and process. It will speed things up.
- Take it as a part of the whole package with other services from public cloud providers. It pays off then to have it integrated.
- If you look to be at least partially able to move between the providers. It is not that rosy and you will have a problem with moving the data anyway.
When not to do K8s in your project:
- Do not build it on your own as a local solution in your data centre. Go and get it as a service. Building it is hard and you will fail too many times for it to pay off.
- It doesn't make sense if you don't have an application architecture that supports and benefits from it. Not every app will benefit from the microservices approach.
- Do not start large-scale, before your team gets good knowledge and is ready. It is a complex solution and they need to know how to build and operate it.
- Do not go for CNCF solutions expecting that they will work out of the box. You will have to put it to work on your own. Time and skills are required.
 As you can see, the points of view are quite similar.
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.
Author
