Why Cloud APIs Don't Matter - InformationWeek
Cloud // Cloud Storage
08:00 AM
Rich Wolski
Rich Wolski
Faster, More Effective Response With Threat Intelligence & Orchestration Playboo
Aug 31, 2017
Finding ways to increase speed, accuracy, and efficiency when responding to threats should be the ...Read More>>

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
How Enterprises Are Attacking the IT Security Enterprise
How Enterprises Are Attacking the IT Security Enterprise
To learn more about what organizations are doing to tackle attacks and threats we surveyed a group of 300 IT and infosec professionals to find out what their biggest IT security challenges are and what they're doing to defend against today's threats. Download the report to see what they're saying.
Register for InformationWeek Newsletters
White Papers
Current Issue
IT Strategies to Conquer the Cloud
Chances are your organization is adopting cloud computing in one way or another -- or in multiple ways. Understanding the skills you need and how cloud affects IT operations and networking will help you adapt.
Twitter Feed
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.
Flash Poll