Kubernetes is not the new virtualization layer

Why I Cringe When People Say Kubernetes Is the New Virtualization Layer

Feature image via Pixabay.

How many times have you seen a diagram like this one? Maybe some cloud vendor showed it to you, or you saw it in an analyst presentation.

See how infrastructure went from bare metal to virtualization to cloud and now containers and Kubernetes? Virtualization is an infrastructure concept that sliced up bare-metal machines into smaller units that workloads could live in. Containers can be an even smaller unit of compute to manage that you shove bits of applications into. So containerization is the new virtualization. This idea is so tidy to express. So simple. So misleading.

Let’s back up. Ultimately when somebody is using any of the technologies in the diagram it is to run something, whether it is simple or not. Somewhere in there is infrastructure that an application runs on plus maybe some platform services and the application itself. This is where I think the misleading comes into play in the diagram. The diagram implies that containers and management of them through Kubernetes is infrastructure. Infrastructure evolution tends to confer density and cost “hard” benefits, but most importantly has historically been something practically invisible to the application.

This was certainly the case for the first couple of steps in the diagram. Take virtual machines (VMs) — not much changed in the application layer from bare metal to VMs because VMs just provided a new means by which to deploy the same old applications; the primary difference was that applications now shared space with neighbors on their hosts. Cloud 1.0 was also an infrastructure play — you ran the same old, now virtualized, applications, just somewhere else. As a popular sticker said, “The cloud is just someone else’s computer.” So far, so good with the diagram.

But… Cloud 2.0 is something different. Sure, there are the containers and orchestrators. But there is more. Your app looks different. It is architected and built differently. It behaves differently. You don’t generally just take your old workloads and lift and shift them into this world; these applications didn’t exist before. Now we’ve hit the snag with the diagram. Cloud 2.0 is not just a way to pack more of the same old apps onto machines here or there. Cloud 2.0 requires something different of IT but also of the application and the developer. Cloud 2.0 is not just another step on a seemingly inevitable “up and to the right” infrastructure journey. Containerization is not the new virtualization layer.

You might think this is a silly semantic argument or ask “why does this matter?” Worldview matters. Biases introduced or magnified through language matter. They change the lens through which we interpret and reason about what we see around us. Imagine how different things would be for Kodak if they had thought of themselves as an imaging and picture capture company, rather than a film company (in the event this example doesn’t ring a bell for you, Kodak invented the digital camera but then abandoned it as they were a “film” company; Kodak went bankrupt in 2012 because of… other companies’ digital cameras).

We have plenty of examples of where an infrastructure-centric point of view can lead IT endeavors astray. Remember how OpenStack was going to be deployed everywhere? IT vendors and managers thought that if only they offered the holy infrastructure trio — compute, storage, and network — on-prem more cheaply than in the public cloud then people would stay on owned infrastructure. By thinking about the problem from an IT infrastructure lens they missed a lot of the real action that turned public cloud into the behemoth it is today — in platform services and elastic resource consumption. They built expensive products and solutions (think Cisco Intercloud, HP Cloud, my own Nebula and a whole graveyard of other startup corpses) that never went anywhere because they were designed from a point of view that not only forgot the developer but didn’t really understand them to begin with. As a result, they definitely missed what developers were doing with microservices and deep platform services. Thinking of cloud as just infrastructure prevented them from even seeing that there was more to do than offer the holy trinity.

What technology such as Kubernetes and containers offers is something that sits right between infrastructure and what some people had to turn to PaaS for, namely distributed computing tools. Kubernetes, in particular, offers a lot of power in the form of a declarative model for developers to really describe their container layer, coupled with desired state maintenance that makes sure that model is satisfied. Reasonable people can disagree on whether an infrastructure team should manage that layer, and the answer on the ground can definitely differ from company to company. But let’s all be clear that there is something deeper and more complex than what that arrow in the diagram is lazily implying and leading you to believe, namely that we’ve found a way to magically just pack an application into a different box.

Containers and orchestration are a big step in a less black and white world, where the line between infrastructure and services and applications is a lot more blurred, and developers and IT both need to understand it and change to accommodate it and each other.