In the Cloud, Virtualization is an Implementation Detail
Join the DZone community and get the full member experience.Join For Free
Virtualization is everywhere. Enormous and highly profitable companies have been built on nothing but virtualization. And nowhere has virtualization made more of an impact than in Cloud Computing, the rampant and unprecedented adoption of which has been the direct result of the wide availability of virtualization software and techniques that enabled it. But does the cloud actually require virtualization?
I think not.
What makes Cloud Computing Cloud Computing?
According to NIST Cloud Computing has a handful of defining characteristics including on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured services. Nowhere does this say anything about virtualization, and all of these features can be obtained without a hypervisor in site.
So Why Virtualization?
Without a doubt, virtualization is the fastest track to enable these cloud features. Virtualization provides:
- resource pooling
- mostly instant availability
- over-provisioning of resources
- server consolidation
- efficient disaster recovery responses
- reduced hardware vendor lock-in
and a host of other capabilities that ease the burden of providing cloud capabilities.
Importantly, the time-consuming and clunky manual tasks of building, installing, loading, booting, configuring, and connecting a physical server can be fully accomplished in software, which means the entire process can be encapsulated and served behind an API. This results in major gains in productivity for ops and developers, and is, as discussed above, the reason that virtualization is the enabling technology for cloud.
Why Not Virtualization?
Virtualization does come at a cost, mostly in the areas of agility, performance and security. VMs are beefy, with large memory footprint, and they’re not exactly quick to start up.
Performance necessarily takes a hit. Fundamentally, a virtual machine or hypervisor will allow “user” code to execute unimpeded, but when “privileged” operations are invoked, the VM must intercept and intervene, making sure these operations behave and do not interfere with the rest of the system. This interception and intervention introduces overhead.
More generally, virtualization enables multi-tenancy where several workloads or tenants share a single physical host. The process of sharing and swapping between these tenants necessarily introduces inefficiencies.
I recently had a discussion with a devops engineer from a significant player in the cloud security industry. He told me that their cloud-based security application services hundreds of millions requests a day, and that by eliminating the virtualization layer they were able to realize a 5% performance increase.
Virtualization also changes the security landscape. Security architects often take advantage of hardware acceleration and other bare-metal features for encryption, entropy, and performance, and these are obscured or unavailable in a virtual environment. Also physical isolation is always more secure than anything a hypervisor can provide.
Additional downsides include potentially inconsistent performance, unpredictable behavior due to the noisy neighbor problem, and increased complexity of failure analysis due to the additional VM layer.
However for most applications and workloads the benefits of virtualization far outweigh these downsides. But workloads with very high throughput, or those that deal with highly sensitive data, might benefit from running on a stack where virtualization isn’t present.
Metal-as-a-Service: Virtual Private Cloud without the Virtual
MaaS, or Metal-as-a-Service, is basically cloud sans virtualization, and allows the delivery of cloud solutions without some of the disadvantages that virtualization brings to the table. Many cloud providers are diving into bare-metal cloud offerings.
Take a look at Canonical’s MaaS which treats compute, storage, and network as commodities, much like virtualization does, but without the overhead of the virtualization layer. From their site: Metal-as-a-Service lets you treat farms of servers as a malleable resource for allocation to specific problems, and re-allocation on a dynamic basis. No virtualization here.
This is a powerful concept that allows complex full-stack apps to deployed to the cloud, with all the above-mentioned cloud features (on demand, self service, etc) yet avoiding many of the downsides of virtualization.
Other IaaS Providers joining the Metal Party
Other infrastructure providers are taking the leap into MaaS. Sign up for Mirantis OpenStack and you can instantly access a dedicated cluster of bare-metal hosts guaranteed to be yours and yours alone, with no noisy-neighbors to keep you awake at night.
And you might find it Ironic that the OpenStack project, mostly focused on provisioning VMs, also has a bare-metal component well underway.
Google and Virtualization
If virtualization incurs a 5% overhead, then Google, with their gazillions of servers, could probably unplug an entire datacenter by eliminating the virtualization layer. Obviously Google is more forward thinking than this, and have been building non-virtualized infrastructure for ages. The secretive Borg project, and more recently, the Omega cluster management system, provide a unified view of compute resources without the need for a virtualization layer.
Apache Mesos provides similar functionality, and its adoption by Twitter shows that they too see the value of a non-virtualized infrastructure.
Containers vs. Virtualization
Containerization is like virtualization off steroids. Containers provide a homogeneous and isolated environment in which applications can safely run, much like virtualization does. But containers are less bulky, more nimble, more lightweight. Instead of the several minutes it takes to boot a VM, a fully-equipped container can “boot” in under a second.
Today most container-based applications run in virtual environments, but this seems almost redundant: containerization on top of virtualization. Why not eliminate the VM layer altogether and provision the containers on bare metal?
Joshua McKenty from Pivotal has strong opinions on this matter. At a recent Cloud Foundry meetup he said: "Containers on bare metal is like having unprotected sex with the Internet."
I wouldn’t go quite that far, at least not until the third date, but Josh clearly has more experience in these activities than I do. And he does have a point. Docker, for example, does not provide the full isolation between different “guests” that hypervisors do. Just ask Google: they run containers everywhere, but when they need true isolation (for example in Google Compute Engine) they run their containers on VMs.
Naysayers aside, there’s considerable work being done by Joyant and others building powerful platforms that provision and manage containers directly on the hardware.
What about Stackato?
Does Stackato run on bare metal? The short answer is yes but we don’t officially support it.
A slightly longer answer: Stackato is delivered as a VM appliance, intended to be provisioned from within a hypervisor. But Stackato at its essence is a bootable Ubuntu image, highly evolved and enhanced to support all the things that makes it an enterprise hardened PaaS suitable for any production workload. But it’s a bootable Ubuntu image none-the-less, and Ubuntu images can be booted on physical hardware just as easily as from a hypervisor.
We don’t officially support bare-metal Stackato...yet. But we could: all you have to do is ask.
In the Cloud, Virtualization is an Implementation Detail
But really, the bare-metal vs. virtualization shouldn’t matter. Virtualization is just an implementation detail. For the vast majority of applications, services, and workloads running in the cloud, the specifics of the underlying infrastructure just don’t matter. Unless you’re in the .0001% of applications that need crazy high performance or have security requirements that aren’t acceptable to the rest of the world, then what’s under the hood makes no difference.
The other 99.9999% should not be concerned with such matters. If you are,, as I’m fond of saying, then you’re in the weeds. Let’s step back and look at the big picture. What are we really trying to achieve?
The Big Picture
This quote, from gigaom, sums it up nicely:
We believe the simpler path for the New Stack is to give power to developers to write modern data center–scale applications against an aggregation of all of the resources in the data center, to build operational support into apps as they are created, and to avoid management of individual machines and other low-level infrastructure.
That’s it! Application teams should not get mired in the complexities of the infrastructure. Instead they should be free to define their platform in terms of resource requirements, policies, SLAs, and high level security constraints, independent of the underlying architecture of the infrastructure. And this precisely is what PaaS, and other modern deployment platforms like Apache Mesos, provide.
Mesos says pretty much the same thing:
...we are also using commodity hardware. So, today, this VM model doesn’t make as much sense any more. Rather than splitting up the applications onto multiple machines, we have to aggregate all the machines and present them to the application as a pool of resources.
The Bottom Line
The panacea here is to allow an app team to deliver and provision software to the data center just as easily as it can be provisioned to a laptop. The interface exposed to the development team has nothing to do with VMs, instead providing a unified view that looks the same whether deploying to a laptop or to multiple datacenters.
If you want to experience it today, in less time than it took you to read this blog, download the Stackato microcloud right now, and see for yourself what’s it’s like to program to your data center from the comfort of your own laptop.
Published at DZone with permission of John Wetherill, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.