Over the course of a few years, cloud native applications and infrastructure have been growing far more than originally anticipated. Although there are still many organizations that aren't moving their workloads to a public or private cloud, it's very much becoming the norm. In fact, it's difficult to find a startup today that isn't starting its business in the cloud.

The cloud simply makes things easier to get started.

With increasing popularity in the cloud comes misconceptions about certain services and APIs. Marketing and/or not understanding exactly what a technology is can, and does, cause confusion.

In this blog post, you'll learn about debunking the idea that Kubernetes == cloud native.

What Exactly Is Cloud Native?

If you take a look at the definition of cloud native, it'll read something like this:

"Cloud native computing is an approach in software development that utilizes cloud computing to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds".

Take a look at this bit in the definition:

"utilizes cloud computing to build and run scalable applications".

Any application can be run in the cloud. You can have a legacy app that you have from 10 years ago run in the cloud as long as the cloud supports it. This doesn't mean the application is cloud native, however.

The big differentiator between an application running in the cloud vs an application being cloud native is scalability.

Is an app you're running compatible with scalability features in the cloud? How can you scale a stateful app in the cloud and is it supported? What are the dependencies of the app?

What Exactly Is Kubernetes?

When a lot of people think about Kubernetes, they truly believe it's a big scary piece of technology that's ridiculously hard to learn.

It's not.

It's actually far more simple than the cloud.

Kubernetes is made up of two parts - servers and an API. The servers are what run the Kubernetes service (the API) and the applications (deployments, pods, services, etc.).

The Kubernetes API is what handles all of the "thinking" when it comes to Kubernetes. Where deployments are going to run. How pods are created. What pods are running where. What applications and dependencies are running. The Kubernetes API is like the brain.

The servers running Kubernetes hosts the API and the deployments, services, pods, etc.. The servers are where everything lives. Think of the servers like the body that the brain lives in.

Another misconception about Kubernetes is that it means containers - it doesn't. Kubernetes is the orchestration platform, which means its one and only job is to scale and manage containers. Containers themselves come from a container engine (runtime), like Containerd, CRI-O, and Docker.

Think of the container engine (runtime) like a car engine and the orchestration system (Kubernetes) like the body of a car. The body of the car gets the engine moving, but the car can't move without the engine.

Why Kubernetes ! = Cloud Native

If you remember from the section What Exactly Is Cloud Native, you saw the definition of cloud native, but more importantly, the utilizes cloud computing to build and run scalable applications section.

By definition, this means that Kubernetes is not cloud native.

Why?

If you look at a Kubernetes manifest with a deployment Kind or Type, you'll see a section for replicas. Replicas are the way to tell the Kubernetes API how many Deployments of an application you want. The Deployments contain Pods, which are running the app(s). By default, Kubernetes has self-healing for any Deployments that may exit that aren't supposed to, ensuring that the replica count is always consistent. There are a few other ways to scale too. For example, you can use the kubectl scale command to auto-scale replicas.

With the above explanations of scaling in Kubernetes and what cloud native truly is, you can see the differentiator:

Cloud native is about scaling applications. Kubernetes doesn't use the cloud native approach to scale applications because it doesn't need to due to having its own scaling functionality.

If you were to create a raw Kubernetes cluster on-prem, the scaling capabilities in Kubernetes would be the same as in the cloud. Why? Because it's all about the Kubernetes API and its capabilities, proving that applications running in the cloud aren't cloud native.