Rich Wolski, known for his work at Eucalyptus Systems, argues that architectural features that outline 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 writer founded the open-source project that created APIs and services to compare Amazon’s. You might not agree, but in due course, he says, it’s the success of the underlying services in attracting developers, who create applications to exploit them, that determines the actual value of APIs. His firm, Eucalyptus Systems, is predicated at the same premise. Its software for personal clouds generates services/APIs that closely mimic Amazon’s.
There remains a healthy debate over the significance of APIs within the modern world of Web services and cloud computing. some time back, my peers Ben Black of Microsoft, Adrian Cole of Netflix, James Watters of Pivotal, and that i were bantering backward and forward at the subject. Eucalyptus CEO Marten Mickos does interviews concerning the subject in between debates with Cloudscaling founder and CTO Randy Bias. My computer science research group on the University of California, Santa Barbara, is even studying API governance as a brand new challenge facing modern IT managers.
With the entire importance that APIs appear to have garnered, I desire to make a controversial statement that i’m hoping stimulates a healthy repartee among InformationWeek readers:
APIs don’t matter, abstractions do.
Put in a different way, the API is just methods to “talk” to software that implements a selected functional a part of a cloud service or business. To make this functionality easier to apply, faster to develop, and more robust, the software implements its functionality in the case of a logical abstraction.
For example, it’s easier to chat SQL to a database system and get it to do what we wish than it’d be to speak on to the CPU, disks, and network connections that underlie the database and tell them each in turn what we’re attempting 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 is the quality of the database abstraction, not the standard of the API, that defines the reliability and advantage of the resulting services. An identical is right for cloud services today.
[ a wiser option to run apps within the cloud? Read Containers Add New Efficiency To Cloud Computing. ]
When we started the Eucalyptus project, we knew we needed Eucalyptus to be compatible with Amazon’s AWS, but we didn’t spend lots of time initially attempting to understand the APIs. In reality, on the time, AWS supported three different APIs — REST, SOAP, and command line — for the exact same set of cloud services. That’s, we thinking about understanding the set of cloud abstractions we needed to implement as one set of services after which built three different APIs for that set.
Not convinced that APIs and abstractions are different and that abstractions are what matter? Once we started Eucalyptus as a firm, several competitors claimed that they too supported the Amazon APIs. They’d, as a matter of fact, read the AWS documentation and implemented remainder API calls that Amazon so carefully specifies. The best problem was that once a customer’s application made these calls to AWS after which to at least one of those other competitor systems, the consequences that came back were different. It’s, there have been a great number of implementations of an identical API that ultimately worked differently, counting on how cloud service abstractions of the actual cloud were implemented.
So why should anyone care?
More Insights