This One Time, At Cloud Camp…

Walt and myself recently attended a fun little “unconference”, Cloud Camp, hosted at Amazon’s AWS campus and organized by Dave Nielsen, its founder. Firstly, it was quite remarkable how successful Cloud Camp has become, with at least several taking place on every continent (I’m counting Antarctica too, they’ve got Internet, don’t they?). In his opening of the unconference Dave presented the always controversial question: what is the definition of cloud computing? His answer: OSSM!

On-demand

Self-service

Scalable

Magical pony glitter and rainbow sparkles!

(Walt reports I may have that last one wrong and was probably something more like “Multi-tenant”)

After Dave’s short opening we were treated to a series of lightning-talks, 5 minutes a piece. The talks were fairly marketing driven but for a few. The most dynamic speaker was Margaret Dawson, VP of Marketing at Hubspan, whom I believe had the most succinct definition of cloud computing: a revolutionary new consumption model of computing resources. There was another great presentation from Amazon’s own Steve Riley, a senior technical program manager, discussing security in the cloud. He had some interesting insights about classical notions of computer security, in particular how many organizations strongly correlate security with physical possession of the respective hardware resources, yet do not hesitate to transmit data over the Internet when it can be argued no single entity owns or possesses it. There was a related presentation from the software developer of a financial portfolio management firm, highlighting the psychological difficulties of getting people to trust their data in the cloud and the tactics entailed to move an organization and its customers in that direction; to wit: incrementalism. Google and Microsoft did their spiel, nothing all that interesting or new coming from Google although Microsoft seemed very aggressive about strengthening their enterprise relevancy in the market, presenting their new 2010 November Azure release.

Oh yeah, IBM presented too, they want you to buy something.

Shortly after the talks we went into “unconference-mode”, whereupon Dave polled the audience to come up with ideas for several group discussions. Ultimately the following discussion groups were agreed upon:

Google App Engine

Cloud API’s

Personal Projects in the Cloud

Low-Latency Applications in the Cloud

Microsoft Azure

The discussion groups were 30 minutes a piece, 3 in parallel and back-to-back so we could all at least attend 2. Walt and I attended the Low-Latency and Personal Projects discussions, of which I will only comment on the former due to it’s highly technical nature.

Likely the most tech-heavy session, the Low-Latency discussion began with a standing question of what kind of caching techniques are being used to generally decrease latencies. I brought up the benefit of memcache and its use in our highly-scalable Linkscape API product. I also pointed out that it’s an effective multi-tier caching solution, reducing latencies in both the front and back-end. The discussion quickly became focused on the capricious nature of I/O latency in multi-tenant architectures and how best to avoid it. The consensus was simply just don’t do it (unless you have to). There were some horror stories thrown about concerning network bandwidth issues at Amazon. Someone providing anecdotes about such a situation decided to move to Rackspace to ameliorate their network latency issues (however I have to wonder if they did not prematurely do so), sharing that the move did ultimately improve application responsiveness. Two primary conclusions that came from this session:

It’s I/O latency that breaks applications in the cloud. Naive porting of standard server-based applications will fail hard and fast if they are I/O-bound to begin with.

We need some better guarantees of I/O latency from cloud providers. There was some mention made of Amazon offering a new “guaranteed IOPS” feature. I find this feature compelling, being highly beneficial to someone deploying to EC2 who must otherwise formulate a deterministic/realistic SLA for their customers.

All in all it was good to get together with some cloud folk and commiserate a bit. Throughout the sessions it became highly evident that there are still few established best practices, and even definitions for much of what we do in cloud computing. It’s an exciting time to be involved in this problem domain seeing it slowly mature into something revolutionary and likely unforeseen.