Adding some more colour to the highlights from my VMworld US 2016 coverage:
I attended a group discussion hosted by Ben Corrie who was the clever guy who put together last year’s VMworld demo of the game Prince of Persia running in MS-DOS in a container!
It was a pretty high level group discussion, Ben asked for agenda things to go through:
He went through the reasons for vSphere Integrated Containers which is to provide a Docker API consistent experience to developers yet also provide a VM consistent experience to operations people. Each container is spawned as a VM so all the security, availability, backup, scheduling and management procedures you have for VMs can now work with containers as well.
Containers 101 – VMs have a private name space with resource constraints, containers also have the same construct of a private name space but without a shared OS.
Docker made containers easier to deploy by bringing a daemon to act as control plane, also layered image management.
Problem solving/value proposition: portability, state management, operational efficiency, automation
vSphere integrated Containers: Docker commands send from docker client, VIC deploys a regular VM, image pulled from docker registry, the VM is booted with small PhotonOS .ISO just to be able to connect over serial port. Container as a VM, you get same networking / storage / scheduling / availability etc. as a regular VM.
Photon Platform: orchestration platform for creating container hosts
Also went through roles of what developers and operators do.
Discussion on portability, from laptop to production, same image.
Direct VIC integration with NSX is coming in the future, if you already have NSX it will work and be available as a network but currently you can’t add new NSX constructs. So, the demos of container management with NSX and VIC are a little premature.
As for compatibility Mesos, etc that don’t use native Docker APIs don’t work as they normally expect an agent within Linux to look at the processors and iptables. This isn’t in the VM, anything that is native Docker API compatible will work. This is going to get interesting if your operational people are going to want to use higher level container management tools which are then not compatible with VIC which your ops people want to use to get visibility.
You can go and have a try for yourself at : http://github.com/vmware/vic-product
I was actually genuinely interested that very few people in the session actually knew how containers worked even at a high level. I expected the group discussion to be more of a deep dive considering Ben’s deep architectural knowledge. It seems containers are very new after all or perhaps there were other deeper dive container sessions on at the same time. Containers are going to be deployed very badly in many cases, existing apps are just going to be repackaged to run in containers. This fits perfectly into VMware’s vision for running containers as VMs. Packaged apps running as they did in VMs but now as containers will need the underlying infrastructure availability and operations that vSphere is great at providing. This is however the wrong way to approach the true benefits of containers which should be microservices but its not going to stop people heading down that road and VIC is there to help.
Scott M. Fulton III from http://thenewstack.io/ was also in the sessions and has also written some more on the tech at VMworld.
VMworld2016 has made the recording of many sessions publicly available but not this one it seems.
Recent Comments