Dear (Hack) Tech Pundits: Please Stop Saying “Containerizing Workloads is a VMware Replacement”

Miss me?

I’m mainlining bourbon for this one, which means that by the time I proofread this sober I will have had to back off like 9 swear words, easy.

Thinkingoutcloud update: I may or may not have some posts coming out about the whole VMware/Broadcom goings-on. I haven’t decided yet. They are mostly posts about cloud economics.

Best I can say for now is that VMware is no longer a Hypervisor company, VMware is a Cloud Platform company. They have been a cloud platform company for the better part of a decade. You just refused to pay attention.

Change is disruptive.

I was done debating all that as far back as early February. I’m over it. Instead, here’s a tract I was compelled to release into the ethers:

The Crux of the Problem

So what has angered me so much and shaken me so violently from my self-imposed blog-hiatus . . . my blog-hibernation . . . my blog-slumber?

People saying stupid crap like this (focus on the italics):

“Your options for switching from VMware are Vendor X or FOSS Y (I’m not naming names) . . . or you can containerize your workloads so you won’t need to virtualize an OS at all.”

That last italicized part makes me want to punch kittens, and everyone knows I love kittens:

Containerizing workloads does not eliminate the need for an operating system. Full stop.

That’s not a thing.

Containers are not independently-functioning entities that bypass the need for an OS. Did you learn anything from my Containers 101 post? I’ll give you a hint . . . google cgroups.

A diagram of cgroups. Source: https://en.wikipedia.org/wiki/Cgroups

I am especially angry because I have heard this absolute humdinger of a misconception from at least one misguided CIO and from two people with “Architect” in their titles. These are people who should know better.

Although to be fair, that last part about the “Architect” in their titles doesn’t mean much because people like me are given titles like “Architect”.

So, there’s that.

Anyway . . .

I Will Explain It To You Like You Are 5

I am removing Windows Containers from the equation, since that’s not my area of expertise:

  1. Containers run on cgroups, whether you are using EHRMERGERDKUBERNERTERS! or not.
  2. cgroups is a feature of the Linux Kernel.
  3. The Linux Kernel needs some kind of OS no matter how lightweight: you know, the thing that makes it boot up, take input, and talk to stuff? Yeah. That.
  4. Therefore, containers must run on an OS.

YEA!

Can’t I Run Containers on an OS Running on Bare Metal?

Sure. Pros and cons. Assuming you still have a fair amount of workloads that can’t be containerized (which is usually a safe assumption, and good luck containerizing those 35TB database servers), I am not sure I would consider that approach “replacing VMware” at that point. You’re in a whole new realm of . . . well, whatever that is.

Also, containers (or Kubernetes, really) on bare metal versus containers on VMs is hotly debated . . . if the year was 2017.

Where were you?

Containers on VMs (mostly) won from a management overhead and scalability standpoint. Bare metal is for super low-latency/high-performance requirements. I am not saying people don’t run containers on bare metal, and I am not saying it’s without its use cases.

But for most shops it’s way easier and more cost-effective to use Virtualized OSes to host containers, wherever they run.

What About Containers in Public Clouds, Surely Those Aren’t Running on an OS?

All implementations of containers in public clouds run on virtualized OSes, or whatever it is each public cloud calls a “virtual machine”. That includes your EKS’s, your AKS’s, your GKE’s, and your ECS’s. Look them up.

Can you run “cloud native” on VMware?

Let me answer that question with another question: Did you know that Spring and Azure Spring Apps are VMware products?

And while I’m at it, since “cloud native” is an approach (private or public), you can run cloud native apps on VCF, VMC on AWS, or Azure VMware Solution.

Well, I’ll be a tech pundit’s uncle.

Oh Yeah? What About Serverless?

Serverless does not mean things don’t run on a server, it just means that you don’t care which server and you don’t want to manage said servers. The OS part has been obfuscated away.

But it all still runs on a VM, or a set of VMs, no matter where it runs.

Can you run Serverless on VMware?

Yes. Ever heard of Knative?

What Else Is Problematic About Containerizing Workloads as a VMware “Alternative”?

Have you ever converted a traditional virtualized application into a container? I have. There’s no easy push-button V2C converter tool. There are dev tools out there that do it, but you still have to know how to code it and architect it. It takes talent, because to do it at scale means using a container orchestrator (like Kubernetes), and then you’re in a whole different realm called (buzzword alert) App Modernization. Engineers will have to get those bash/git/yaml/IaC/CI/CD/Kubernetes skills out. They’re going to need them.

And fun fact, your run-of-the-mill VMware Engineer doesn’t usually have those skills. I should know. I talk to them almost daily, but I can’t help but mention here that I have advocated repeatedly and at full volume that they should.

And you know what else is expensive? Paying highly talented people to re-architect and/or refactor your applications when you otherwise wouldn’t.

Furthermore, if you are a Windows-heavy shop, I am not sure how widespread mainstream support would be for taking on converting your Windows apps into Windows containers, but comments are open for you Windows-container specialists out there to correct me.

Additionally, if we’re talking about COTS applications, even if you could containerize them, your vendor will need to support them.

What Does This Mean If You Are Running VMware and You’re Shopping Around?

First, you should understand that if your plan is to reach 100% containerization to engineer your way around the costs of VMware, that is unrealistic. A fool’s errand. I hope you haven’t told your bosses that.

In the meantime, I can fix the statement for those hack pundits you’ve been reading:

“One option might be to look for candidate workloads that can be consolidated into containers to decrease your resource consumption, allowing you to run on fewer cpu cores and have more portable workloads.”

That might save you some money, and/or allow you to migrate workloads elsewhere. But the labor and resources involved with evaluating that in the first place, as I mentioned earlier, will also cost you money. You should put a pencil to that.

But you still have to run containers on an OS, and if bare metal isn’t for you (and this is my point from the jump):

YOU. STILL. NEED. A. HYPERVISOR.

Take that hack pundits. You should get a new job. Nobody likes you.

One thought

Leave a reply to Al Rojas Cancel reply