Manual deployment vs. Amazon Elastic Beanstalk

Question

What are the advantages we get by using Elastic Beanstalk over maually creating EC2 instance and setting up tomcat server and deploy etc for a typical java web applicaion. Are load balancing, Monitoring and autoscaling the only advantages?

Suppose for my web application which uses database I installed the database in the EC2 instance itself. When Autoscalling takes place will the database gets created in the newly created instance or it will be accessing the database I created in the master instance... If it creates just a replica when autoscaling happens how will be data sync happens between the instances?

Answer 1

I had an app deployed both in EC2 dedicated(Nginx & Gunicorn) and Beanstalk Environment(CentOS & Apache2).

My observations:

• BeanStalk is Paas. Manually creating an EC2 instance(IAAS), is like doing everything from scratch, but you have solid control.

• BeanStalk comes with by default CentOS and Apache(Httpd). You could choose OS in dedicated instance.

• These things that mattered to me,

  • There were lots of 504 errors showing up in Beanstalk environment.
  • It was difficult to debug when BeanStalk server crashed, as logs would also not show up and could not ssh into machine. This is very important.
  • Installing/configuring tools like Celery, Redis (need to run another port) etc.,. in dedicated instance is lot more easier.

• In my case, I had to scale up (Beanstalk)server in order to run installation of some packages(like pandoc). These things are more simpler in Ubuntu.

• Scaling is a lot more easier in BeanStalk. Cloning servers is straightforward in BeanStalk.

• I had taken micro in both the cases (dedicated & Beanstalk). I felt dedicated micro instance was better.

• Automated deployment in Beanstalk. I had to write scripts to automate the same, which is fine, since it is only once.

Answer 2

All the things you mentioned like load balancing, monitoring and auto-scaling are definitely advantages.

However, you have to kind of think about it this way: In a true Platform as a Service (PAAS), the goal is to separate the application from the platform. As a developer, you only worry about your application. The platform is "rented" to you. The platform "instances" are automatically updated, administered, scaled, balanced, etc. for you. You just upload your WAR file and it just works (at least theoretically).

EC2 by itself is not PAAS. It is more like IAAS (Infrastructure as a Service). You still have to take care of the server instances, install software on them, keep them updated, etc.

Elastic Beanstalk is a PAAS system. So are App Engine and Azure among many others.

In a true PAAS system, the DBMS is a separate component from the web application server(s). The reason is obvious: The DBMS cannot be possibly installed on the instances that are being used for the application server because, as instances are created and destroyed based on your traffic, the DBMS would be lost! Having the DBMS and application server on the same machine/instance is not generally a good idea anyway.

In a PAAS system, the DBMS is a separate service. For Amazon, it would be Amazon RDS. Just like with Elastic Beanstalk, where you don't have to worry about the application server and you just upload your WAR file, with RDS, you don't have to worry about the DBMS and you just deploy your database(s).

Elastic Beanstalk and RDS work very well together, especially when deployed in the same availability zone, where the latency would be very low.

Finally, using Elastic Beanstalk doesn't cost anything more than the deployed resources (EC2 instances and the load balancer). However, RDS is not cheap and would definitely be more expensive than using a single EC2 instance for both the application server and the DBMS.

Answer 3

Elastic Beanstalk does more than just load balancing, monitoring, and autoscaling.

1) Manages application versions by storing and managing different versions of your application, allowing you to easily switch back and forth between different versions of your applications.

2) Has the concept of "environments" for each application, allowing you to deploy different versions of your application in each environment. This is handy for example if you want to set up separate QA and DEV environments, and you want to easily deploy a build first in DEV then deploy the same version of the application in QA when your QA team is ready for the next build.

3) Externalizes the important container configuration properties (Tomcat memory settings, for example) to the Elastic Beanstalk console and API. Because of this you can easily save the settings and copy them between environments.

4) View application log files through the console and automatically roll and archive log files to S3. (Admittedly this feature is currently a little weak.)