Introduction
As a former vSphere and now OpenStack Architect, I’ve been following with much interest the courtship ritual that VMware has been performing with the OpenStack project. Dan Wendlandt and the entire OpenStack Team at VMware has been busy courting the OpenStack community at various venues, including the recent OpenStack Summit. For the Grizzly release, VMware began contributing code to integrate vSphere with OpenStack; the code contribution has steadily increased both in quantity and in scope moving into Havana and continuing into the upcoming Icehouse release.
I’ve been writing about some of the work that VMware has done to integrate vSphere with OpenStack compute and their VMDK format with OpenStack block storage. This has allowed me to participate in a number of conversations about VMware’s commitment to OpenStack and what is their end-game may be in all of this. After all, VMware has not historically being a stalwart in the open source community; clearly, they are investing resources into OpenStack because they expect an eventual return on their investments.
So What Is VMware Up To With OpenStack?
As an interested observer, I’ll like to take a shot at answering that question. However, let me preface everything by saying that I do not work for VMware and despite my interactions with Team OpenStack at VMware, I do not have any inside knowledge to share. Instead, my views are based on my experience working with VMware and their products and observing their involvement in the OpenStack community.
In general, there seems to be two prevailing views regarding VMware’s involvement with OpenStack. The first view is that of the conspiracist who believes that VMware’s involvement is a way for them to sabotage an opponent from the inside. This is a common charge made against large vendors who involve themselves in the open source or open standards world. For example, that charge was levied against Oracle when they purchased SUN and basically bought their way into the MySQL world; in many ways, the jury is still out on that marriage. However, in the case of VMware and OpenStack, there seems to be a growing consensus that VMware is genuinely committed to OpenStack. The most public change in opinion came from Boris Renski, co-founder and EVP of OpenStack integrator, Mirantis; Renski had previously opposed VMware’s membership in the OpenStack Foundation. But now Mirantis is partnering with VMware to deliver vSphere integrated OpenStack deployments and Renski is openly advocating the use of vSphere with OpenStack. The truth, of course, is that there will always be detractors until the day that VMware open sources the vSphere code.
A second view is that of the pragmatist who sees VMware’s involvement with OpenStack as a classic example of a tech vendor hedging its bets by ensuring that its products work with a potentially competing technology. An example of such a move is Microsoft porting its Office Suite to Mac OS in order to capture the business productivity application market. The view here is that while VMware would obviously prefer that customers purchase their vCloud Suite and host VMs outside their data center on vCloud Hybrid Services (vCHS), there will be a certain percentage of customers who will adopt OpenStack as their Cloud platform of choice. From VMware’s standpoint, there might even be a possibility that OpenStack will eventually win out; in that scenario, VMware wants to ensure that their products are the virtualization technologies of choice underneath OpenStack, even if it means making those products work with open source hypervisors such as KVM and Xen. This is similar to the view espoused by consultants and pundits like Keith Townsend, who blogs about the future of VMware.
My own view is similar to the pragmatist view although I do not necessarily agree that VMware is planning to make all its technologies compatible with hypervisors other than its own. Some point to NSX as the model for where VMware is going in terms of embracing an open source and a multi-hypervisor future.. However, I actually think the NSX model has also provided VMware with a roadmap for how to differentiate vSphere from other hypervisor technologies in a “Cloudy” world. The key, I believe, is to understand the link between Cloud Computing and VMware’s vision for the Software-Defined Data Center (SDDC).
The SDDC Isn’t The Cloud
VMware’s vision for SDDC has been well publicized and is at the heart of where they want to take current and future customers. While VMware markets its SDDC architecture as a building block for Infrastructure-as-a-Service (IaaS) Clouds, some have conflated SDDC with Cloud Computing. In a previous post, The SDDC Isn’t The Cloud, I argued that the SDDC, as VMware envisions it, is not synonymous with the Cloud but is an enabling technology to build IaaS Clouds. To sum up my views from that post… Cloud platforms, such as OpenStack, orchestrate the management and the provisioning of virtualized resources in order to deliver those resources as consumable services at scale. The SDDC vision is to not only virtualize the underlying hardware infrastructure but to make it fully programmable i.e. the ability to treat infrastructure as code. The ability to program the infrastructure dynamically from a northbound “controller” such as OpenStack, could enable end-to-end management and provisioning from the virtualized resources down through the underlying hardware.
So How Is VMware Bringing The SDDC To OpenStack?
My thesis then is that VMware is tying to bring its vision of the SDDC to the OpenStack project in the hope that it make them the Cloud vendor of choice for both legacy and next-gen applications. They are doing so, not by minimizing vSphere and the ESXi hypervisor, but by placing it front and center as THE hypervisor that can enable OpenStack to orchestrate resources running in a SDDC. In this, they are taking a page from the NSX playbook of combining proprietary networking and open source technology to deliver Software-Defined Networking (SDN). The added benefit of taking this approach is that legacy VMware customers who are looking embrace SDN and Cloud Computing platforms, such as OpenStack, can do so while still using their familiar vCNS technology and vSphere Switches.
VMware took their first step, I believe, in making vSphere the lynchpin of their OpenStack with SDDC strategy when they contributed the VMwareVCDriver to enable OpenStack to manage vSphere clusters. It provides a means for VMware customers, who choose to go the OpenStack route, to use a familiar and trusted hypervisor with features they have come to rely on, such as HA, vMotion, and DRS; more importantly, VMware hopes to convince those same customers that they are providing an on-ramp, via vSphere, to a Cloud that is powered by the SDDC.
To get a further glimpse of how VMware might look to execute further on this OpenStack with SDDC strategy, it may be instructive to look at the blueprints submitted to the OpenStack project; in particular, take a look at the blueprints related to storage. Why is storage such an important component? As VMware’s vision for a programmable infrastructure has evolved, the infrastructure layer that has been the focus of their recent attention has been the Storage layer; for example, read this recent blog post on Software-Defined Storage (SDS) by VMware’s Office of the CTO. Technologies such as Virtual SAN (VSAN), VM Storage Policy, and Virtual Volumes (vVOLs) are VMware’s attempt to create a SDS layer in their SDDC architecture. In the Havana release, VMware added the capability of using VMDK files as the backing storage for OpenStack Cinder block volumes. Initially, this may seem to be a trivial feature and unnecessary given that ESXi hosted VMs could already attach Raw Device Mapped (RDM) disks as Cinder volumes, similar to instances hosted by other hypervisors such as KVM. However, as I have written about and the associated software blueprint indicates, this feature “also positions Cinder to take advantage of features provided by VMFS and upcoming technologies such as vSAN, vVOL and others.” These advantages, however, are only available to OpenStack Clouds running vSphere.
Moving into Icehouse and beyond, a review of the various blueprints submitted by VMware reveals additional storage-related enhancements. This includes a blueprint to support the use of VSAN datastores as a VM’s primary disk and another blueprint to give OpenStack the ability to map a Cinder volume type to a the VM Storage Policy for a VMDK volume; the latter feature is a steps toward enabling the underlying storage to be managed from either vCenter or OpenStack. Taken together, these enhancements further the path to OpenStack integration with VMware’s evolving SDS architecture, all through the vSphere construct. With the compute and storage layers of the SDDC being managed via vSphere, the networking layer being managed via NSX, and all integrated with OpenStack, I believe VMware is building a solution that could convince their enterprise customers to choose vSphere as their Cloud hypervisor of choice.
Conclusion
Assuming I am correct in my assessment of what VMware hopes to do with OpenStack, is this a viable strategy? Much of it, of course, has to do with their ability to execute on the vision of SDDC and the integration with OpenStack. The other factor to consider is what other contributors to the OpenStack project may be willing and able to do in terms of building competing programmable infrastructure solutions into OpenStack. Only time will tell, but if I am right, it will make for a very interesting 2014 in the OpenStack and VMware worlds.
Related articles
Installing The vSphere OpenStack Virtual Appliance (VOVA) On Your Laptop, Part 1 (cloudarchitectmusings.com)
Installing The vSphere OpenStack Virtual Appliance (VOVA) On Your Laptop, Part 2 (cloudarchitectmusings.com)
VMware Advances Support for OpenStack Framework (virtual-strategy.com)
Filed under: Cloud, Cloud Computing, IaaS, OpenStack, SDDC, Virtualization, VMware Tagged: Cloud computing, OpenStack, SDDC, VMware, VMware ESX, VMware vSphere