exploits on Linux are rare, but a few occur each year, leaving the possibility that one of them will act as a spoiler in a sensitive container environment.
Virtual machines, however, exist as a set of file definitions and policies that mimic a real machine, with logical boundaries around server resources to set them apart from other VMs. They have a small attack surface. The host's hypervisor does its work with just 30 or 40 commands communicated directly to the hardware. They can be periodically checked and protected; alterations are easily detected.
Containers, on the other hand, are much faster to spin up, replicate and scale-out, all important qualities in Web operations. Google is a practiced user of containers precisely because its search and internal operations exploited those efficiencies. It created the Linux control groups and much of the original source code that underlies Docker operations. So why is Google helping VMware put containers in virtual machines?
Google runs them that way when it's dealing with customer workloads headed for App Engine or Compute Engine. (Unlike VMware, it puts them inside a KVM virtual machine.) It's in Google's interest to have more IT departments familiar with and accustomed to using containers. That familiarity will potentially increase the attractiveness of Google's cloud services. Hence, its willingness to make its Kubernetes container provisioning system available as open source code and continue its development with VMware.
Containers also represent a way for VMware to reach application developers, a community that may be less interested than VMware in virtual machines and production security. VMware has spun off the parts that interest developers, such as the Cloud Foundry development platform and Gemstone caching system, into its Pivotal subsidiary. One of things Pivotal has produced is Pivotal CF, a commercial version of the Cloud Foundry platform.
James Watters, Pivotal's VP of product and ecosystem for Cloud Foundry, says container efficiencies can be easily carried over into a virtualized environment. More than one container may be run in a virtual machine; in all likelihood dozens or hundreds will be. The resources needed to keep a dozen containers in one virtual machine are much less than the resources needed for a dozen virtual machines. In a multi-tenant world, there's a limit: Containers in one virtual machine are probably going to come from one customer and not be mixed with those from another customer.
So the "blend," as Watters puts it, of container technology with the manageability and security of virtual environments is likely to be the recommended path for IT managers for a long time. VMware, Docker, and Cloud Foundry "are building in very robust Docker support. I'd argue VMware has the most advanced container management system in the world," Watters said in an interview.
With Google and Docker seeing big advantages to fitting containers into the VMware environment, that's how it's likely to remain -- at least for a while. But I still think that containers running inside virtual machines represent an architecture that's very close to VMware's interests rather than the only sensible way to run containers. Other possibilities will one day manifest themselves for launching and running containers on their own. But until some startup or disruptive coalition shows a system with the potential to do it, we'd better get used to hearing about the benefits of blending the two together.
Cloud Connect (Sept. 29 to Oct. 2, 2014) brings its "cloud-as–business–enabler" programming to Interop New York for the first time in 2014. The two-day Cloud Connect Summit will give Interop attendees an intensive immersion in how to leverage the cloud to drive innovation and growth for their business. In addition to the Summit, Interop will feature five cloud workshops programmed by Cloud Connect. The Interop Expo will also feature a Cloud Connect Zone showcasing cloud companies' technology solutions. Register with Discount Code MPIWK or $200 off Total Access or Cloud Connect Summit Passes.