Cloud APIs are like military parades

The previous post (“Amazon proves that REST doesn’t matter for Cloud APIs”) attracted some interesting comments on the blog itself, on Hacker News and in a response post by Mike Pearce (where I assume the photo is supposed to represent me being an AWS fanboy). I failed to promptly follow-up on it and address the response, then the holidays came. But Mark Little was kind enough to pick the entry up for discussion on InfoQ yesterday which brought new readers and motivated me to write a follow-up.

Mark did a very good job at summarizing my point and he understood that I wasn’t talking about the value (or lack of value) of REST in general. Just about whether it is useful and important in the very narrow field of Cloud APIs. In that context at least, what seems to matter most is simplicity. And REST is not intrinsically simpler.

It isn’t a controversial statement in most places that RPC is easier than REST for developers performing simple tasks. But on the blogosphere I guess it needs to be argued.

Method calls is how normal developers write normal code. Doing it over the wire is the smallest change needed to invoke a remote API. The complexity with RPC has never been conceptual, it’s been in the plumbing. How do I serialize my method call and send it over? CORBA, RMI and SOAP tried to address that, none of them fully succeeded in keeping it simple and yet generic enough for the Internet. XML-RPC somehow (and unfortunately) got passed over in the process.

So what did AWS do? They pretty much solved that problem by using parameters in the URL as a dead-simple way to pass function parameters. And you get the response as an XML doc. In effect, it’s one-half of XML-RPC. Amazon did not invent this pattern. And the mechanism has some shortcomings. But it’s a pragmatic approach. You get the conceptual simplicity of RPC, without the need to agree on an RPC framework that tries to address way more than what you need. Good deal.

So, when Mike asksDoes the fact that AWS use their own implementation of an API instead of a standard like, oh, I don’t know, REST, frustrate developers who really don’t want to have to learn another method of communicating with AWS?” and goes on to answer “Yes”, I scratch my head. I’ve met many developers struggling to understand REST. I’ve never met a developer intimidated by RPC. As to the claim that REST is a “standard”, I’d like to read the spec. Please don’t point me to a PhD dissertation.

That being said, I am very aware that simplicity can come back to bite you, when it’s not just simple but simplistic and the task at hand demands more. Andrew Wahbe hit the nail on the head in a comment on my original post:

Exposing an API for a unique service offered by a single vendor is not going to get much benefit from being RESTful.

Revisit the issue when you are trying to get a single client to work across a wide range of cloud APIs offered by different vendors; I’m willing to bet that REST would help a lot there. If this never happens — the industry decides that a custom client for each Cloud API is sufficient (e.g. not enough offerings on the market, or whatever), then REST may never be needed.

Andrew has the right perspective. The usage patterns for Cloud APIs may evolve to the point where the benefits of following the rules of REST become compelling. I just don’t think we’re there and frankly I am not holding my breath. There are lots of functional improvements needed in Cloud services before the burning issue becomes one of orchestrating between Cloud providers. And while a shared RESTful API would be the easiest to orchestrate, a shared RPC API will still be very reasonably manageable. The issue will mostly be one of shared semantics more than protocol.

Mike’s second retort was that it was illogical for me to say that software developers are mostly isolated from REST because they use Cloud libraries. Aren’t these libraries written by developers? What about these, he asks. Well, one of them, Boto‘s Mitch Garnaat left a comment:

Good post. The vast majority of AWS (or any cloud provider’s) users never see the API. They interact through language libraries or via web-based client apps. So, the only people who really care are RESTafarians, and library developers (like me).

Perhaps it’s possible to have an API that’s so bad it prevents people from using it but the AWS Query API is no where near that bad. It’s fairly consistent and pretty easy to code to. It’s just not REST.

Yup. If REST is the goal, then this API doesn’t reach it. If usefulness is the goal, then it does just fine.

Mike’s third retort was to take issue with that statement I made:

The Rackspace people are technically right when they point out the benefits of their API compared to Amazon’s. But it’s a rounding error compared to the innovation, pragmatism and frequency of iteration that distinguishes the services provided by Amazon. It’s the content that matters.

Mike thinks that

If Rackspace are ‘technically’ right, then they’re right. There’s no gray area. Morally, they’re also right and mentally, physically and spiritually, they’re right.

Sure. They’re technically, mentally, physically and spiritually right. They may even be legally, ethically, metaphysically and scientifically right. Amazon is only practically right.

This is not a ding on Rackspace. They’ll have to compete with Amazon on service (and price), not on API, as they well know and as they are doing. But they are racing against a fast horse.

More generally, the debate about how much the technical merits of an API matters (beyond the point where it gets the job done) is a recurring one. I am talking as a recovering over-engineer.

In a post almost a year ago, James Watters declared that it matters. Mitch Garnaat weighed on the other side: given how few people use the raw API we probably spend too much time worrying about details, maybe we worry too much about aesthetics, I still wonder whether we obsess over the details of the API’s a bit too much (in case you can’t tell, I’m a big fan of Mitch).

Speaking of people I admire, Shlomo Swidler (in general, only library developers use the raw HTTP. Everyone else uses a library) and Joe Arnold (library integration (fog / jclouds / libcloud) is more important for new #IaaS providers than an API) make the right point. Rather than spending hours obsessing about the finer points of your API, spend the time writing love letters to Mitch and Adrian so they support you in their libraries (also, allocate less of your design time to RESTfulness and more to the less glamorous subject of error handling).

OK, I’ll pile on two more expert testimonies. Righscale’s Thorsten von Eicken (the API itself is more a programming exercise than a fundamental issue, it’s the semantics of the resources behind the API that really matter) and F5’s Lori MacVittie (the World Doesn’t Care About APIs).

Bottom line, I see APIs a bit like military parades. Soldiers know better than to walk in tight formation, wearing bright colors and to the sound of fanfare into the battlefield. So why are parade exercises so prevalent in all armies? My guess is that they are used to impress potential enemies, reassure citizens and reflect on the strength of the country’s leaders. But military parades are also a way to ensure internal discipline. You may not need to use parade moves on the battlefield, but the fact that the unit is disciplined enough to perform them means they are also disciplined enough for the tasks that matter. Let’s focus on that angle for Cloud APIs. If your RPC API is consistent enough that its underlying model could be used as the basis for a REST API, you’re probably fine. You don’t need the drum rolls, stiff steps and the silly hats. And no need to salute either.


Filed under Amazon, API, Automation, Cloud Computing, Everything, IT Systems Mgmt, Mgmt integration, Protocols, REST, Specs, Utility computing

15 Responses to Cloud APIs are like military parades

  1. John

    I’m surprised there was no mention of OCCI ( They are working very hard to establish a cloud standards API.

  2. Pingback: Cloud APIs are like military parades

  3. “The issue will mostly be one of shared semantics more than protocol.” Please elaborate!!! (Because I think there are some very interesting discussion points buried in that statement.)

  4. Andrew,

    Basically that the main issue with regards to going across Cloud is modeling in a consistent way the capabilities of the Cloud infrastructure. At the IaaS level, a VM is a VM until you get to the point where you realize that providers don’t support the same number of NICs, the same storage mounting options, etc…

    At the PaaS level, go ahead and try to deploy across Beanstalk, CloudBees and GAE (the Java version). I can guarantee that the issue won’t be that their APIs look different (that’s easily abstracted). Rather, it’s that their Java runtimes behave differently and support different services.

    That’s what I mean.

    You’re right that this would be worth a separate discussion. I’ve touched on it in previous posts (e.g. the “post-mortem on the previous IT management revolution” in which I lament wasting time on throw-away protocol rather than re-usable modeling and “separating model from protocol in Cloud APIs”) but I have never fully articulated and illustrated the issue. Lots of others are well aware of the issue (e.g. Thorsten von Eicken in the quote from him I put in the post above) but I don’t remember a single write-up by anyone that crisply captures it in details.

  5. Pingback: Jan. 25: What We’re Reading About the Cloud: Cloud Computing News «

  6. Pingback: William Vambenepe — The REST bubble

  7. The RPC versus REST debate is not a big deal for practising programmers. The problem is SOAP (and its precursor CORBA) which is hugely over complicated to the point that it requires heavy-duty tooling (e.g. the elephantine Visual Studio) to use it.

    REST APIs are simple enough that lightweight libraries invariably appear in PHP, Ruby, Python and C# as soon as the API is released. This has a huge impact on developer acceptance and thus the adoption rate—especially for mass-market services whether they be Facebook or Salesforce. Note that latter’s about-face from SOAP to REST over the last year or so as evidence of this.

  8. Pingback: You Are Like

  9. One of the Web principles I like the most is the Principle of Least Power: . By the PLP, if a URL-encoded-RPC approach is powerful enough to meet the needs of interacting with AWS services, then it should be preferred over a more powerful REST approach.

    Hearing someone complain that REST should be used instead of RPC is like hearing someone complain that a context free grammar should be applied to a problem instead of a regular expression grammar. If the regular expression grammar is powerful enough for current and foreseeable uses, then by the PLP it should be used.

  10. Pingback: Should Cloud APIs Focus on Client Libraries More Than Endpoints?

  11. Pingback: William Vambenepe — The API, the whole API and nothing but the API

  12. Stu

    This is well said. The whole ECML/EDML experience at Elastra was IMO one big exercise in “we’re not there yet”.

    Having said that, I still think IT management as a whole (including cloud in that) is long due for getting away from flipping switches and reading LEDs with RPC’s and into exchanging documents, thus the Web becomes both your API and the basis of your config management system at the same time. But at this point, most are just trying to ship something, anything, to keep up with the pace of the market.

    Regarding the “discipline” theme at the end of your post: Many API’s are really, really poor because they’re unconstrained, undisciplined. It’s pretty unique (and refreshing) to find even a library API with great internal consistency. The good (i.e. usable / decent performance) RPC APIs shipped were built by experts who’ve delivered at least one shitty DCE RPC, COM, CORBA, or SOAP system and learned the gotchas along the way. I wonder if thinking in terms of resources, representations & a uniform interface at least forces regular devs to take the network and interoperability into account. We have had much “unlearning” to do in industry as the network has become pervasive – the protocol is not about what the server developer wants, it’s supposed to be about what the client wants, since there are so many more of them. Amusingly, the rise of REST-as-preferred-networked-architecture-style has arguably improved the quality of RPCish APIs quite a bit, by forcing people to think.

  13. We no longer live in a server-centric world. The main benefit of REST is it’s ability to be easily consumed by browser or server-side applications.

    Browser engines (like Google’s V8) can only communicate using HTTP verbs, paths, and unique IDs.

  14. Pingback: Should Cloud APIs Focus on Client Libraries More Than Endpoints? | Phil Leggetter - Real-Time Web Software and Technology Evangelist

  15. Pingback: Lessons Learned from Using Multiple Cloud APIs