Why Docker != Containers and Docker OSS != Docker Inc.

You try to convey a concept but it’s only when something (else) happens that people have their “Aha moment”.

Last year VMware introduced a project called Bonneville that later became vSphere Integrated Containers.

Having recently moved to the VMware Cloud Native Application Business Unit, working on Bonneville and VIC has been one item of my charter.

If you didn’t bother to check the blog posts linked above, in a nutshell, vSphere Integrated Containers is a technology that allows you to provision a VM while maintaining the Docker experience (API/CLI, images format, public registry, etc). The advantage of doing this, in short, is that developers win (as they “want Docker”) and IT wins (because most IT shops have standardized operations around VMs).

This is often a hard concept to grasp because of a core fundamental misconception that pervades the industry: Docker = containers.

This is about to change.

Enter “unikernels”.

From this point on, everything I am writing in this post is pure personal opinions and have nothing to do with my professional role (just as a reminder).

A few days ago Unikernel Systems announced they were joining Docker (Inc.). There is a short video that talks about it here.

During the video there are a few gems.

This notion that “the ability to use the same Docker tools, which have been widely adopted with developers, will rapidly accelerate unikernels adoption” is very important in the context of understanding that Docker != containers.

One could go as far as paraphrasing that into (in the context of Bonneville): “The ability to use the same Docker tools, which have been widely adopted with developers, will allow users to leverage the traditional VM construct IT has standardized on”.

Or put it in another way picture (a somewhat simplify view):

You could, potentially, choose the right tool back-end (be it a Unikernel, a container or a VM) for the right job without disrupting the front-end experience.

This is a very powerful concept.

By the way, it is important to understand, in the picture above, that that VM doesn’t represent the VM on top of which you run an OS which can then run a container. In other words we are not talking about whether you should instantiate containers on a bare metal OS or on a OS running in a VM.

What I am showing in the picture above is a VM instantiated by Docker (that’s what the vSphere Integrated Container technology does).

If you want to go deep, I suggest you watch Ben Corrie’s session on Bonneville at QCon last year. It’s well worth the investment of 50 minutes of your time.

Back to unikernels now.

There have been a few very deep technical rants on the blogosphere about why unikernels are unfit for production (which is a somewhat relative statement given that, depending on who you ask, you may hear that VMs aren’t fit for production; not sure where this would leave containers honestly).

There have also been quite a few online discussions on the topic one of which is this very lengthy thread on Hacker News.

What stood out for me from this sea of comments were the statements that Solomon Hykes (Founder and CTO of Docker) made:

“Computers do run only one unikernel at a time. It’s just that sometimes they are virtual computers. Remember that virtualization is increasingly hardware-assisted, and the software parts are mature. So for many use cases it’s reasonable to separate concerns and just assume that VMs are just a special type of computer.

For the remaining use cases where hypervisors are not secure enough, use physical computers instead.

For the remaining use cases where the overhead of 1 hypervisor per physical computer is not acceptable, build unikernels against a bare metal target instead. (the tooling for this still has ways to go).”

I will candidly admit that I am not 100% sure about what he meant by that. Sometimes the nomenclature we all use to refer to things in an IT stack change and this isn’t helping. If you consider also that we are at the early stages and there is a physiological “mess” around the alternatives at our disposal…. well you get the picture.

What I brought home from these statements is that Docker wants to offer options. Be them containers on bare metal, containers on VMs on hypervisors, Unikernels on hypervisors etc.

I see VIC (which I’d refer to as “containerVMs” on hypervisors) as yet another one of those options that Solomon is alluding to.

So a more detailed picture of the alternatives that are panning out for the future should, potentially, look like this:

The fact that Docker bought Unikernel Systems was a big wake up call for many and, if nothing, it’s going to be a great educational moment for the industry as a whole.

This is however coming at the cost of adding additional confusion though:

I said this is a good thing because it gives people the option of picking up the back-end that is most fit for their use case. However, unikernels would have existed anyway regardless of Docker acquiring the company behind them. In other words, a user could have picked unikernels anyway and be done with it.

The cynic person in me suggests that we should see this through the lenses of Docker Inc., the commercial entity behind the Docker OSS (Open Source Software) project.

Docker Inc. has (rightly so) all the interests to remain “top of stack”. As much as they can be “the interface people see and talk to” they are in a strong spot.

They are trying to establish a “control point”. This isn’t per se a bad concept and it’s something that any commercial company is incentivized to achieve as a way to remain differentiated.

I have never come across a commercial company whose strategy was to live in the lowest level of the stack waiting to be commoditized by the technology that could easily sit on top of it. There are well known industry practices and patterns around this.

Now imagine if Docker wasn’t to acquire (and double down on) Unikernels Systems.

If unikernels were to be successful in the future we’d see two separate and parallel stacks (a Docker/container stack and a unikernel stack) with potentially different north-bound interfaces.

In which case there would be a third party (e.g. Kubernetes), agnostic to the back-end run-time and their interfaces, that would provide the single entry point to deploy onto both stacks. This would, as a result, commoditize Docker (both Docker the OSS project and Docker Inc. the commercial entity).

Joe is right when he says that the value is up in the stack but, I think, you need to establish a proper and solid control point before you can exploit and take advantage of it up in the stack.

Now that Docker != containers is hopefully a bit more clear than before, there is another key concept that people will need to familiarize with in the future to exactly understand maneuvers like this.

This other key concept is: Docker OSS != Docker Inc.

This “friction” is already evident among companies and projects like Kubernetes, Mesos and Docker (Inc.). They (and many others) are all “fighting” (commercially) for being that “entry point”.

As a matter of fact, while everyone is standardizing on and using Docker (OSS), Docker Inc. is “just” one of those companies that are trying to build a business model around it.

Docker Inc. has an (obvious) advantage but it is important to keep in mind that Docker OSS != Docker Inc.

In conclusion, just to make it very clear, I want to call out that I am not trying to picture Docker Inc. as the devil.

They are a great company with an ethic that I like (a lot) and they are doing what ALL commercial companies (including the one I work for) are supposed to do: generating profits.


9 comments to Why Docker != Containers and Docker OSS != Docker Inc.

  • nmishkin

    Maybe I’m nitpicking, but since you did mention the potential for confusion related to nomenclature…

    In your final diagram you show “Unikernel” sitting directly on top of “Hypervisor” and at the same level as “VM”. I think it’d be more correct to have a “VM” box below the “Unikernel” box (and above the “Hypervisor” box). Unikernels are just specialized OS’s. They don’t run in the ether. They run *on* a VM or physical machine.

    • Massimo

      Hey Nat. Thanks for chiming in. No you are not nitpicking, I see what you mean. I was trying to oversimplify to avoid more confusion (but I may have introduced more as I simplified too much). When I was drawing that I was focusing my attention on “the unit of deployment” so that box represents what Docker (the interface) is deploying (in the backend). Since the Unikernel gets deployed (I guess) with his own VM, I’d like to keep the box as-is running directly on the hypervisor. What I may/should do is to change the label of that box from “Unikernel” into something like “Unikernel VM” or “UnikernelVM” or “Unikernel + VM”. Your thoughts? Thanks!

      • Massimo

        Now what I may be missing though is the “Unikernel” on top of a bare metal physical machine. I am not sure however how viable a use case like that would be for a traditional “cloud” deployment (maybe more viable for an IoT use case where a “bare metal physical machine” may be a fridge? 😉

      • Yeah, I think “Unikernel/VM” would be the right thing. And probably remove the “VM” box at the end of the 4(b) arc or elaborate on what you mean by it. (What’s the significance of a VM that has no OS of any sort?)

        WRT the “bare metal” environment, I’m not knowledgeable enough about unikernels to say how they operate in such an environment. I can imagine a system built around physical boxes that PXE boot up into a unikernel where the PXE boot server in under the control of a system that dynamically allocates hardware and chooses what unikernel is supposed to run on the hardware. But maybe that’s just my imagination running wild :-)

  • […] are not the only way to deploy cloud native applications (please refer to this excellent post from my VMware colleague @mreferre), but also to acknowledge that they are important for a number […]

  • Massimo, Nat,

    The unikernel in 4a *is* a VM, so I consider it correct as-is. It’s the application code, combined with all the necessary libs in order to run directly on the hypervisor.

    You could also target a unikernel to run on bare metal, by compiling with all the necessary drivers and this has also been done. It’s just a case of using the relevant libraries. This kind of use-case would be more useful for embedded/IoT-style deployments.

    You can even run them as Unix processes (see MirageOS), so they’d be on top of an OS in that case.

    Since it’s just ‘libraries all the way down’ I don’t really draw a distinction between targeting for a hypervisor or for metal. Especially since the toolchain deals with the work of pulling in the required libs.


    • Massimo

      Amir, Nat, thanks for the discussion.

      I think trying to make it perfect (in this context) will risk to make it more confusing for the uneducated on the specific of these technologies. I’d like to stick (for now) to the central point of this post (which is that Docker != just containers).


  • […] Why Docker != Containers and Docker OSS != Docker Inc. […]

Leave a Reply