Entries in IaaS (6)


Infrastructure (-aaS) goes to war


Among the most interesting developments in the business of IaaS during the past few months has been the rather dramatic ways in which the players have been throwing down guantlets.  Some notable examples:

  • The incumbent AWS, in Andy Jassy's recent AWS Summit presentation, has diss'd private cloud as "false cloud" 
  • Turning the beam to illuminate their position with respect to other infrastructure services, AWS has a point to showcase their record of continual price reductions while delivering just-in-time functionality to its community of customers when compared to other IaaS offerings.
  • The new aspirants GCE and VMware vCloud Hybrid Service have made clear their intention to appeal to their constituents -- the cutting edge development communities in need of almost unheard of scale in the case of Google, and the enterprise in search of the promises of hybrid clouds in the case of VMware
  • Rackspace and Joyent have revised their pricings, while accompanying the announcements with functional additions or the promise ('real soon now') of functionality and service level assurances to their customers and customers-to-be.

Like many other observers of the cloud services industry, I've made comments that include the terms 'commoditization' and 'race to the bottom.'  But in looking at historical analogs, I am coming to the conclusion that there are other ways to interpret the situation in IaaS, and consider possible outcomes other than an eventual oligopoly of the 'Big Three.'

In the upcoming series of blog posts, I hope to take selectively from the economic history of the steel industry and the airline industry to point out how the cloud infrastructure industry's 'future history' might play out.  An analyst and observer of industries is always at risk when predicting the future -- so I won't.  But I will point out some similarities to major techno-industrial disruptions, the tactics and strategies of competition, and their resulting successes and failures.  

I welcome reaction, commentary, alternative interpretation, but please... no name-calling. 


VMworld 2009 and the vCloud API

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.


Page 1 2