You probably heard about the most recent episode of “AWS API in Openstack” saga. If you haven’t, head over to Nati Shalom's blog to read one of the best recaps I have seen.
My personal position in this discussion is very simple. I am not saying Openstack should fully adopt AWS API, nor am I saying Openstack should not fully adopt AWS API. What I am saying is which API is presented doesn’t matter, as long as API exists and remains stable, with reasonable version management (so that developers can write against it easily). And I am not alone. Just give us a reasonable API, everything else doesn’t matter.
Ideological footing for the viewpoint that Openstack should just adopt AWS APIs can be traced to works of Simon Wardley. Simon was the first to introduce cloud computing community to several important concepts from science, he is a well established thought leader in information technology widely followed by both cloud pundits and practitioners.
As part of the recent debate, Simon wrote a post titled The 'Innovation' Battle, in which he says in part:
[...] innovation is not about the interface but should be above and below the interface.
[...] [others] believe that innovation of the interface is paramount. They believe that what matters is the interface, they hence strongly oppose adoption of AWS APIs.
In this post, I would like to expose a flaw in Simon’s logic and convince you that both camps in API debate are actually in line with Simon’s guiding principle that innovation of the interface doesn’t matter.
What is an interface?
First, let’s think of what an interface is, in most general terms. Interface is a set of behaviors and intended use cases that something provides and adheres to. When 2 things provide same or very similar interface, they become interchangeable. Over time, as the number of things providing same or similar interface grows and interface itself is refined (gains new desired behaviors based on feedback and observations, gets rid of behaviors that customers found unnecessary), it becomes a commodity.
Take a regular automobile. What is the interface of a car, in most general terms? It consists of several behaviors. One has to have a way to get situated in a seating position in front of a steering wheel and instrument dashboard. One has to have a way to get a car to move forward, back, turn and stop. One has to have a way to see what’s behind a car. You could go further and say that over time car interface gained expectations of ability to steer with hands and brake and accelerate with feet. Maybe ability to listen to music on your iPhone is a must now - interfaces do evolve.
These are all general things that one expects from a car and that allow most people to operate any car of roughly the same size without too much difficulty or a user manual. This is car’s interface.
What’s the interface of IaaS cloud? In most general terms, it’s ability to programmatically request a running OS image (we now call it an instance), uniquely identifiable and addressible, connected to a specified network, with ability to stop it.
Now on to a key point. Try to think through historical evolution of cloud - from the first version of Amazon EC2 to other IaaS clouds to newer versions to EC2. Has the generic IaaS interface changed in any significant way? Not really - no one is innovating in the interface any more because a lot of interesting work there has already been done. Even mighty Google who came out with their IaaS cloud last year, haven’t done any significant innovation in the interface (this doesn’t mean they haven’t innovated in other areas which are more important to customers).
Interfaces don’t expand simply because vendors want to sell more things - interfaces evolve only when customers are actually using new behaviors and functionality.
API as Implementation of the Interface
Even though all car manufacturers implement the same interface, their implementations are all different. Doors can open to the side or up. Door handles could be flush or not. Same controls could sometimes be knobs or buttons. Steering wheels’ diameter is different. Controls signage is different.
Have you thought about why car manufacturers haven’t converged to a single implementation of the interface? I have. Because customers want differentiation and customers don’t mind the differences in what looks to them like details.
Similarly, IaaS API is implementation of the general interface. Order of parameters, POST or GET or PUT for API calls, details how to sign your request, instance ids hex with an “i-” in front or numeric, public IP address as NAT or directly on network interface. The list could go on and on and you can name tons of these little differences if you had a chance to work with many clouds (not merely talk about many clouds but actually write code that uses many clouds).
These details don’t matter to most developers (and every developer I have personally spoken to), just like whether windshield wipers are turned on by pushing lever up or down doesn’t matter to most car drivers.
I think Simon is correct to point out that innovation should be happening outside of the interface. And it is. But his assumption that generic interface to an IaaS cloud and API are one thing is flawed - they are not, and cloud is not the only commodity where this is evident, as I showed above. API is an implementation of the interface. Nobody is innovating in generic interface anymore on a large scale - the feature set is pretty solid shaped by current capabilities of available technologies.
One can very well believe that Openstack would be better off adopting AWS APIs but it can’t be solely because of Simon’s “innovation of the interface” argument.