Why Cloud APIs Don't Matter

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