AWS Elastic Beanstalk Programming Model
As I have already mentioned, Elastic Beanstalk will handle the nitty-gritty day-to-day details associated with running and scaling your application. You get to focus on your application and on your customers instead of on the details of the infrastructure.
You can use the development tools and development environment of your choice. You can use your existing build system and you can even use the Elastic Beanstalk command-line tools to fully automate most of the compile/deploy/test cycle.
You can also use the AWS Toolkit for Eclipse. You can write your application, deploy it to Elastic Beanstalk, and even test it out without having to switch your focus away from Eclipse.
Each application runs in a container of a particular type. The default Elastic Beanstalk container lets you run Java applications in a Tomcat environment. Your application can make use of Servlets and JavaServer pages and you can mix the two of them as you would like. You can also use all of the usual Java EE classes and APIs as you would like; Elastic Beanstalk won’t get in your way!
You do need to give some thought to data persistence if you want to build a scalable and highly reliable application (and I’m sure that you do). Because an Elastic Beanstalk application can scale to multiple EC2 instances, storing long-term data on the file system of the instance is not a good idea. Instances will also come and go as a result of Auto Scaling and the occasional hardware failure. Therefore, any data that you need to keep around for an indeterminate period of time should be stored in a database, not on the EC2 instance. Amazon S3, Amazon SimpleDB, and the Relational Database Service will all be of use here.
Your code can also make use of the AWS SDK for Java. This SDK gives you access to important parts of AWS including:
- The Amazon Simple Storage Service (S3) for public or private storage of data objects of any size (1 byte up to 5 TB).
- Amazon SimpleDB for highly available and highly scalable storage of non-relational data.
- The Amazon Simple Queue Service for reliable storage of messages as they travel between independent components of your application.
- The Amazon Simple Notification Service for highly scalable publish and subscribe messaging.
- The Amazon Relational Database Service for easy and convenient access to a scalable relational database.
- Amazon Elastic MapReduce to process large amounts of data using a hosted Hadoop framework.
Each of these services is scalable and highly reliable and available for you to use (or not) as desired. Depending on when you signed up for AWS, you may have access to these services within the AWS free usage tier.
You can also use the SDK to access EC2, CloudWatch, and AutoScaling APIs. This is probably an edge case since Elastic Beanstalk will take care of the hosting and scaling for you, but I’m sure someone will find an interesting way to make use of these services from within an Elastic Beanstalk application.
Although I am a big fan of each of these services and certainly hope that you will use them, I think that it is important to note that nothing in the Elastic Beanstalk model or in the default container type actually forces you to use them. If you have existing code that makes use of other middleware, go right ahead and use it. If you need to call other services that run on other EC2 instances in the AWS cloud, go ahead and call them (and enjoy reliable, low-latency access while you are at it). Need to call services that are running outside of AWS? Go for it! Freedom of choice is a fundamental tenet of AWS and one that I can’t emphasize enough.
I should also point out that Elastic Beanstalk itself has a full set of APIs. The Elastic Beanstalk APIs can be used to create, control, modify, and delete applications and environments. I have covered these APIs in a separate post.
Keep Reading: AWS Elastic Beanstalk from the AWS Management Console.