Lydia Leong

A member of the Gartner Blog Network

Lydia Leong
Research VP
11 years at Gartner
19 years IT industry

Lydia Leong is a research vice president in the Technology and Service Providers group at Gartner. Her primary research focus is cloud computing, together with Internet infrastructure services, such as Web hosting, content delivery networks…Read Full Bio

Coverage Areas:

Are multiple cloud APIs bad?

by Lydia Leong  |  August 27, 2009  |  3 Comments

Rackspace has recently launched a community portal called Cloud Tools, showcasing third-party tools that support Rackspace’s cloud compute and storage services. The tools are divided into “featured” and “community”. Featured tools are ones that Rackspace has looked at and believes deserve highlighting; they’re not necessarily commercial projects, but Rackspace does have formal relationships with the developers. Community tools are fro any random joe out there who’d like to be listed. The featured tools get a lot more bells and whistles.

While this is a good move for Rackspace, it’s not ground-breaking stuff, although the portal is notable for a design that seems more consumer-friendly (by contrast with Amazon’s highly text-dense, spartan partner listings). Rather, what’s interesting is Rackspace’s ongoing (successful) efforts to encourage an ecosystem to develop around its cloud APIs, and the broader question of cloud API standardization, “de facto” standards, and similar issues.

There are no small number of cloud advocates out there that believe that rapid standardization in the industry would be advantageous, and that Amazon’s S3 and EC2 APIs, as the APIs with the greatest current adoption and broadest tools support, should be adopted as a de facto standard. Indeed, some cloud-enablement packages, like Eucalyptus, have adopted Amazon’s APIs — and will probably run into API dilemmas as they evolve, as private cloud implementations will be different than public ones, leading to inherent API differences, and a commitment to API compatibility means that you don’t fully control your own feature roadmap. There’s something to be said for compatibility, certainly. Compatibility drives commoditization, which would theoretically lower prices and deliver benefits to end-users.

However, I believe that it’s too early in the market to seek commoditization. Universal commitment to a particular API at this point clamps standardized functionality within a least-common-denominator range, and it restricts the implementation possibilities, to the detriment of innovation. As long as there is rapid innovation and the market continues to offer a slew of new features — something which I anticipate will continue at least through the end of 2011 and likely beyond — standardization is going to be of highly limited benefit.

Rackspace’s API is different than Amazon’s because Rackspace has taken some different fundamental approaches, especially with regard to the network. For another example of significant API differences, compare EMC’s Atmos API to Amazon’s S3 API. Storage is a pretty simple thing, but there are nevertheless meaningful differences in the APIs, reflecting EMC’s different philosophy and approach. (As a sideline, you might find William Vambenepe’s comparison of public cloud APIs in the context of REST, to be an interesting read.)

Everyone can agree on a certain set of core cloud concepts, and I expect that we’ll see libraries that provide unified API access to different underlying clouds; for instance, libcloud (for Python) is the beginning of one such effort. And, of course, third parties like RightScale specialize in providing unified interfaces to multiple clouds.

One thing to keep in mind: Most of the cloud APIs to date are really easy to work with. This means that if you have a tool that supports one API, it’s not terribly hard or time-consuming to make it support another API, assuming that you’re confining yourself to basic functionality.

There’s certainly something to be said in favor of other cloud providers offering an API compatibility layer for basic EC2 and S3 functionality, to satisfy customer demand for such. This also seems to be the kind of thing that’s readily executed as a third-party library, though.

3 Comments »

Category: Infrastructure     Tags: , , ,

3 responses so far ↓

  • 1 Andy   August 28, 2009 at 2:23 am

    I think Amazon S3 API is becoming a standard as many cloud storage providers such as Sun and Eucalyptus support it. There are a lot more smaller storage vendors who also offer S3 API support.

  • 2 Steve Lesem   August 28, 2009 at 6:55 am

    I could not agree with you more. Current REST APIs are more of a reflection of the underlying storage cloud technology versus the need to have REST API conformance that strongly supports required functionality. Further , some API differentiation simply reflects specific cloud features and functions. Two quick thoughts: API “change out” effort is often outweighed by the perceived benefits of the alternative supplier; and most likely we will quickly arrive at base functionality with highly similar APIs, with particular storage cloud advanced functions being where the APIs will differ the most. Steve

  • 3 Do we need Cloud API Standards ? « The "Present" I live in   October 24, 2009 at 7:24 am

    [...] “Are Multiple Cloud APIs Bad ?” – Lydia Leong (from Gartner) wonders if the standard should be around already popular Amazon’s S3 and EC2 API.   Also brings about an important point (which I would talk about further below) that Rackspace API is different from Amazon because Rackspace has taken some fundamentally different approacheses. [...]