Cloud // Cloud Storage
08:00 AM
Rich Wolski
Rich Wolski

Why Cloud APIs Don't Matter

Rich Wolski, known for his work at Eucalyptus Systems, argues that architectural features that define how each cloud works are more important than a cloud's APIs.

Editor's note: This contributor argues that the services behind a cloud API are more important than the API itself. The author founded the open-source project that created APIs and services to match Amazon's. You may not agree, but in the end, he says, it is the success of the underlying services in attracting developers, who create applications to use them, that determines the real value of APIs. His firm, Eucalyptus Systems, is based on the same premise. Its software for private clouds generates services/APIs that closely mimic Amazon's.

There remains a healthy debate over the importance of APIs in the modern world of Web services and cloud computing. A while back, my peers Ben Black of Microsoft, Adrian Cole of Netflix, James Watters of Pivotal, and I were bantering back and forth on the subject. Eucalyptus CEO Marten Mickos does interviews about the subject in between debates with Cloudscaling founder and CTO Randy Bias. My computer science research group at the University of California, Santa Barbara, is even studying API governance as a new challenge facing modern IT managers.

With all of the importance that APIs seem to have garnered, I wish to make a controversial statement that I hope stimulates a healthy repartee among InformationWeek readers:

APIs do not matter, abstractions do.

Put another way, the API is simply the way to "talk" to software that implements a specific functional part of a cloud service or business. To make this functionality easier to use, faster to develop, and more robust, the software implements its functionality in terms of a logical abstraction.

For example, it is easier to talk SQL to a database system and get it to do what we want than it would be to talk directly to the CPU, disks, and network connections that underlie the database and tell them each in turn what we're trying to do. Thus a database is an abstraction that hides the complexity of a physical system. The database API lets applications manipulate this abstract system, but it's the quality of the database abstraction, not the quality of the API, that defines the reliability and benefit of the resulting services. The same is true for cloud services today.

[ A smarter way to run apps in the cloud? Read Containers Add New Efficiency To Cloud Computing. ]

When we started the Eucalyptus project, we knew we wanted Eucalyptus to be compatible with Amazon's AWS, but we didn't spend a lot of time initially trying to understand the APIs. In fact, at the time, AWS supported three different APIs -- REST, SOAP, and command line -- for exactly the same set of cloud services. That is, we focused on understanding the set of cloud abstractions we had to implement as one set of services and then built three different APIs for that set.

Not convinced that APIs and abstractions are different and that abstractions are what matter? When we started Eucalyptus as a company, several competitors claimed that they too supported the Amazon APIs. They had, in fact, read the AWS documentation and implemented the REST API calls that Amazon so carefully specifies. The only problem was that when a customer's application made these calls to AWS and then to one of these other competitor systems, the results that came back were different. That is, there were lots of implementations of the same API that ultimately worked differently, depending on how cloud service abstractions of the particular cloud were implemented.

So why should anyone care?

1 of 2
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
User Rank: Strategist
11/15/2013 | 12:12:38 PM
Are OpenStack, Amazon compatibility possible?
OpenStack underlying services have been designed to resemble those of Amazon Web Services. correct? If Rich Wolski is right, and I suspect he is, how hard would it be to modify a subset of OpenStack services to make them work in a way that's similar to Amazon's, if an OpenStack service supplier decided to do that? Perhaps the supplier would like Amazon S3 to serve as a compatible storage for backup or disaster recovery purposes. But the Swift storage service in OpenStack must do some things differently from S3, and any OpenStack provider that modifies Swift in his own setting must then maintain those changes through successive OpenStack releases. Ugh. You wouldn't do it that way, would you? How do you make OpenStack storage and S3 both available to an OpenStack user?  
<<   <   Page 2 / 2
Google in the Enterprise Survey
Google in the Enterprise Survey
There's no doubt Google has made headway into businesses: Just 28 percent discourage or ban use of its productivity ­products, and 69 percent cite Google Apps' good or excellent ­mobility. But progress could still stall: 59 percent of nonusers ­distrust the security of Google's cloud. Its data privacy is an open question, and 37 percent worry about integration.
Register for InformationWeek Newsletters
White Papers
Current Issue
Top IT Trends to Watch in Financial Services
IT pros at banks, investment houses, insurance companies, and other financial services organizations are focused on a range of issues, from peer-to-peer lending to cybersecurity to performance, agility, and compliance. It all matters.
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on for the week of July 17, 2016. We'll be talking with the editors and correspondents who brought you the top stories of the week to get the "story behind the story."
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.