Originally posted internally 26 May 2016:

Last week I called in on Brad Meiseles, the senior director of engineering responsible for VIC. It’s a product I’ve been watching since the earliest rumblings around what Project Bonneville did with the VMfork technology that had originally been envisaged as something for quicker launching virtual desktop infrastructure (VDI).

VIC has taken a while to hatch, as it’s a complete rewrite of what was done with Bonneville, but it might be one of the most important things to emerge from VMware this year. Containers are a big threat to VMware and all of the vSphere (and associated management) licenses they sell, but VIC gives VMware the opportunity to set up an enterprise toll gate to containers because it gives the security of VMs with hardware trust anchors at the same time as giving the quick launch, low footprint and packaging ecosystem of containers.

There’s just one problem. The underlying technology that VIC uses for its quick launching magic comes with VMfork in vSphere 6, and most of the world is still running vSphere 5.5. Furthermore containers have swept through the industry so fast because most people already have a Linux that can run them, so they haven’t had to wait for the hardware refresh cycles that went along with most ESX/vSphere deployments/upgrades. I’m hopeful that VIC will be released with vSphere 5.5 compatibility; after all quick launch matters a great deal in dev/test environments for quick cycle times, but it’s less of an issue in production, and VIC is very much aimed at being the secure production destination for containers that get developed elsewhere.

Retrospective

VIC hasn’t become as big a part of the enterprise containers conversation as I expected it to be. I think this is down to companies taking a bimodal approach (or preferably pioneers, settlers, town planners [PST]), and so there’s little mixing of existing VM environments with new container environments (which generally tend to be using Kubernetes, quite often under the auspices of Red Hat’s OpenShift).

Original Comments

VK

It is an interesting update. Would like to know if they will extend the support to other docker eco-system components/options, like Swarm or kube, networking , volume mapping options.

This is more a question. IMO, a container solutions need container eco-system of components for their POV, scale and future roadmap. Support to Docker alone is a limited option. what do you think? Cattle needs a helmsman as Kubernetes would say!

CS

Since they’re doing an implementation of the Docker APIs it will work with many other parts of the ecosystem.

It’s explicitly intended to work with Kubernetes, Swarm etc., and if you look at VMware’s broader strategy around cloud native applications (including things wearing the Photon badge) then there’s explicit support for multiple orchestration and scheduling systems.

Things get a little more tricky with aspects like networking. Firstly VMware is trying to position products like NSX as offering better capability than networking based on a host Linux kernel, and secondly any networking that assumes multiple containers sharing the same kernel (which is most Docker networking right now) will run into trouble in an environment where each container has its own kernel.

VK

Thanks.
Anything that works with kube is and should be good (read bais)
NSX is good and rightly complex and solves more than container networking. It addresses the entire enterprise L3 overlay architecture and so on.
but…It is imperative for VMware to share the licensing model easy & upfront, if we are to solution with them mixing with opensource.
Please correct me if I am in isolation saying this. The whole solutioning gets tedious if the licensing info is not available- simple and easy. I call this the Oracle-fuss.
Asking for ‘deal size’, ‘we can work it out’ responses.

To circle back to your main post, project lightwave from VMware is suppose to address the LDAP requirement of photon and in turn their container solution.
If VIC -vSphere level REST support is published, it will Enroute Agility container support