VMware positions for the future around vFabric and vCloud

Two of the most significant announcements involved the consolidation of  VMware’s recent acquisitions in the applications platform space into vFabric and the addition of a management offering (vCloud Director) to vCloud which are respectively PaaS and IaaS plays that compete feature-wise with the established market leaders.

vFabric

In VMworld from an Open Source Perspective, we mentioned that in its SpringSource subsidiary, VMware had managed to acquire an entire application stack.  The big VMworld announcement was they’ve given this a name – vFabric.  You can tell it’s a core VMware product – it begins with a small “v”.

The key thing is to understand the value of vFabric in terms of its features vs. the value of vFabric that comes from the integration of vFabric with vCloud and vSphere. Let’s first review the components of vFabric:

vFabric is comprised of the following components:

• Lightweight Application Server: tcServer, an enterprise version of Apache Tomcat, is optimized for Spring and VMware vSphere™ and can be instantaneously provisioned to meet the scalability needs of modern applications.
• Data Management Services: GemFire speeds application performance and eliminates database bottlenecks by providing real-time access to globally distributed data.
• Cloud-Ready Messaging Service: RabbitMQ™facilitates communications between applications inside and outside the data center.
• Dynamic Load Balancer: ERS, an enterprise version Apache web server, helps ensure optimal performance by distributing and balancing application load.
• Application Performance Management: Hyperic™enables proactive performance management through transparent visibility into modern applications deployed across physical, virtual and cloud environments.

vFabric is both a private and public cloud PaaS. For an interesting take on the private vs. public debate read the Laundromat post at Rationalsurvivability.com Hint: VMware really thinks you should have your own washing machine,  rather than going down the Laundromat. Let’s take a look at the differences between vFabric in a private vs. a public cloud implementation.

The key difference is not whether or not vFabric in in fact run in a private or public cloud, but rather whether on not is it run on a VMware provided platform (vSphere or vCloud). VMware intends to build very specific integration between its platforms and vFabric. Some examples are the ability for an application running on vFabric to dynamically request memory (the scarcest resource in a shared system), and the promise on the part of VMware for VMware to assume end-to-end responsibility for the performance of the application IF it is written in Java to vFabric and it is running on one of the the two VMware platforms.

If you are not running vFabric  on a VMware infrastructure bus you are running it on the forthcoming VMforce or Google/VMware Public clouds we discussed at the end of April, and the expectation is that java components would be transferable. However if you took advantage of features uniquely available to you if you were running vFabric on vSphere or vCloud, presumably you would be out of luck in terms of having those features work (memory access) when you tried to run your Java app on vFabric at Google.

vFabric is being made available to the vCloud ecosystem of hosting and cloud providers which consisted of over 2000 companies as of VMworld – all of whom will thus be able to compete with Salesforce.com and Google and potentially get to market first. The key question will be where to the applications come from, as someone has to create the base of applications that get deployed first on either vFabric on VMware or vFabric on the other public cloud offerings.

vCloud

So, the other big announcement was on vCloud, specifically on vCloud director which seeks to provide a unified management layer. As we discussed, vCloud has its own API, and there are some concerns about maturity with respect to Amazon, and openness with respect to OpenStack.

The eye catching aspect of the vCloud announcement was the IT Service Management (ITSM) element, which starts to move vCloud ahead of the pack. It isn’t really new news, we trailed it in VMware + Ionix Assets – Impact Upon the Virtualization Management Market. The idea is that you can implement a service catalog (check out ITIL for a definition) that sits over your IaaS infrastructure, and that the business can interact with the Service Catalog to provision new services (rather than dealing with the underlying components of those services).

We are a long way from widely-deployed fully-functioning Service Catalog in most physical environments but there is no doubt IaaS makes it easier, and we had identified this component emerging across other IaaS plays. The key questions for vCloud Service Director are:

1. Is it complete, and if not from whom should one get the missing functionality. Reflex Systems, ManageIQ, Embotics, Hyper9, DynamicOps, Eucalyptus, and newScale all of private cloud management offerings that have substantial adoption among leading edge customers.  There was an announcement from newScale at VMworld on 24^th August (they must have arrived a week early to get a better deal on the hotel room) about the newScale Service Catalog running on Eucalyptus.
2. Will vCloud Director support the diversity of environments that most enterprises have (multiple virtualization platforms, and applications on both virtual and physical hardware)?
3. Will it be attractive to public cloud vendors as their provisioning stack, or will the public cloud vendors shy away from having a provisioning stack that makes them into a commodity vs everyone else.

For example, newScale is not feature-identical with vCloud Director, and in some ways sits a level above it,  On Eucalyptus it leverages rPath for automated provisioning.  It also has store front and governance layers that are not present in vSphere Director, and you can deploy newScale onto vSphere Director’s Service Catalog to provide these elements.