What is it?
Today Amazon announced a new service, Elastic Beanstalk. What it is, is a combination of a complete Java stack (other languages supposedly coming later) along with a management wrapper around some of the existing EC2 tools such as load balancing, auto-scaling and monitoring. This definitely touches a pain point that developers are facing when they deploy their apps to the cloud. In fact, it’s part of the reason that Heroku and Engine Yard have done so well. While its pretty easy to setup a server in the cloud and load up your software, a setup that basic normally won’t scale and will not be easy to manage over time. As a result, developers either spend a lot of time rolling their own solutions or they pay for a Platform-as-a-Service (PaaS) like the ones mentioned earlier. What Elastic Beanstalk does is provide developers some of the advantages of a PaaS without the costs and without given up total control of the server.
So let’s dig into Elastic Beanstalk a bit more. There are several pieces to the service.
- A Java stack that Amazon has put together that is comprised of Linux, Apache, Tomcat and Java. There is even an Eclipse plug-in to integrate Elastic Beanstalk into the IDE. The stack is pretty standard. It does not include things like Spring or any other popular variations of the Java stack. Note, Amazon has indicated there will be other stacks in the future. In fact, Engine Yard is supposed to be helping to create a Rails stack.
- A Management GUI built into the AWS console that allows developers to setup and configure their application.
- Use of some the AWS services. That includes: the load-balancer, auto-scaling and cloud-watch. S3 is also used to store version of your app and for log consolidation. Normally, you would need to setup these up yourself if you wanted to use them. Elastic Beanstalk will automatically setup all these services when it deploys your app.
- Support for application versioning. Elastic Beanstalk uses S3 to store each of the versions of your application which it can use to either deploy the lastest release or rollback to the previous version.
- An API to allow developers to build Elastic Beanstalk into their development process. I can see teams using Hudson or another continuous integration using the API to push new releases/versions to Elastic Beanstalk.
Using Elastic Beanstalk is pretty straightforward. First you load your application on to S3. Then you use the AWS Console to create a new application. The configuration options allow you to specify a variety of options including the S3 bucker where to find your application and the rules for when Amazon should scale your application. At that point, you are able to launch the application. Elastic Beanstalk will setup the load-balancer, create a EC2 instance, install your application, setup auto-scaling and cloud-watch. The final thing you need to do is point the domain for your app to the CNAME that Elastic Beanstalk provides. At this point, your app is live and setup in a configuration that should be pretty easy to monitor and manage.
Clearly there is a lot to like about Elastic Beanstalk. Is there anything that got missed?
First, as previously mentioned, right now the service only supports a Java stack. For a lot of people using some of the other popular languages (like Ruby, Python and PHP), that is a non-starter. Hopefully, it won’t be long until Amazon has stacks for the key popular languages.
But the other important area where Beanstalk falls short is in that it is oblivious to databases. I can’t image there are very many applications that don’t depend on some sort of database. That means that you need to take care of setting up your database yourself. And since Elastic Beanstalk does not know about your DB, it is not able to monitor it or scale it either. This means that even though Elastic Beanstalk takes care of your application, you need to find another solution for the database. To be fair to Amazon, there are a lot different databases that people are using today (like MongoDB, CouchDB, Cassandra, etc). But I think they should have been able to support MySQL, especially since they already have the Relational Database Service (RDS).
You should also think about is whether you application needs another other than the basic stack. Does it use Memcached, Redis, or some other piece of software that is not part of the standard stack. If so, you still need to handle that yourself. Either you need to put it on another service or figure out some way to automate the installation when your app comes up on a server. If you look at Heroku, they now have an add-on program that is quickly building a robust list of options. Amazon needs to consider something similar.
And finally, if you move to using Elastic Beanstalk, you are pretty well committing yourself to keep your app on Amazon. I don’t see that a big issue but it’s something that you need to keep in mind.
So is it Worth Using?
In short, this is still an important step forward for Amazon. For developers that have been building their own software stacks and manually deploying it to EC2, this has the potential to take several things off their plate. Clearly, Elastic Beanstalk will not be 100% of the solution but having the things that Elastic Beanstalk handles taken off a develoepers plate will make things simpler, even if they still need to handle some things themselves. One thing i forgot to mention is that Elastic Beanstalk is free (although you still pay for the underlying services). That in itself should get a lot EC2 developers to give it a look.