Benefits Of Using Kubernetes For An Organization

If you’re implementing a specific technology for an organization, the overarching question that you must constantly ask yourself is “why use X technology”. Business leaders and engineers must understand why and how a platform will help fill their needs. There are an incredible amount of platforms and orchestration tools in the wild today, along with some from the past, but the burning desire for Kubernetes is running red hot. Why?

In this blog post, you’re going to learn about the five key benefits for organizations when implementing Kubernetes.

Containers Are A Thing

At the start of it all, there were mainframes. Huge boxes that ran hardware for computing workloads. Next, we had servers. The distributed computing era, of which we’re still in. Servers were smaller, a bit faster, and had the ability to be optimized. After that came virtualization as running one application on an entire server didn’t make much sense from a resource perspective. Instead, it made far more sense to take multiple apps, virtualize the hardware, and run several on the same server.

The next evolution after that was containers, which are a way to virtualize an operating system instead of the underlying hardware.
Containers are becoming increasingly popular not just for production workloads, but for engineers testing features and pieces of an application. It’s much easier for a developer to create a container vs a server to test an app. Because of that, organizations are starting to adopt containers, but containers by themselves are ephemeral. They need a way to be orchestrated and managed, which is where Kubernetes comes into play.

Same Game, Next API

There’s always a lot of talk about automation, but really what’s meant by automation is to create a repeatable process. Doing things like:

• Logging into a UI
• Changing server configs on the fly
• Putting out fires constantly

aren’t repeatable processes. You can’t automate how your workloads are deployed or managed. However, with Kubernetes, it all comes down to an API.

Every piece of work that you conduct on a Kubernetes cluster is through an API. Whether you’re creating a Kubernetes resource with kubectl apply -f or retrieving a resource with kubectl get , you’re interacting with an API.

There’s no specific UI out of the box (other than the Kubernetes Dashboard, which isn’t out of the box) or GUI tool. Instead, everything that you typically do when interacting with Kubernetes is with the command-line tool kubectl or with YAML/Kubernetes Manifests. Because of that, it’s far easier to create repeatable processes.

When you want to do something from a repeatable perspective, if you have an API to reach out to directly, it makes everything an engineer does easier. Not to mention, an open API gives you the ability to use any programming language to interact with it. For example, the common way to create a Kubernetes resource is with a Kubernetes Manifest, but there’s nothing stopping you from writing some Go code to interact with the Kubernetes API and perform the same action that the Kubernetes Manifest is doing.

Firefighting Is Minimized

Per the Google SRE Handbook, engineers should not spend more than 50% of their day putting out fires. Fires typically consist of:

• Fixing an alert manually
• Fixing a deployment manually
• Fixing a configuration manually

and pretty much everything else that doesn’t have a repeatable processes associated with it.

The idea is that for anything that isn’t repeatable, engineers spend the other 50% of their time coming up with automated solutions. That way, the 50% of time they’re spending putting out fires can be narrowed down as long as possible.

With Kubernetes, although it’s not the easiest platform to get up and running, once it is up, all of your workloads are running on one platform. Because of that, it’s far easier and straightforward to create repeatable processes with one platform than it is with two or ten. Engineers have the ability to seriously minimize firefighting if they implement an orchestration layer like Kubernetes.

The great thing is that there are so many other products that work with Kubernetes to make things easier that you don’t have to do a lot of the heavy lifting.

For example, Kubernetes exposes a /metrics API. You can use an observability tool like Prometheus to ingest those metrics and then create repeatable processes around fixing problems that occur in logs and/or traces, all under one platform.

It’s A Datacenter In One Cluster

Let’s think about what makes up a Kubernetes cluster at a high level:

• Servers
• Operating systems
• Storage
• Networking
• Applications

Of course, there’s way more that goes into it, but when you look at that list, it kind of feels like you’re looking at what makes up a data center.

That’s because you are.

Underneath the hood, a Kubernetes cluster is like a data center running in one place. There are several networking components, storage pieces, operating systems that can be run to create the cluster, all different types of servers, and any containerized application you’d like.

It essentially means that engineers don’t have to leave that cluster for their workloads. Everything can be managed in one place, programmatically, and automated in a repeatable fashion. Of course, there are the underlying servers and operating systems to manage, but from a day-to-day perspective, engineers can focus on way more value-driven work.

Scalability Is Easier Than Ever

To wrap up, and certainly last but not least, is scalability. Let’s think about a common scaling concern.

It’s a busy week for your organization’s product. Potential customers are reaching out to the website, putting in orders, there’s a ton of network traffic, and your application that’s running on a server starts to get bogged down. Because of that, you have to scale it out to other virtual servers or even potentially bare-metal servers.

Because of this one click of high volume, there’s a ton of work that has to go into creating the automated process to get the application scaled out successfully.

With Kubernetes, it’s handled automatically for you with Replica Sets. With a Replica Set, you can specify whether you want one or two or twenty Pods running of your application. If you’re, for example, running three replicas and the app is starting to get overloaded, you can configure your Kubernetes Manifest to allow horizontally scaling your workloads/replicas. You don’t have to create new automation or new processes. It’s all managed for you by Kubernetes. The only thing you need to do is ensure that there are enough worker nodes running to handle the load, which is far easier than creating an entire system/process to scale out binaries on virtual machines.

Wrapping Up

There are several reasons for organizations to consider the benefits of using Kubernetes. The goal is to make engineer’s lives easier by easily scaling, creating repeatable processes, and giving engineers a better management system for their workloads. Although it’s not the easiest platform to get up and running in the beginning, the benefits later on far outweigh the time it takes to get Kubernetes properly configured.