Last week I was at the London leg of the Amazon startup tour, the afternoon began with an short talk from Adam Selipsky, VP of Amazon Web Services, who gave overview of the origins and principles of AWS and a basic lesson in the utility and economics of cloud computing. Next up was Simone Brunozzi, Technology Evangelist for AWS Europe (http://twitter.com/simon), who got into more depth about the specifics of the more commonly discussed Amazon services (i.e. not Flexible Payment System/Mechanical Turk etc). He noted that there are currently upwards of 400,000 registered developers in the AWS program.

S3

There are currently over 29,000,000,000 objects are currently stored in S3, and the service has seen growth of around 3600% in the past 2 years
One of the lesser known features of S3 is its automatic scaling. S3 automatically places replicas of each object stored into multiple datacentres for redundancy and fault tolerance. What it also does is to automatically increase and decrease the number of distributed replicas in step with demand. So if a particular file suddenly becomes popular, S3 will create more replicas to handle the higher download rate. When that demand subsides, the number of replicas is reduced

EC2

EC2 is probably the service we make most use of at the moment, mainly for creating test lab environments as and when we need them. I think EC2 is probably the best understood of the AWS services right now, as it provides a resource that most of us are really familiar with already, it just does it really, really well. As a case in point, Simone highlighted animoto who, using EC2, were able to ramp up the server farm running their slideshow application from 80 to 3500 servers in around 48 hrs following the unexpected success of their facebook app.

SQS

Most well designed distributed systems employ some kind of queueing as the glue that sticks together loosely coupled component services. SQS was developed by Amazon for precisely this reason, and I often wonder whether we ought to be making more use of this particular service. However, it seems we’re not alone in our hesitancy to embrace SQS, it seems that it’s lack of strictly deterministic behaviour (an SQS queue is not a straight forward FIFO pipe, messages may arrive out of order) seems to be keeping many external developers from using it more (I think that the lack of a standard queuing interface makes people uneasy too as it increases the lock-in to AWS as a provider – a point that was touched on in the Q&A later in the day). My feeling is that this is one of those problems that can be solved by applying a little lateral thinking to the design. The case study detailing the architecture of the GrepTheWeb application built to process data harvested from the Alexa service is a great example of using queues to coordinate a workflow through multiple, independent components.

SimpleDB

Maybe it was just me, but I thought that Simone skipped over SimpleDB a little. Its a shame because SimpleDB feels to me as though its the least well understood of the AWS services (possibly due to it being the most recently unveiled), and I’d like to see more exploration of which use cases its suited to, what its strenghts and limitations are, how (if?) people are actually using it etc.

Futures

Simone closed with a brief view of the AWS roadmap, which in the near future includes more security futures, continuation of the internationalisation of services with EC2 joining S3 in Europe, the upcoming Content Delivery Network offering and the suite of management-tools-as-a-service (MTaaS ?) slated for rollout early in 2009

There was something of interest in each of the customer talks, and I was pleasantly surprised by the way that they all presented balanced assessments of the capabilities of the various Amazon services, there certainly didn’t seem to be any pet developers on show. The presentations that I got the most from were the ones from PutPlace founder Joe Drumgoole, Alan Williamson from MediaFed and Tom St.John of Kontexto

Joe Drumgoole : PutPlace

http://putplace.com is essentially an online backup service, built on AWS. When they started in 2006, their initial business plan included plans to spend $1,000,000 on datacenters and hosting, a plan they ditched in favour of moving to an architecture based on EC2 and S3. They run both application and task server grids, as well as their customer data db on EC2, with just their service monitoring being hosted outside Amazon’s datacenters.

Using EC2 allows them to quickly and easily reproduce their setup both for increasing capacity, and for testing (they currently run 2 grids – one for production and a second for OAT – Operational Acceptance Testing). Joe mentioned that they’ve spent a lot effort on getting the automation right here, something we’re also doing, and that this enables them to set up a grid in 10 minutes, and tear it down in in 30 seconds when they’re done with it.

Some stats on PutPlace:

• Running on EC2/S3 in production since January 08
• Backing up ~15000 user files per day
• Currently spending around $1200 per month on EC2
• And $500 on S3 – as you’d expect, usage of S3 is increasing constantly (doubling on a monthly basis), but their EC2 usage is largely static

Joe finished off with a wish list for AWS, including a request for more stats, the ability to create EC2 instances in European datacentres (something we’d really like too), and a stable, offline storage service for backups and other data with low frequency access patters (again, something we’d find very useful too).

Alan Williamson : MediaFed

MediaFed provide federation of premium online media from large publishers, such as The BBC, the Guardian and LeMonde.They also monitor and manage content as well as providing demographics and monetization services (could do with some of those!) Their original architecture was of the traditional variety in that they outsourced of hosting real, physical hardware to a managed service provider. Rapid growth prompted move a move to cloud services, and AWS in particular, when it proved impossible to economically scale on demand within the constraints of their hosting arrangement and that adding capacity meant long long lead times of around 10 days

The MediaFed application is composed of a number of frontend webservers, backend servers for RSS crawling, plus a whole bunch of servers doing things like ad insertion and analysing click through data. All of this is supported by Amazon infrastructure, with all of the processing being carried out on EC2 and S3 used for long term storage of logs, database snapshots etc. What I found most interesting about the MediaFed setup is the way they manage deployment as a single application stack. According to Alan, MediaFed is basically a Java app, running on Linux, which helps mitigate cloud vendor lock-in (a topic thats rightly getting a lot of airtime just now). In the past, we’ve taken a similar tack with development of the core platform codebase, a single java deployment the we just squirt onto fairly vanilla linux boxes, then just start the required bits. It simplifies the deployment considerably, and for us that’s crucial. I have wondered lately though how long this strategy will continue to be viable as we add more services (and therefore code) and as our codebase becomes more modular with better componentisation (through continual refactoring at both the code and design levels). In some of our most recent development, we’ve been using Puppet to manage the deployment of both our code and thirdparty dependencies like Java to a bunch of machine both internally and running on EC2. So far, this has worked well for us though it’ll be interesting to see how it develops along with our software.

Another interesting point Alan made was that even though EC2 now comes with a shiny SLA, instances DO go down, and you have to live with it. This calls for some thought when developing your application, handling failures is a core competency for any distributed application, specially one runnng in someone else’s datacentre. MediaFed’s solution to this is that when an instance falls over, they just spin up another to take its place. However, as services running on one node need to be able to reach services running on other nodes, they make what I thought is a novel use of SimpleDB. SimpleDB acts as a global, highly available service registry, when an instance boots one of the steps in its automatic configuration is to register itself to a known location in SimpleDB. The lack of services that compete more or less directly with SimpleDB seems to reduce MediaFed’s potential portability somewhat although thanks to the open APIs, other providers could always implement a compatible service.

Tom St.John : Kontexto

Kontexto is another player in the media analysis space, who aim to provide an on demand media measurement and analysis platform. Essentially, they run a large text collection and analysis infrastructure to provide categorization, storage, search and analytics (think data profiling, topic stats, trends & sentiment analysis etc) services.

By Tom’s admission, he’s ‘not the technical guy’ so his talk focused on the business aspects of cloud computing, especially from the point of view of a start up seeking investment. Tom told us that Kontexto’s cloud based architecture was a big selling point for early stage investors as it reassured them that their money would be spent on developing Kontexto’s USP(s), and not burned up by capital expenditure on ever depreciating hardware. Tom’s talk was the last of the day, so I guess that time was tight, but he did get a chance to list out some of the other things building their service atop AWS has enabled – most of which are particularly pertinent to a startup, but all of which we’ve found relevant ourselves:

• Experiment and make mistakes without burning money

• Try out new business models

• Focus on core software development, not system administration

• JIT scaling

• The ability to attack big market opportunities without needing a large capital war chest

The day finished up with a panel involving the previous speakers, followed by a QA session with Adam Selipsky and Amazon’s CTO, the legendary Werner Vogels. The Amazon guys were fairly cagey about the AWS roadmap beyond what’s already been published (to be expected, really), but Werner seemed intrigued by a question regarding GPUs on demand for applications with über-high processing requirements (read into that what you will). The bones of the message I think they were trying put across though was this: the current suite of web services provided by Amazon are the very lowest level blocks that they think are essential to builders of large (and small) scale applications with the “Internet Inside”. They’re the product of building these sorts of applications many many times over, and the current AWS APIs have evolved organically from that process. The implications of this are twofold, firstly: its not a finished work. So as Amazon gather more information about what are useful services to provide, their offerings will be refined and expanded over time (so feedback from the user community is essential for the long term success of AWS). Secondly, we can expect higher level services to emerge as their requirements and commonalities gain clarity, something that we’re already starting to see already.