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 can not agree, but in any case, he says, it’s the success of the underlying services in attracting developers, who create applications to make use of 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. ages back, my peers Ben Black of Microsoft, Adrian Cole of Netflix, James Watters of Pivotal, and that i were bantering from side to side 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 all the importance that APIs appear to have garnered, I would like to make a controversial statement that i am hoping stimulates a healthy repartee among InformationWeek readers:
APIs don’t matter, abstractions do.
Put otherwise, the API is solely the right way to “talk” to software that implements a particular functional a part of a cloud service or business. To make this functionality easier to make use of, faster to develop, and more robust, the software implements its functionality with regards to a logical abstraction.
For example, it’s easier to speak SQL to a database system and get it to do what we would like than it might 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 good thing about the resulting services. An analogous is correct for cloud services today.
[ a better 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 looking to understand the APIs. Basically, on the time, AWS supported three different APIs — REST, SOAP, and command line — for the exact same set of cloud services. That’s, we interested in 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 corporation, several competitors claimed that they too supported the Amazon APIs. They’d, in truth, read the AWS documentation and implemented remainder API calls that Amazon so carefully specifies. The only real problem was that after a customer’s application made these calls to AWS after which to at least one of those other competitor systems, the outcomes that came back were different. That’s, there have been a variety of implementations of the identical API that ultimately worked differently, looking on how cloud service abstractions of the actual cloud were implemented.
So why should anyone care?
More Insights