OWS, Amazon and the Value of an API
People like to use new technology as a metaphor and API seems to be bubbling up as a good choice. Here’s Alexis Madrigal on Occupy Wall Street as an API:
What an API does, in essence, is make it easy for the information a service contains to be integrated with the wider Internet. So, to make the metaphor here clear, Occupy Wall Street today can be seen like the early days of Twitter.com. Nearly everyone accessed Twitter information through clients developed by people outside the Twitter HQ. These co-developers made Twitter vastly more useful by adding their own ideas to the basic functionality of the social network. These developers dont have to take in all of OWS data or use all of the strategies developed at OWS. Instead, they can choose the most useful information streams for their own individual applications i.e. occupations, memes, websites, essays, policy papers.
I find the examples he uses after this paragraph a bit tenuous, but I really like the API metaphor in this example and generally. It’s a simple way to understand how distributed systems functions. (Franchising, for example, was essentially an API before people were talking much about APIs.)
What happens, though, when you take it further like Amazon did? Essentially the company decided that everything must be an API: No functionality produced could exist without being a simple service that any other group in the company could reach. It was probably best explained in an accidental Google+ post by a Google engineer a few weeks ago who used to work at Amazon. Here he explains Jeff Bezos’s service mandate:
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6) Anyone who doesn’t do this will be fired.
7) Thank you; have a nice day!
What happened next was pretty amazing. After building all these services Amazon started exposing them all publicly. In designing their company around APIs they actually discovered a second business (Amazon Web Services) that they are dominating. In essence the act of simplifying the company down to a set of service calls helped them see where their greatest strengths lay. It’s an interesting approach and one I can only assume we’ll see more companies follow.