The power of abstraction
It is the design of the abstractions (the logical function of the cloud services) and not the APIs that result in desirable properties such as scale, resilience, and secure self-service. For instance, in most clouds it is not possible to specify on which specific machine a virtual machine (VM) should be launched. The abstraction says that a VM will exist sometime after the run command is issued (or an error will be reported), but no indication of where the VM is residing will be provided.
The reason for this formulation is so that the cloud can use eventual consistency to achieve scale. Since the user cannot specify where the VM is to run, the cloud can delay the decision (a process called delayed binding) as long as possible. As a result, a specific "slot" for the VM does not need to be reserved (e.g., a lock is avoided) allowing the system to respond to as many requests simultaneously as possible.
Notice that this abstraction property holds no matter what the API's properties might be. For example, the API might be synchronous or asynchronous -- that is, it may be that the user command waits until the VM start request is completely fulfilled or the user is allowed to continue and must check back from time to time (as in the AWS API) to determine when the VM is ready for use.
Note also that it is possible for a bad API to mask the useful properties of a good abstraction. Consider all of the graphical management dashboards that require individual IP addresses to be entered instead of a range. This API does not work at scale due to the possibility of data entry error and the time required.
Thus APIs actually do matter, but they matter for a different reason. The APIs must make the cloud services facile but it is the services themselves and not the APIs that matter when it comes to the question of cloud interoperability.
If only it were that simple
Some of the Cloud cognoscenti have, from time to time, argued about the need for this cloud to support that API in service of cloud interoperability. Randy Bias of CloudScaling and other OpenStack contributors who support his point of view have argued that OpenStack should support the AWS APIs. If only the problem were that simple.
A direct API translation is possible if the underlying abstractions are the same. If they are not, then bolting the same API onto a different abstraction will yield different behavior from the same set of commands. From an application perspective, this has serious consequences. If the APIs look the same but the cloud services yield different results, it is difficult to move an application from one cloud to another and still know what's going to happen at the application level.
Thus, debates about one cloud supplier "adopting an API" from another cloud supplier are usually arguments about whether it's necessary to re-engineer that supplier's underlying abstractions.
So how different are they?
The good news for cloud interoperability is that the core abstractions implemented by different IaaS clouds are similar. This begs the question, "If two clouds with different abstractions are to interoperate, how much effort is required to refactor their internal services before applications do not see a difference?"
I wish I knew. However, until the true source of cloud incompatibility shifts from a discussion of APIs to a discussion of service abstractions, I fear we will not make much progress toward an understanding.
Developers, however, vote with their apps. When enough developers vote for an API and interoperability, a de facto standard emerges, and other clouds have the option of changing to adopt it. Even so, real interoperability will require that their internal service abstractions to be the same, not just the APIs.
Debating the real issues
It is possible for clouds to implement application portability. However, achieving this goal requires more than a debate over cloud APIs. The community needs to develop an understanding of the architectural features that define how each cloud works -- that is, the cloud abstractions -- and to debate which architectural features are both feasible and essential.
Despite the discourse on APIs that has taken place, with its heroes and villains, the real debate over how to make cloud computing a universal platform has not yet begun.
Want to relegate cloud software to edge apps or smaller businesses? No way. Also in the new, all-digital Cloud Software: Where Next? special issue of InformationWeek: The tech industry is rife with over-the-top, groundless predictions and estimates. (Free registration required.)