In my first article on Amazon's EC2, Getting Started with the Cloud: Amazon Web Services, an Infrastructure as a Service (or IaaS) offering that provides total control over all aspects of an architecture, from its hardware resources to its OS flavor and version, and ultimately to any and all software required (think databases, application servers, etc). This low level of control is what many software development and operations teams require and even desire. However, this level of control often equates to complexity and a resultant slowdown of a development-deploy cycle.
It's not surprising then to see competitors attacking Amazon's cloud market share with higher-level offerings, known as Platforms as a Service (or PaaS), which abstract a lot of the intricacies of a system architecture ranging from hardware configurations all the way down to what software is provided or not provided. In essence, PaaS offerings are a lot like a sandbox (that is, you are free to play within their bounds, but if you want to go outside of them, you're out of luck). Thus, they facilitate rapid development and deployment because development teams don't need to deal with a lot of system details it's all just there. Examples of such successful PaaS offerings include Google App Engine (or GAE) and Heroku.
A PaaS like GAE makes rapid deployment a breeze, provided you play within Google's sandbox. All aspects of memory allocation, space allocation, and even mundane things like load balancing are handled for you by Google's team of engineers. GAE (which has been extensively covered this year on Dr. Dobb's in Allen Holub's series of GAE how-to articles) scales without manual intervention. That is distinctly different from leveraging a raw EC2 environment, where scaling, among other things, is handled by you. Not surprisingly, many development teams have opted to go with PaaS offerings even if they do in some ways restrict aspects of the development cycle. In essence, development teams are wiling to live with restrictions if they provide a benefit. In the case of GAE, it does rapid deployment.
Nevertheless, Amazon does offer a PaaS that abstracts away a lot of the low-level system details, but also provides you with a high degree of control that isn't apparent in competing PaaS offerings. Thus, with AWS, you have the opportunity to have your cake and eat it too!
Introducing Elastic Beanstalk
Amazon's Elastic Beanstalk is a cloud-based all-in-one rapid deployment environment that lives on top of the Amazon Web Services infrastructure. Elastic Beanstalk packages up EC2, S3 (Amazon's cloud-based storage service), RDS, SimpleDB, and a host of other Amazon offerings into one easy to configure and use product. Thus, you don't need to make a lot of choices or have sysadmin skills to put a viable Web application that's capable of mass scalability on the AWS platform into production.
With Elastic Beanstalk you get handy features that you wouldn't easily get if you rolled your own EC2-based environment. For instance, an Elastic Beanstalk provisioned application is easily monitored by Amazon; in fact, during the provisioning process, you can provide Amazon a special URL to ping to monitor application availability. What's more, if your application does go down, Amazon will notify you via email. Even though Amazon provides you with the base EC2 instances on which to run your Web application, you are still able to SSH to those instances all you have to do is provide Amazon with an existing key pair.
You also get a URL. That is, your Elastic Beanstalk instance is, by default, given a publicly available URL related to your environment's name (though you must first pick an available name). For example, if your application's name is caprice, your provisioned Elastic Beanstalk URL would be http://caprice.elasticbeanstalk.com.
Furthermore, just like with all other AWS products, you have a bevy of options available for deployment and management of Elastic Beanstalk applications. I tend to favor the Web-based AWS management console; but you also can use an Eclipse plug-in, or even a command-line client (just as I showed you in the first article in this series, Getting Started with the Cloud: Amazon Web Services).