Amazon thinks that it has a way of getting you hooked on cloud deployment - you can now upload your Java/Tomcat app to the EC2 cloud and it will just run.

There are two distinct ways of organising cloud computing. You can take the virtual appliance approach and deploy a complete system - operating system and whatever support is required for the app, languages, frameworks and so on. Alternatively you can focus on the app and provide a framework where the app is the only component that needs to be deployed. The app as the unit of cloud deployment is the approach taken by Microsoft's Azure and Google's App Engine. Until now Amazon's EC2 system was more or less appliance oriented - but now there is Elastic BeanStalk.

Yes "Elastic BeanStalk" a name that proves that not only open source projects and products get silly names.It seems that Amazon likes the name because it lets them say things like

"AWS Elastic Beanstalk is easy to begin and impossible to outgrow"

If you can stop sniggering long enough to consider using Elastic BeanStalk it turns out to be quite attractive. The big problem with using an appfabric approach is that you need to support a wide range of "application containers". An application container is simply an active environment - OS, servers, language, libraries etc - that are needed to run the app. You can imagine it as a container that the app has to be loaded into to actually run and do its job. In most cases there is no well defined app container and this makes the task of building cloud support for this sort of deployment difficult. Microsoft solved the problem by restricting apps to ASP.NET and Google solved it by restricting apps to Python. Amazon promise to support multiple app containers but for the moment it only supports Java.

What you have to do is write a Java app that targets the Tomcat server, package it as a WAR file (Web Application Archive) and upload it. From this point you can leave it to Elastic Beanstalk to figure out how best to deploy it in the EC2 cloud. It will perform load balancing and allocate the app to server instances. You don't have to configure the OS or ensure that the environment is right to run the app.

In principle its a deploy and forget solution but of course if you want to fiddle with parameters you can. You can set the database to use, the instance type used to run the app, configure HTTPS and so on. Most importantly you can set the auto-scaling parameters which control how many instances are used to run the app and so control both performance and cost.

You can see that really what is going on here is a lowering of the entry level. You don't have to learn much to get started but you can certainly bet that as time goes on you will slowly but surely work your way into the container until you know it well enough to consider it plus your app a virtual appliance.

"We'd been grappling with how to simplify application deployment and management on AWS without removing the flexibility and control our customers have come to expect," said Adam Selipsky, Vice President of Amazon Web Services. "Once we started exploring the mental model of customers being able to 'open the hood' to tinker with the infrastructure management themselves, a light bulb went off and we realized we didn't have to make this 'either/or' decision. AWS customers can now choose to have as much automation or as much control as they wish."

Amazon even offers a free usage tier that means that as a new customer you don't pay until you have started to clock up a reasonable amount of usage.

During restoration work at Bletchley Park, papers which had been stuffed between the roof rafters to act as insulation were discovered and found to include unique surviving examples of Banbury Sheets. [ ... ]