Amazon Web Services
Monday, February 25th, 2008 at 11:51 pm
Getting there was straightforward: bus, train and then another train to get back around the loop to Parliament Station a bit quicker. One thing to remember about Parliament is that there are two concourses, each located past the end of the platforms. If you go down the platform in the wrong direction you end up having to double back more than the platform length once you leave the station. Not good if you are running a bit late. But it is good to know for the next Web Standards Group meeting as once entrance/exit is very convenient for the current meeting venue.
Afterward a few (about 10) made it to a nearby bar for a drink, an even smaller group (of 7) then made it to a Japanese resaurant for some food and a discussion of how technology has evolved over time.
What about the presentation itself?
Mike gave an overview and examples of how people are using there of the Amazon Web Services:
- Amazon Simple Storage Service (S3)
- Amazon Elastic Compute Cloud (EC2)
- Amazon Simple Queue Service (SQS)
I hadn’t really looked into any of these before and I now need to have a look. Of what was said there are two things that stuck in my mind. The first being that it is possible to serve data directly from S3 by making the objects public and pointing a subdomain of yours at the S3 service. Would be very useful to push your static content out onto a highly available and high performance service.
The second thing that stick in my mind is that people are monitoring their virtual servers in EC2 and automatically adjusting for load by increasing or decreasing the number of instances. At work, virtualisation of our web nodes is (sort of) under consideration. I see this type of thing as the only tanglible benefit of virtualisation of our nodes.
You would need to have a generic image that when booted up as a new instance will grab the current production code, add itself to the load balancer and start serving content. Implementing it in such a way that the new instances have the appropriate permissions to databases, etc would be tricky. But it could make it trivial to double or triple your capacity during a few peak times.
Of course this is assuming your bottleneck is CPU…