The competition to claim the IaaS crown for enterprise computing has seen a major set of interesting events this week. As mentioned in this post (and its update) on Citrix and Xen.org, their preemptive announcement has a lot of people paying attention. Clearly, the industry expected something major to come from VMware's VMworld2009 conference this week, and they were not disappointed.
On Monday, VMware detailed the vCloud API in an open session. It's come as a mostly pleasant surprise. The API is closely associated with the DMTF's OVF/OVA standards, relying heavily on OVF/OVA as the means of representation and description of the virtualized solutions. Some initial reactions, based on an admittedly superficial review: (I reserve the right to add to this, and reverse myself on any of these pronouncements.)
- There are questions in my mind about the the model's use of a template to specify requirements that is obviously VMware's vApp. (I suppose that it would be too selfless of VMware to take any other tack.)
- The vCloud API leaves a lot of the networking specification and semantics required by a solution to be defined by the service provider in a proprietary manner. That is, for the networking aspects, the means by which connectivity and security (e.g. firewall rules) are to be provided by the network infrastructure are individually defined by the service vendor that's supporting the vCloud API.
[Geek alert] Apparently, when a network resource request is expressed by the (vApp) template, the IaaS provider can return an existing network or dynamically generate a new one that meets the requirements of the request. However, the network resource name that's returned implies provider-specific semantics. This effectively diminishes the out-of-the-box portability of solutions that rely on vCloud API. [End geek alert]
From first reading and reviews by people I respect (such as William Vambenepe and Rich Pelavin, co-founder of Replicate Technologies) the vCloud API 'does the right things,' on most of the points where it is definitive. There are clearly aspects of the specification that had to be left for further refinement. There's a slightly 'hurried' aspect to the spec, but I believe we should be thankful that they did not feel compelled to do everying in the first go-round, thereby making a mess that has to be cleaned up later.
What's interesting to me is the approach they've now taken with respect to making vCloud API 'the standard.' Coincident with it's release to the public, VMware has submitted the vCloud API Specification to the DMTF for the purpose of making it the Cloud API standard. VMware has found real value in its participation in DMTF over the past few years. Both the quality and general support of OVF/OVA as a DMTF standard proves out the upside to this standardization strategy. Immediate submission of the spec to DMTF is in stark contrast to the approach adopted by Amazon Web Services, which has published the details, but has kept it in a somewhat nebulous (if you'll pardon the expression) legal status. As Sam Johnston (@samj) points out in this post to the CCIF group, the intellectual property issues related to EC2's API are pointedly going in another direction, with specific restrictions to use of the API only with Amazon's own services and patents pending that relate to the API.
So, what about the commercial impact on the services industry? At a special event held yesterday at VMworld 2009, Paul Maritz made the claim that over a thousand service providers are now in position to offer VMware-ready cloud services, based on the vCloud API. Quick to reiterate that message, companies like AT&T, Savvis, Verizon Business, Terremark, Bluelock, Hosting.com, Logica and Melbourne IT announced immediate (or real-soon-now) launches of services under the VMware vCloud (TM) Express program. Software companies building on the vCloud API that announced include Aptana, Cloudera, CollabNet, CohesiveFT, EngineYard, ParAccel, RightScale, rPath, SpringSource, Terracotta, TIBCO, and Zend. Whew.
So, does having this kind of support mean that VMware is the winner as the basis for enterprise use of cloud services? Not yet. It's way too early to tell. At this point, we need to watch the players take the field and start the competition. Let's just see what enterprise users actually use, and for what purposes. To my mind, the place to focus is on the software companies. To the degree that cloud applications get built using the vCloud API as the approach of choice, that will be the measure of real leadership in this market.