Java EE application deployment on Amazon EC2

Question

We have a Java EE application (EAR file deployed on JBoss, MySQL, MongoDB) which we would like to deploy on an Amazon EC2 instance. I have several questions regarding deployment best practices.

• What is the most commonly used Linux AMI which we can rely on for a robust deployment (There are so many Linux variants, and I am not sure which AMI is commonly used, is it Fedora, CentOS, Red Hat, SUSE ...)
• How do we handle production upgrades (EAR file modifications or schema upgrades)? Are there any tools which are available to handle this installation or rollback of these changes?
• What kind of data backup capability is available for the database?
• Should I rely on Amazon RDS for MySQL support?
• How should I handle support for MongoDB?

This is the first time, I am hosting a web app, and would appreciate some inputs on how to manage the production instance.

Answer 1

1. Use whichever Unix variant you're most comfortable with. It may pay to choose one with good cloud support. For my site I use Ubuntu.
2. I have a standard image that is the base of every version deploy I do. I have www.mysite.com pointing to an Elastic IP so I can decide which instance it goes to. The standard image has all the software I would like to be installed (Postgres/Postgis/Tomcat/etc) however the database and web server data folders and symlinked to Elastic Block Store (EBS) instances.
   1. When it comes time to try and do a deploy I begin a new instance up, freeze and snapshot the EBS volumes on production and make new volumes. I point my new instance at the new volumes and then install whatever I need to onto that. Once I've smoke tested everything successfully I can switch the Elastic IP to point to the new instance and everything keeps ongoing.
   2. I'll note that I presently have the advantage where only I will modify the database; no users can. This will become a problem shortly.
3. If you use the XFS filesystem on top of the EBS volume then you can tell XFS to freeze the file system (so no updates happen) then call the EC2 API to snapshot the volume then unfreeze the file system. The result is that the snapshot is taken quickly and sent to S3. I have a nightly script which does this.
4. If RDS appears like it'll suit your needs then use it. Amazon is building a lot of solid tools quickly and this will ease your scalability problems if you've got any.
5. The usage of MongoDB should be aligned with the purpose of your application and the benefits you gain from that. I would recommend you use MongoDB for static data retrieval like state, country, area etc, where MySQL to be used for transaction data only