Virtualization vs. Containers – a fight you should never have

I have some time to while away before I get on to a plane to head back home to my amazing wife and often-amazing zoo of animals. Am I at the Tokyo Zoo, or in some ancient temple looking for a speed date with spiritual enlightenment? Of course not. I came to the airport early to find good wifi and work on an OpenStack deployment lab I’m running in a few weeks with some co-workers. Good grief, I’m a geek. But anyway.

Auburn the beagle in her natural habitat
Auburn the beagle in her natural habitat

But before I get into my lab install I wanted to talk a little bit about something I saw way too much at OpenStack Summit. For some reason, people have decided that they are going to try to make money by making Linux Containers ‘the next Virtualization’. Canonical/Ubuntu is certainly the worst example of this, but they are certainly not the only one. To repeat a line I often use when I’m talking about the nuts and bolts of how containers work:

If you are trying to replace you virtualization solution with a container solution, you are almost certainly doing both of them wrong.

First off, at the end of the day it’s about money. And the biggest sinkhole inside a datacenter is not fully utilizing your hardware.

Think about how datacenter density has evolved:

  1. The good ole days – a new project meant we racked a new server so we could segregate it from other resources (read: use port 80 again). If the new project only needed 20% of the box we racked for it, we just warmed the datacenter with the other 80%.
  2. The Virtualization Wars – Instead of a new pizza box or blade, we spun up a new VM. This gives us finer grain control of our resources. We are filling in those resource utilization gaps with smaller units. So that same 20% could be set up multiple times on the same pizza box, giving up closer to 100% resource consumption. But even then, admins tended to err on the side of wasted heat, and we were only using a fraction of the VM’s allocated resources.
  3. The Golden Age of Containers – Now we can confidently take a VM and run multiple apps on it (zomg! multiple port 80s!) So we can take that VM and utilize much more of it much more of the time without the fear that we’ll topple something over and crash a server or a service.

This is where someone always shoves their hand in the air and says

<stinkeye>But I need better performance than a VM can give me so I’m running MY CONTAINERS on BAREMETAL.</stink_eye>

My response is always the same. “Awesome. Those use cases DO exist. But what performance do you need?”.

Here’s the short version.

A properly tuned KVM virtual machine can get you withing 3-4% of bare-metal speed.

Leaving out the VM layer of your datacenter means that once you consume that extra 3-4% of your baremetal system that KVM was consuming, you have to go rack another system to get past it. You lose a lot of the elastic scalability that virtualization gives you. You also lose a common interface for your systems that allow you to have relatively homogeneous solutions across multiple providers like your own datacenter and AWS.

Containers bring some of that flexibility back. but they only account for the Dev side of the DevOps paradigm. What happens when you need to harden an AWS system and all you care about are the containers?

Secondly, hypervisors and Linux containers are FUNDAMENTALLY DIFFERENT TECHNOLOGIES.

A hypervisor virtualizes hardware (with QEMU in the case of KVM), and runs a completely independent kernel on that virtual hardware.

A container isolates a process with SELinux, kernel namespaces, and kernel control groups. There are still portions of the kernel that are shared among all the containers. And there is ONLY ONE KERNEL.

All of that to say they are not interchangeable parts. They may feel that way to the end user. But they don’t feel that way to the end user’s application.

So take the time to look at what your application needs to do. But also take some time to figure out how it needs to do it. All of the use cases are valid under the right circumstances.

  • Straight virtualization
  • Straight baremetal
  • containers on VMs
  • containers on baremetal

A well thought out It infrastructure is likely to have a combination of all of these things. Tools like OpenStack, Project Atomic, and CloudForms make that all much much easier to do these days.

I <3 OpenStack! Now What do I do?

OpenStack (http://www.openstack.org/) truly has the imagination of a lot of the IT world right now. It has the power to be an incredible tool that changes how modern IT business is performed. It is actually a collection of tools that can run on a single or multiple systems and often have at least some overlapping functionality.

  • OpenStack Compute (code-name Nova) – core project since Austin release
  • OpenStack Networking – core project since Folsom release
  • OpenStack Object Storage (code-name Swift) – core project since Austin release
  • OpenStack Block Storage (code-name Cinder) – core project since Folsom release
  • OpenStack Identity (code-name Keystone) – core project since Essex release
  • OpenStack Image Service (code-name Glance) – core project since Bexar release
  • OpenStack Dashboard (code-name Horizon) – core project since Essex release

Projects Incubated in the Grizzly release:

These tools allow you to see multiple types of hypervisors and storage systems through a single pane of glass. It is already a very powerful tool. The inclusion of the concept of metering and Orchestration in the latest release point in the direction of a solution, but they are (at least today) intended to be gateways into OpenStack more than complete solutions for those problems.

And that’s the problem that Enterprises will soon be facing. Even with Red Hat working on their supported version of OpenStack whose community is called RDO (http://openstack.redhat.com/Main_Page), OpenStack doesn’t provide all of the abilities that are needed to truly manage an enterprise installation and achieve a true ROI. So how do you do that?

A company has to be truly aware of what’s going on in their datacenters to really make money using a hybrid cloud approach at the level OpenStack can do it. It’s a matter of looking at a price sheet to see how much a given system would cost on Amazon for a length of time. But how much does it cost to add that same machine to one of your internal hypervisors? A company would have to be truly aware of heating and colling costs, and the changes made by increased load on a given hypervisor system to be able to accurately charge back cost to its various clients.

Once a company is aware at that level, there are a few ways to go. The one I’m currently very impressed with is from Red Hat. It’s the 2.0 version of their CloudForms product (http://www.redhat.com/solutions/cloud-computing/red-hat-cloud/private-clouds-cloudforms.html). When Cloudforms 1.0 came out I didn’t really see the goal or the point. However, Red Hat purchased a company called ManageIQ last year, and set their team on integrating their product in and working on the now-released 2.0 product.

It’s pretty nice for several reasons:

  • It’s delivered easily as a virtual appliance (a first for Red Hat)
  • It gives you the single pane of glass to automate and meter all of your virtualization environments
  • It uses no hacky access methods. No database hacks. It goes through the front door and manages everything properly.
  • It’s extremely easy to build out complex logic-driven events within your infrastructure

Laying CloudForms on top of OpenStack and your virtualization solutions gives enterprise users an incredibly powerful management platform for managing a truly hybrid cloud through a very few “panes of glass”.

1 – from http://www.openstack.org/software/roadmap/