Containers and hypervisors. Why both are important.
So hopefully you’ve heard all about containers, and if you have, you most likely learnt that they are going to take over the world and leave all your virtual machines (VM) for dead.
Unfortunately, as with most things IT, the truth is probably not as simple as VMs are dead, long live containers.
So why containers?
The main shout-out that container pushers seem to be offering is efficiency; that is the number of containers you could run on a given physical host vs. the numbers of VMs.
How many more, 4x, 5x, 6x — it depends on who you believe. The numbers are compelling and if the only thing you care about is how many services you can run on a host, stop reading here and go spend time migrating your environment to a container solution.
What’s wrong with my virtual machine environment?
It’s a fat, hungry, slow to provision bare metal approach, that means we spend more time making sure VM operating system images are working and less time making useful stuff happen.
Now that’s probably a pretty harsh statement, and if you view your VMs vs. how things were done in a purely physical environment, you’d probably call me out as some kind of escaped mental patient; but vs. containers, there is probably a bit of truth in the statement…
Best_friends_forever
Here’s the thing, I don’t think there should be a container vs. hypervisor battle. I think there’s a more peaceful solution that sees them being BFF’s.
Hypervisors have been with us for long enough now that when I challenge customers on “why wouldn’t you virtualise?”, I now get very little resistance.
Within the IT industry, hypervisors are generally considered secure when properly hardened.
Hypervisors have been around long enough that they are even free, and what vendors are selling us now is the management tools to make your environment do what you want - and we’ll park the debate on what’s better.
So I’ve introduced a few other parameters here other than just “how many things can I run”. We also need to consider security, toolsets for managing the environment and what skillsets are available in the marketplace to help (I’m sure you can think of more, I’m just using these to illustrate my point — and it’s my post so I’m allowed to do that).
I really want to touch on security, as I think it’s a major differentiator at a tech level between container vs. VM.
One ring to rule them all
Ha, sorry couldn’t help myself with that heading - I am from middle earth after all.
In this case though I’m talking about ring 0 (zero). Unmodified guest OSs on a hypervisor can still execute operations as if running in ring 0. A nice overview of this is shown here. The basic break down of all of this is that a hypervisor provides a superior security mechanism vs. a container solution. An obvious question is “do I need this level of protection?”.
Plan for the worst, hope for the best
The short answer regarding security is yes. Even if you have the simplest security requirements, you’re still likely to want to separate test/dev vs. production - and yes, there are more likely other reasons to separate these two particular environments other than just security e.g. wanting to be able to run different versions of libraries in test/dev vs. production.
But here’s the thing, this is why I believe it’s not a container vs. VM argument, I think they are both required.
Goto Best_friends_forever
So we’re back at best friends. So when would you use container instead of a VM? This is where most of the stuff I’ve read on containers falls short, it’s basically infrastructure guys lobbing technical grenades at each other on why one is better than the other. The thing is, in most environments today, you’ve probably got very little need for containers simply because a main advantage is “compute more stuff”, and I bet the CPU utilisation isn’t a main bottleneck in your environment. If you could add more CPU, memory or IOPS, which would you choose?
So containers are a waste of time then?
No, but I think we really need to look at how applications are developed to really take advantage of them.
The container world is all about Docker at the moment, and with good reason. Microsoft have announced that Docker for Windows will be on the next version of Windows server and is already supported on Azure Linux.
VMware have also jumped on the container bandwagon and presented their container strategy at VMworld 2014.
All of this stuff is nice, but it all seems to focus on running applications as they are today.
There are even blogs on how to run legacy apps in containers - you know because containers are so much better than VMs #sarcasm
Microservices
What we really need is an application service view to driving real value from containers.
I believe that when applications are developed with a service-based architecture, the usefulness of containers jumps ahead and there becomes a clear delineation on the containers vs. VM question.
In a microservices environment where services are containerised, we all of a sudden start to provide a level of agility and responsiveness that businesses today are demanding of IT.
Containerised services could be moved from an on premises environment to cloud services providers as required/appropriate to provide bust capability (as an example). The self contained nature of Docker containers and the general programmability of containers could allow for additional services (i.e. containers) to be spawned and discarded as demand requires.
Container portability also starts to provide the level of portability that VMs sort of seemed to offer, but never really delivered on; and could mean no vendor lock in. Will Amazon running a special this week, buy 100 compute hours and get 10% free? Maybe Azure run a buy one get one free special on VMs? As the heavyweights of public cloud services start duking it out we’ll start to see all sorts of crazy incentives, but will you be able to take advantage of them?
But all of that container goodness needs somewhere solid and secure to run, and that’s your virtual environment. There is likely to be a level of maturity surrounding that virtual environment which will make it the ideal place to segregate the guest OSs required to spawn all those containers.
It will also take more cross skilling of roles. People that might have traditionally been labelled developers vs. people that might have had an operational focus will be smashed together in a kind of dev and ops mash up - I wonder if that’s a thing ;-)
Simply thinking container vs. VM isn’t going to help you.