I have been looking at Amazon EC2. It is a fascinating service. It is quite a thrill to fire up your own linux instances in the cloud the first time. The fun wears off after a bit because linux instances are quite boring on their own. I am sure designing a web application server infrastructure in the cloud will be a lot more fun. So, I started taking baby steps towards that, which involves staring at their HTTP query API.

The EC2 query API, unlike the S3 API is quite un-RESTful. HTTP GET is overloaded and is neither safe nor idempotent. All requests take a list of query parameters, the first parameter is called Action. Most of the other query parameters are arguments to the Action. The remaining are query parameters to deal authentication and non-repudiation. GET is the only HTTP verb used. The three most common actions I used were start, stop and status.

The two primary nouns in the EC2 vocabulary are images and instances. Images are the bits that make up the Xen virtual instance. Instances are runtime instantiations of images. An operation like getStatus() can be intuitively modeled as a GET on an instance resource. However, I got stuck on modeling start and stop.

I then consulted with a REST expert, he suggested that I think of a start as a POST to list of instances and a stop as a DELETE on an instance. An excellent suggestion, although there is a part of me (the dumb part) that feels that this not terribly intuitive. Although it seems to frowned upon, I actually prefer tunneling RPC calls through POSTs. It gives me more latitude to model my rpc’ish calls with a POST and my entity calls with all the verbs. Which leads to me wonder why EC2 did not use POST instead of GET, wouldn’t they have the REST stamp of approval ?

For now, I am sticking with a purist REST interface. Here is my REST table.

I used ProjectZero to build this out. The code is in an early alpha state in a branch. I checked in the code to https://www.projectzero.org/svn/zero/branches/p_sr_amazonec2. Prior registration on the ProjectZero site is required.

I have been working on Project Zero for the last year. The project is an incubator and is still in its early stages.

Disclaimer – the views expressed on this blog are mine and mine alone, they do not reflect the views the Project Zero team.

As with all software projects in their early stages, things changed at a frenetic pace at one point. However, the two things that were most important to me throughout were the adoption of dynamic languages on the JVM and REST. On most days I think using Java as a systems programming language in combination with a dynamic scripting language (like Groovy or PHP) makes a lot of sense. On other days, I think the Java bubble is a strange entity and whether the bubble tax is worth it. For reasons I still do not understand, Java has been very successful in the Enterprise and the practical side of me says dynamic languages on the JVM are a fantastic idea. In any case, with proper API design (hard problem), small scripts written in a dynamic language can achieve a lot. Whether you call them little languages or DSLs or glue code, there are significant productivity gains that can be achieved using them.

My affection for REST is partly based on the shock and awe approach taken by WS-*. I see REST as a set of organizing principles that constrain how I think about the server side of a web application (the client side is still a big mess). I like constraints in thinking about software, especially constraints other smart folks have put a lot of thought into. Now, REST might be a little too constraining, since I frequently have to seek out REST Jedi like Joe to feel the force. I will describe more about this in future posts.

The project has been a great learning experience for me. I get to work with a lot of interesting pieces of technology. The one big lesson though – the biggest challenges in software are on the business side. Translating cool technology ideas into dollars is the hardest problem. One solution of course is a network driven, community and folksonomy based ad revenue model, but that one seems to be getting tapped out.