VIC’s Uncool GA

Hard to believe that almost two months has passed since my last update. Much has happened in that time, not least the fact that VIC Engine and Harbor GA’d. Kicking ourselves for not having a make it cool GitHub Epic targeted for the release, but you always forget something.

The engineering team spent some time before Christmas coming up with some blog content that is gradually dripping its way out onto here and here. I have a list as long as my arm of blogs and videos I want to put out and despite promising to start, my selfish desire to relax over the holidays got the better of me.

Docker’s containerd announcement was a great end-of-year gift to the team as this should allow us to modularize much more effectively, reuse more common code and provide a compatibility layer to enable some cool integration. The whole purpose of our re-architecture of Bonneville and being fully open-source was to enable these kinds of integrations.

Sketching out a plan for containerd integration is currently top of my list of priorities and I’m very pleased to announce one of our engineering team, Vlad Burenin, will be a full-time contributor to the project.

Looking back over the year, it’s interesting to think about what we could have done better and what we’ve learned. One of the things I spent most of December doing was performing a subtle pivot in messaging what VIC is and what it’s for. There seems to be a fog of confusion that I don’t seem to be able to break through around VIC engine: The fact that a Virtual Container Host isn’t a literal host. The difference between running a container as a VM vs in a VM. How it’s different to Photon Platform. There’s three blog posts right there (note to self). The net result of this confusion has been a perception of VIC engine as being a one-trick pony — something that’s a bit niche — something that might be useful for legacy workloads, but couldn’t possibly sit under something genuinely cloud-native like Kubernetes.

What I’ve realized is that in order to convey what VIC engine is, I need to start talking about it first an foremost as a VM provisioning mechanism that provides a means for a vSphere admin to create a self-provisioning portal for developers. This is exactly what it is today, by the way. It just so happens that the binary format for VM provisioning is the Docker Image, that the VM has all of the characteristics of a container; and the API of the self-provisioning portal is the Docker API.

Once you realize this and once you grok that anything can be spun up as a VM, you realize that what we’ve built is a means of allowing anyone to self-provision anything into vSphere infrastructure without needing any vSphere credentials, without raising a ticket and in a way that allows the Admin full control over the infrastructure. You can spin up a Docker host. You can spin up a Linux VM running sshd, you can spin up a Tomcat server, you can spin up Jenkins slaves. You should even be able to spin up a Kubernetes cluster. And everything you provision can be customized and stored in DockerHub. Without raising a ticket. Or asking anyone first.

Now that’s cool if you ask me.

Originally published at on January 19, 2017.

Like what you read? Give Ben Corrie a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.