Having made its fortunes virtualizing the X86 servers at some 500,000 customers worldwide, there is no bigger threat to the continued financial success of server virtualization and cloud player VMware than the wild enthusiasm that software development teams have for Docker containers. Everyone knew that VMware would have to respond in some way, and the answer is simple and elegant. VMware is going to make virtual machines running on its ESXi hypervisor look and feel like Docker containers.
What VMware seems to be betting is that a large portion of its enterprise customers want to layer containers on top of their existing virtualized server infrastructure without going all the way and embracing the still-nascent stack of orchestration and management tools from Docker, the company, or various open source alternatives, such as the combination of the Mesos cluster controller and the Kubernetes container management system that has been integrated on it. The former is inspired by search engine giant Google’s Borg controller, and the latter is actually code contributed by Google to the open source community to manage Docker and rkt containers. Google created Kubernetes with inspiration from its own container management inside of Borg and specifically to manage containers atop the Google Cloud Platform public cloud.
As it turns out, there will be many different ways to skin the Docker container management cat before this is all done.
Microsoft, for example, created its own Nano Server minimalist operating system specifically for containerized environments – based on its own experience with the Azure public cloud – and is working with Docker to bring container support with various flavors to the future Windows Server 2016. Microsoft will in fact deliver two kinds of containers – one called a Windows Server Container and the other called the Hyper-V Container – that will be managed by Docker Engine, the runtime controller for the commercial Docker stack.
VMware has been taking a parallel course, and in April announced its own minimalist Linux operating system, called Project Photon, which was designed explicitly to support Docker, rkt, and Garden (used by Pivotal in its CloudFoundry platform cloud) containers running atop the ESXi hypervisor and hooked into VMware’s NSX virtual networking stack.
With a standard container format and runtime announced this week at the DockerCon conference, which all the major players in servers, operating systems, and virtualization have gotten behind, the competition will be less about what image format to use and how it runs, but rather how well the implementation of what in essence will be a Docker container format and runtime environment that appeases the security needs of CoreOS, which used to be a staunch Docker supporter in its CoreOS hyperscale Linux but which broke ranks late last year to create the appc container format and rkt runtime as an alternative to Docker’s libcontainer format and Docker engine runtime, collectively known as runC. With Google and Red Hat steering the standard along with Docker and CoreOS, we are confident that a unified container format and runtime will come to fruition and that is an even bigger threat to VMware than a fragmented market would have been.
Or, perhaps not, if yet another effort announced this week by VMware, called Project Bonneville, comes into play.
Project Bonneville is a set of code that is in technology preview now and that fulfils VMware’s promise to integrate Docker containers into the VMware ESXi hypervisor and vSphere extensions. Ben Corrie, a senior staff engineer at VMware who is managing the Bonneville effort, blogged a bit about it and explained that the uniting of VMware’s virtualization infrastructure and Docker’s container formats and repositories will perhaps be the easiest way for enterprises to deploy Docker.
Last summer at the VMworld conference, when the top brass said they would embrace Docker, it turns out that Corrie and his team were already two months into the Project Bonneville effort, and the essential argument that Corrie makes is that a container “is a binary executable, packaged with dependencies and intended for execution in a private namespace with optional resource constraints” and that a container host “is a pool of compute resource with the necessary storage and network infrastructure to manage a number of containers.” And once we have established these definitions, then a virtual machine can be said to fit the definition of a container and a hypervisor is a container host. This sounds very similar to Microsoft’s Hyper-V Container, at least in concept.
To be more precise, Project Bonneville is a Docker daemon that has custom drivers for networks and execution that is compatible with the Docker Client APIs, and that means an ESXi VM is treated exactly like a Docker container. The way it works, Bonneville downloads containers stored in the Docker Hub repository, or the on-premise version called Docker Hub Enterprise, and fires it up in an ESXi VM using the Instant Clone feature of the ESXi 6.0 hyperviser, developed under the codename of Project Fargo, that was announced last fall. One of the complaints with server virtualization in general is that hypervisors have too much overhead and it takes too long for VMs to start, and the Instant Clone feature can fire up clones up to ten times faster than the traditional way vSphere does it.
By the way, if customers want to fire up the Photon minimal Linux inside of a VM as part of the Bonneville container, they can do that and then put Docker containers on top of them. Or they can just run containers with their bits of system and application software raw on the hypervisor. The “pico” version of Photon, as Corrie calls it, has a footprint of about 25 MB compared to something on the order of 3 GB for a full-on Linux operating system. At the moment, Bonneville only supports containers running Linux applications on X86 iron; it is possible that VMware comes up with a scheme to support Microsoft’s Nano Server and skin the Hyper-V Container concept using an ESXi VM as the basis, much as it has with Docker containers. Microsoft is supporting the Docker APIs, so this should not be terribly difficult for VMware to do.
Here is the real question, then. Will Microsoft, VMware, and Red Hat be able to embrace and extend Docker to such an extent that the actual Docker and its tools are limited to greenfield applications and large-scale enterprises and service providers who are looking to completely revamp their infrastructure? With a unified container format and runtime, largely based on the work from Docker, CoreOS, and Red Hat with lots of input from Google, the job is actually easier for three biggest systems software suppliers to add containers to their wares and make it harder for upstarts like Docker and CoreOS to get actual business. This will probably have zero effect on the ability of these upstarts to get venture funding.
The other question is what VMware will be charging for Bonneville and related tools. The software will go into private beta in the third quarter, and probably will not ship for production until early 2016. And it is our guess that VMware will be perfectly content to give away Bonneville for free in exchange for keeping its lucrative vSphere, vCenter, and vCloud licenses and support contracts renewing. Microsoft will probably do the same with its Docker stack and various container formats, too, for exactly the same reason.
Sign up to our Newsletter
Featuring highlights, analysis, and stories from the week directly from us to your inbox with nothing in between.
Great write up, thank you. Just a quick clarification on the “multi-OS support” in Bonneville. Given the fact that we’re using x86 hardware virtualization and given that all of the container infrastructure pieces – the layered filesystem, the SDN, the Docker image cache – are managed by the hypervisor, Bonneville can theoretically bring full Docker support to any x86 operating system. At Dockercon, we showed off our experimental MS-DOS 6.22 support, which we built to powerfully illustrate this message. We took a legacy OS which has no support for containers and using a vanilla Docker client to go through the full workflow – Dockerfiles, images, containers – with a completely different OS. As such, we could containerize any flavor of Windows, Android, FreeBSD etc.