posted

DockerCon 2016 is now over and it was a great success. The VMware CNA team (along with the VMware cloud management, networking and storage teams) was there, and the traffic at the booth was astonishing.

We noticed booth visitors had plenty of questions around container technologies and their relation to virtual machines, especially around some of the technologies we presented at DockerCon–some of which are meant to blur those boundaries.

In this post, we are going to briefly outline our technologies and brands to help people better understand them. This includes:

If you are curious about any of the above technologies (and what they deliver and how they deliver it), please read on.

Before we get into a brief description of each technology, it is important to understand they fall into two completely different categories.

The first model assumes instantiating “docker images as containers in VMs.” This is the Photon bucket.

The second model assumes instantiating “docker images as VMs.” This is the VIC bucket.

The Photon Model

As we alluded to, this model involves a traditional “containers on top of VMs” model. This is Docker business as usual and what pretty much everyone does today: you instantiate a Linux OS, you install Docker on it and you start containers pulling Docker images from a registry.

In this context, we deliver the following Photon components:

Photon OS: in either model, one thing is clear – the container runtime environment should be smaller and more efficient than traditional OS. Our OS partner ecosystem validates this, as just about every major vendor has created a super-slim version of their OS. But, for VMware, because of our infrastructure platform, there was even greater opportunity. Because we were free to focus on the vSphere market, we could make things even smaller and even more efficient. We’ve been able to strip all sorts of legacy modules from the Photon OS kernel and tune buffers, time accounting and compile flags to eliminate redundancies between the container runtime and hypervisor. We’re seeing lots of interest around the concept of this type of runtime improvement, but we’re not done. There’s an entire layer of operational efficiency that we haven’t even begun to tackle. Beyond these focused optimizations, we’re seeing customers try things we never intended, like using Photon to create their container images (there is a Photon OS image in the Docker hub, check it out!). Others are looking at more traditional Linux application architectures running on Photon OS to take advantage of the optimizations there, as well.

Photon Controller: this is the highly efficient, completely distributed, API oriented and easy to maintain control plane that, by leveraging the ESXi hypervisor, can deliver a lean IaaS stack. The work to integrate Virtual SAN and NSX into this compute stack is underway. In addition to providing core IaaS functionalities, Photon Controller also includes cluster management workflows that will allow users to instantiate Swarm, Kubernetes and Swarm clusters. Cormac Hogan and William Lam have good articles on how to set those up. Go check them out!

Photon Platform: this isn’t a technology per se but rather a brand name to identify the container optimized IaaS platform above. Photon Platform is the brand name that includes ESXi and Photon Controller technologies, similar to how vSphere is the brand name that encompasses ESXi and vCenter technologies.

It is important to understand that Photon Platform isn’t a disruptive model when it comes to “Docker thinking.” The industry have been using this model for 3 years now:

  • you get a hypervisor (Photon Machine)
  • you get a hypervisor control plane (Photon Controller)
  • you instantiate a VM as a Docker host (Photon OS)
  • and you eventually run a container inside said Docker host

Container management and orchestration is out of scope for the Photon technologies. As a matter of fact, the very first supported commercial bundle we have launched is Photon Platform with Pivotal Cloud Foundry.

While you could always download Photon Controller today and instantiate your very own standalone Photon Platform IaaS platform, we are exploring additional out-of-the-box integrations with other container management stacks. For example at DockerCon, we demonstrated a docker-machine integration that you can grab here. Using this driver, you can leverage docker-machine to provision Docker hosts on top of the Photon Platform.

The VIC Model

The VIC model is indeed disruptive when it comes to traditional “Docker thinking” but, at the same time, it is intended to be the least disruptive when it comes to traditional data center operations.

Many have made the observation that containers running in Linux are similar in concept to VMs running on a hypervisor. They main difference is that a VM must run an operating system, whereas a container inherits an operating system. This is one of the reasons why containers are fast and efficient – there’s nothing to boot. As such, when you run containers in a VM, the VM hosting the containers is a little like a nested hypervisor.

But what if your nested hypervisor is far less capable than your actual hypervisor? It doesn’t come with clustering, HA, live migration, hardware virtualization security, etc.

VIC brings the container paradigm directly to the hypervisor, allowing you to deploy containers as first-class citizens, bypassing the pre-requisite for Linux VMs. The net result is that containers inherit all of the benefits of VMs, because they are VMs.

With vSphere Integrated Containers, the Docker image, once instantiated, becomes a VM inside vSphere. This solves security as well as operational concerns (we have learned one thing or two in the last 15 years on how to run applications inside VMs in production) at the same time.

But these are NOT traditional VMs that require 2TB and take 2 minutes to boot. These are usually as big as the Docker image itself and take a few seconds to instantiate.  We call them ContainerVMs to underscore they are not traditional VMs. They boot from a minimal ISO which contains a stripped-out Linux kernel (based on Photon OS), and the container images and volumes are attached as disks.

The ContainerVMs are provisioned into a “Virtual Container Host” which is just like a Swarm cluster, but implemented as logical distributed capacity in a vSphere Resource Pool. You don’t need to add or remove physical nodes to increase or decrease the VCH capacity, you simply re-configure its resource limits and let vSphere clustering and DRS handle the details.

The biggest benefit of VIC is that it helps to draw a clear line between the infrastructure provider (IT admin) and the consumer (developer/ops). The consumer wins because they don’t have deal with managing container hosts, patching, configuring, etc. The provider wins because they can leverage the operational model they are already using today (including NSX and VSAN).

Your developers will continue to “docker run busybox” and your (IT admin) will keep managing VMs. The best of both worlds.

This isn’t to say this is the best model. It’s yet another option. If you think using containers as a run-time for your Docker images is the best route to take for your project, then Photon Platform is the best underlying place to run those Docker Hosts (and containers on top of them).

Note: if you have heard of “Project Bonneville” that is <just> the internal name we gave to the research project, started 2+ years ago, that culminated in VIC as we see it today.

The Third Option

What we have discussed so far are the two main models.

Photon Platform is disruptive when it comes to the operational model you have today (assuming you are running vSphere). But on the other hand it is optimized to run containers at scale and so it’s aligned to the “Docker thinking.”

VIC is disruptive when it comes to the “container model” you usually think of when you think of Docker but on the other hand it is optimized for operations. (Or, in other words, you can keep your operations).

A lot of customers are still using a third option (somewhere in between) that is leveraging vSphere. Think of this model (running Docker images on containers on Docker host VMs running on vSphere) as a way to mitigate the disruption: you are running VMs on a very well operationalized infrastructure and you are running Docker images as traditional containers.

This model doesn’t solve the operational burden of running containers in production nor does it solve the need for having a multi-tenancy IaaS platform that is optimized to run containers at scale.

Nevertheless, this could be a great choice for many customers and we are working to integrate vSphere functionalities with Docker technologies (for example: the new Docker Volume Plugin for vSphere).

We see Photon Platform, VIC and vSphere as a continuum of solutions, possibly radically different to cover the spectrum of all customers’ needs and their very different maturity level when it comes to running Dockerized applications in production.

Conclusion

This post was not intended to go deep into the technologies discussed but to give you greater context of the various technologies and brand names we showcased at DockerCon 2016.

We covered two new models (Photon Platform and VIC) that are being developed to purposely address the Docker wave. Additionally, we are positioning vSphere as a viable platform for Dockerized applications that minimize operational disruption.

The picture below may help visualizing (at a high level) how these three stacks compare with each other:

Overview of Running Containers in VMware Environments

Overview of Running Containers in VMware Environments