Kubernetes is seen as hard in part because it can handle almost any kind of workload. Because of this, the resources must be able to be mixed and matched. In other words, they must be like Legos, where a bunch of separate pieces can be put together to make a bigger whole. Take containers as an example: in Kubernetes, you can’t run containers separately. Kubernetes has the idea of “pods,” which are groups of containers. A pod is a group of containers that are tightly connected to each other. But even if you use Pods, it’s unlikely that you’ll be able to run them on their own. Most of the time, you will use a Deployment, a DaemonSet, or a StatefulSet to run them. This is before you’ve shown anyone outside of your organization the service.
You could build a very small Kubernetes cluster and it would work fine, but you really, really don’t want to do that. There are a lot of things running in any cluster that is ready for production that Kubernetes does not need at all. But that isn’t the whole story.
You see, when you’re making a service, one of the things you want to avoid is making your users unhappy. This is just one reason among many. This disappointment can come out in many ways, but one of the easiest ways is to provide a service that can’t be counted on. There’s probably no rule that says your service has to be available all the time. You don’t even have to aim for 99.999% uptime. However, if the service goes down too often, people can’t trust it. A user uploads a picture to a service, only to find the next day that the picture is no longer there. That won’t be something anyone will remember with a smile.
A bad customer experience with a product or service can be caused by a number of different things. Maybe you just put out a new product, and there has been a huge amount of interest in it. It’s a very good problem to have. It’s more likely that a bug is causing the app to crash and making people panic. It could be a problem with the way it is set up, or the certificate could have expired.
This leads me to my main point, which is that making something is hard. You are in charge of a lot of different parts, such as apps, logs, metrics, storage, databases, backups, load balancing, deployments, secrets, and more. Even more so if you are working on making microservices.
You have to do each of these tasks whether or not you use Kubernetes. With cloud computing, you get a lot of that for a price, and if you’re willing to pay that price and accept that some of it comes with a vendor lock-in, you can significantly simplify your stack. But you can’t if you don’t want to pay that price and aren’t willing to accept that part of it comes with a vendor lock-in. Before Kubernetes became so popular, that’s how we did things, and it worked out well.
Forget everything you’ve heard about Kubernetes. There’s a good reason why so many businesses are using it. It makes it so that development teams don’t have to worry about all of these things. Instead, they just have to write a simple YAML file. Most importantly, teams no longer have to ask DevOps or infrastructure staff to add a DNS entry and create a load balancer in order to expose a service. These jobs can now be done on their own. If you tell an operator to do something, they can do it on their own, without being told what to do.
Is Kubernetes something that you should use?
When Kubernetes is used, the “burden” of maintaining clusters falls on the DevOps and infrastructure teams. Is it going to work for all of the businesses? No. Is it a good idea to have three different microservices? Maybe. Maybe not. You should go for it if you’ve reached a certain level of success. It’s possible that your use case is so simple that it would be too expensive to switch to Kubernetes.
When you use Kubernetes, you get a unified way to build things that can be changed as your company grows. By putting together and recombining different operators, you can make powerful automations whenever you need them. Think about using autoscaling. What’s the best way to automatically grow your services? Which way should you scale it, left to right or right to left? Could open connections be used instead to make the service bigger? It’s possible that you don’t need autoscaling at all.
I like Kubernetes. I like it a lot. Would I use it in every possible situation? No. Would I think about it for every business I ran? Probably. It gives you a lot of great ideas that are out of the ordinary, and you can take it to a very high level. Does this mean that you have to use Kubernetes for everything? Definitely not.