Why VMware Is Embracing Containers
Take a look at one dev's thoughts on why VMware is making a push into the container ecosystem, how they plan on doing it, and some possible challenges.
Join the DZone community and get the full member experience.Join For Free
There are no secrets now around the adoption of containers by VMware. There is, however, some confusion among many as to what exactly the reason and methods are for VMware to embrace containers. Many announcements have been happening since VMworld in San Francisco in August 2015. Once the big show for revealing all the new toys among the VMware core ecosystem, the US event turned out to be a strategy session this year followed by some long-awaited and important product announcements in Barcelona for the 2016 event.
Photon, or VIC? Not an OR, but an AND Strategy
The first thing to tackle is some confusion around whether VIC (vSphere Integrated Containers) or Photon Controller will be the place in which VMware customers will deploy and manage a containerized infrastructure within the realms of their vSphere environments.
From what I understand, based on current detail available, VIC is the environment which will present an abstraction to vSphere so that existing Docker clients may be able to deploy using native Docker management, while really using vSphere storage and networking underneath the covers. VIC will be able to be consumed via the API, and will also have some visible management within the vCenter interface.
Where VIC differs from Photon Controller is that Photon is meant to be the layer to the bare-metal, hypervisor, or cloud-container such as Amazon Web Services EC2. Photon is more geared towards trying to be a universal control plane across different infrastructure, while presenting common API services which will adapt to other platforms within the containerized market.
You’ll find that the goal is to run both VIC for existing vSphere environments to allow for container support, while running alongside dedicated Photon environments which are specifically trying to get ahead of the scale-out data center operating system competitors.
Why Photon Over Existing Open Container Scheduling Frameworks?
This is the $1 million question. I’ve often wondered about the reasoning for deploying a new framework to handle container orchestration and scheduling when there are clearly a good selection in the market already. Not only a good selection, but ones which are already fighting over market share in hopes of becoming the de facto standard.
When Photon Controller was released, I questioned the strategy a little bit. I also know that the VMware team doesn’t do things entirely in a bubble, and clearly, they are aware of what this may do as they look to try to become a player in the container game. Whatever the downstream compatibility requirements are to make Photon the abstraction layer, the real hopes for adoption will be in the presentation of compatible APIs for existing frameworks.
Kubernetes as a service offering within Photon will mean that a direct API call can trigger the launch of a Kubernetes cluster within the Photon environment, followed by the ability to use any Kubernetes-compatible platforms atop of that layer. Think of it as the padding to the real workloads which abstracts all it needs to in order to be able to present the type of infrastructure APIs that will win over the development crowd.
Speaking of Photon, there is also Photon OS. This is the CoreOS-like tiny Linux offering that VMware is using to power their vCenter Server Appliance for version 6.5 which will release in the coming months before the end of 2016. Photon OS is an open source alternative to the many competitors in the field, and as you can imagine, it’s tuned to be able to leverage features within the Photon Controller platform.
If you Can’t Beat 'em…
Well, you know the rest of that statement. VMware has launched plans for a deployment on AWS as a dedicated offering, plus the addition of VIC and Photon Controller to capture some of the fast-growing container market. There are many ways to address this growing market, and VMware has clearly chosen to try to open up the menu to next-generation consumers.
My belief is that they are also trying to be an onramp for existing customers in order to stop the inevitable bleeding as more technology spend is leaning towards cloud and container architectures. If nothing, this presents a way to slow the adoption of other technologies by existing customers. That’s a whole other discussion unto itself.
I’m looking forward to seeing all of these products hit the production floor soon, and we can look to the industry to see if the uptake of containers on VMware environments will match the adoption rate that we are seeing already amongst alternative competitors.
Published at DZone with permission of Eric Wright, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.