AWS Cloud – Mostly Local Showers

AWS Cloud – Introduction to AWS – 27th September 2011
We attended the ‘AWS Cloud – Introduction to AWS’ conference in London today (27th September, 2011), to hear a keynote from Amazon CTO Dr. Werner Vogels, technical evangelism from Matt Wood, and some customer presentations by Dan Harvey of Mendeley and Steve Romney of Shutl. Our experience of AWS to date has been largely through our own explorations of SQS, S3 and EC2, so the conference was very helpful in explaining how everything hangs together.

Regional Isolation
One takeaway for us was that Amazon don’t really help you address enterprise architectures that span Amazon’s regions. You can build all the availability and redundancy you want in your Dublin cloud, but if you want to share data or state with your New York cloud, you are on your own (unless you are happy to make transtlantic web service calls). This situation is particularly relevant in financial markets, where you may have multiple exchanges feeding middle and back office systems that are located in a single hub. It is true that Amazon’s CloudFront service reduces latency for static web sites that are accessed from remote regions, but this only highlights the question about how you make everything else work.

Data Sovereignty
An interesting question from the floor was around data sovereignty – if Amazon is a US company, what is to stop your data being subpoenaed by a US court? The answer from the AWS team was that they are not lawyers, and it is really up to you to figure out whether usage of their service for your data is appropriate. We respect the team’s clarity about what they don’t do, as well as what they do do, but we suspect we weren’t the only corporate types around the room thinking ‘errrr … maybe we’ll just pop out and delete our S3 backups.’

Cloud Philosophy
One of the things we like about Amazon is the clarity of their technical philosophy. Considering the depth and breadth of their offering, the AWS web site is positively miraculous. We found and read the complete API for Amazon SQS in about the same amount of time it took us to even figure out what the Microsoft cloud queuing system is called at the moment. At the same time, this does mean you are not going to get a lot of help if your use case falls outside what they are offering. It is utility computing from a large utility, and your chances of getting additional help or special favours are about the same as your chances of EDF changing the frequency of alternating current to your house.

Machines Not Applications
You can tell that Amazon’s heritage is in infrastructure more than applications, and this comes through in their core EC2 offering. It is really up to you to configure your machine the way you want – there is little by way of comparison with more managed application sandboxes such as Google App Engine. As a company with relatively little system administration experience, we can’t say we look forward to configuring machines. But it looks like we might get to have our cake and eat it, as Amazon have also introduced the Elastic Beanstalk, which allows you to write Java code, compile it, package it up into a WAR, and upload it to a Tomcat environment.

The above observations aside, it is clear Amazon are setting the pace here. There is a solidity and maturity about AWS which is very attractive, and whilst other offerings might look more attractive on paper for certain scenarios, we suspect we might miss the 15 years Amazon have spent getting this stuff right. We do wish you could use DevPay outside the US, though.

This entry was posted in Architecture, Cloud, Message Queue Software and tagged , , , , , , , . Bookmark the permalink.