AWS Elastic Beanstalk: Checkmate

Last week Amazon announced a new service in the Amazon Web Services family, Beanstalk. Beanstalk is Amazon’s Platform as a Service play–allowing AWS customers to write server applications in Java using the Apache Tomcat application stack and Amazon’s API. Applications written for Beanstalk automatically deploy and scale via Amazon Web Services’ myriad of offerings including RDS, Elastic Load Balancer and EC2 without the developer having to launch and manage instances of each.

Beanstalk is an important release because Google App Engine has been slowly gathering steam as an alternative to Amazon EC2. Google’s App Engine is what is called a Platform as a Service. It allows you to write an application in Python or Java and host it in Google’s environment where it automatically scales to meet demand. You don’t have to launch instances or manage virtual servers. You simply administrate your application which happily lives in Google App Engine’s cloud.

The problem with Google App Engine is you have no control over scaling. You just hope Google can handle it. And as many have found out, sometimes it can’t. Regardless, not dealing with deploying and managing virtual servers can be worth dealing with App Engine’s quirks. Plus, recent enhancements made to App Engine in response to developer complaints have made it a greater threat to Amazon EC2.

With Amazon EC2 you are in full control–as it is Infrastructure as a Service. This means you are essentially a system administrator–deploying and configuring servers. Except these virtual boxes exist in Amazon’s cloud and not in a closet somewhere in the depths of your colocation facility. Amazon provides a variety of APIs and tools that let you weave these virtual servers together into powerful, scaling application platforms. However, with great power comes great responsibility.

Enter Beanstalk. Now you can write a Java application using Amazon’s API and deploy it to the cloud with one click. Beanstalk will spin up the EC2, RDS, Elastic Load Balancer, and other resources necessary to run it. Plus, you can manually specify how many instances to auto-scale to, how much RAM to use, and many other settings to control the behavior and resources allocated to your application. No praying to the Google Gods for cycles here.

Now it makes sense why Amazon didn’t buy Heroku. They had their own PaaS offering all along. I was considering making the leap to Google App Engine since it’s easier to hand off an application to administrate to non-technical clients than a virtual server farm. But, Beanstalk lets me stay in the Amazon ecosystem and seems at first glance to be more flexible and powerful than Google App Engine.

3 thoughts on “AWS Elastic Beanstalk: Checkmate

  1. Pingback: Tweets that mention AWS Elastic Beanstalk: Checkmate « Ralph Barbagallo's Self Indulgent Blog -- Topsy.com

  2. I’m increasingly interested in this sort of technical detail. Likewise, I remember when you first brought me up to speed about Amazon’s cloud offerings a couple of years ago.

    This was a great read.

  3. Pingback: Google App Engine Experiments « Ralph Barbagallo's Self Indulgent Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s