AWS Elastic Beanstalk — when it’s better than Heroku?

Story by Łukasz Pająk, Software Developer at Nomtek

Photo by Aneta Pawlik on Unsplash

You want to release a Ruby on Rails backend or web application fast, unfortunately, the queue to your DevOps engineer is long as hell? Moreover, all you need is an early staging environment or small PoC (Proof of Concept), not full production release with a balanced load and high-performance database. You could buy a droplet on DigitalOcean. Unfortunately configuring the Nginx, Puma, Redis and PostgreSQL is tedious and even just thinking of it makes you sweat. Your colleague says “AWS”, but you get a little bit confused by its pricing or multitude of services and you still need to configure several things around EC2 virtual machine, like SSL key as well as Nginx server. Why not release it on Heroku? It’s simple, troubleless and cheap (or even free) at the beginning. Indeed this is a good option, but there is something else worth considering: AWS Elastic Beanstalk.

First of all, Elastic Beanstalk works on the services under AWS and follows its price list. How does that differ from simply running the EC2 virtual server instance, you might ask? To be honest I was always a bit confused about its price list. It’s very long and has different variants for different Operating Systems. Amazon claims that you “Pay-as-you-go”. How should I understand it? Will I be charged by CPU Utilization metric, or just by running the EC2 instance? You can also see some mysterious abbreviations like EBS, NVMe or ECU. What does it even mean?

Fig. 1. Part of the EC2 price list. https://aws.amazon.com/ec2/pricing/on-demand/ (2018–11–14)

Let’s explain the AWS price list first.

Pay-as-you-go

Unfortunately, it doesn’t mean you pay for the CPU utilization. Whenever you set up the EC2 instance and it’s in the “Running” state you will be charged per hour or second, depending on the instance type. This is what AWS documentation says: “If your instance is billed by the hour, then you’re billed for a minimum of one hour each time a new instance is started — that is when it enters the running state.” It means you can set up dozens of the EC2 virtual machines, and you will not be charged until you run them up.

Free Tier

Yes, Amazon gives you free services. Some of them are free for 12 months starting from the date you registered the account and some of them are always free. Visit https://aws.amazon.com/free/ for more details. Just keep in mind that 750 hours of the EC2 t2.micro instance, as well as 5GB S3 storage, is free for 12 months.

Fig. 2. Part of the Free Tier. https://aws.amazon.com/free/ (2018–11–14)

AWS Elastic Beanstalk

As I mentioned before, Elastic Beanstalk is working on the services under the AWS. To be exact, it starts up the EC2 virtual machine that has preconfigured Nginx with Puma or Passenger, according to your choice and S3 private bucket as a storage for your code.

Let’s try it out. All you need is the AWS account. Select Services->Compute-> Elastic Beanstalk and then “Get started” button. New application wizard will ask you for application name, platform and the application source code. For me, it was accordingly: “MyTestApp”, Ruby platform and “Upload your code” option. At this point, you should pick the zip file with your RoR application root folder compressed. Later you will be able to use AWS CLI and deploy new code in a more civilized way than just uploading a zip file.

Fig. 3. Elastic Beanstalk new application wizard.

We could create the new application right now, but let’s click the “Configure more options” button first. There are several blocks describing the entire environment with “Low cost” selected for the “Configuration presets”. Notice “Instances” block with EC2 t2.micro selected. It means the Free Tier will be used.

Fig. 4. Elastic Beanstalk Instances configuration block.

My application is as simple as it could be: Rails 5.2, Ruby 2.5.3 and SQLite. If you need a more sophisticated database, you can modify the “Database” block and set up RDS service. Amazon offers several database engines, like PostgreSQL, MySQL or Oracle. If you choose db.t2.micro instance class you will not be charged, since it’s in the Free Tier too.

When you are satisfied with the configuration, click the “Create Application” button. The process takes several minutes after which you will see the green status health check and your application is up and running. The URL address is also given, so you can check if everything is working correctly.

Fig. 5. Elastic Beanstalk application dashboard.

What else will you get?

At this point, Elastic Beanstalk has already configured and launched the EC2 t2.micro virtual machine instance together with S3 bucket for you. If you have selected some database, the RDS service is prepared as well. How cool is that? You think that’s it? Well, not really. What else will you get?

  1. Dashboard, where you can check the health status of your app and recent events.
  2. Configuration board, where you can manage the entire environment.
  3. Logs! Yes, you can request and review the logs from your app, and Elastic Beanstalk knows where to find them.
  4. Enhanced health overview, where you can see the request-response statistics.
  5. Monitoring board, where you can check the basic metrics, like CPU utilization and network traffic.
  6. Alarms based on monitoring metrics. You can set up the warning email you receive when e.g. CPU is utilized over 80% for a specific period of time.

Moreover, free SSL certificates are also available. All that is needed for HTTPS protocol is a custom domain, and you can order the certificate through the Certificate Manager.

What’s next?

That was a very basic example of how to run the application on AWS Elastic Beanstalk. In my opinion, Heroku is a bit easier and troubleless, and there is some general knowledge you need to have before you can safely start working with AWS. Heroku is awesome for things like PoC you just need to deliver ASAP. The free plan is usually enough for them. Moreover, the way you can configure and run plugins on Heroku is pretty convenient.

What if PoC is starting to be more like staging environment, and the customer is saying he would like to release the first MVP next week? The farther you go the easy and convenient Heroku path, the harder it gets to turn and move your app somewhere else.

The biggest issue I dealt with regarding Heroku, was its price. The free plan is cool, but the server is falling asleep after 30 minutes of no activity. The first request to the sleeping server takes ages and sometimes even fails due to timeout. Not a big deal, you would say, since the Hobby Plan is only $7/month. That’s true but with the Hobby Plan you only get 512MB of RAM and it’s just a snap for your Ruby on Rails application when users start to generate some traffic.

Two weeks after MVP release your customer says their business partner loved the application and they want to take on board around 2k of users in the 2 next weeks. Sounds great for the Sales Team? It also sounds like a Professional Plan with several Standard ($25-$50/dyno/month) or even Performance ($250-$500/dyno/month) dynos to me. It’s very easy to switch the pricing plan, but suddenly it appears that the database plugin’s Free Plan reached its limit as well as Redis and LogDNA and the story continues. Alternatively, you can use an EC2 virtual machine on AWS with 2 vCPU and 2GB of RAM which costs less than $20/month. This is obviously not the final cost, because you also need a database and Redis, but it’s still less than on Heroku.

Another difference worth mentioning is that when using Heroku you are not able to connect to your server via SSH and install something. You can only use what Heroku and plugins offer. On AWS you have full SSH access to the virtual machines that Elastic Beanstalk runs.

And the winner is…

Personally, I do believe, that there is no silver bullet and it’s our responsibility as developers to choose a proper tool basing on project assumptions and knowledge we have.

For a short and simple project Heroku is probably what you need, but keep in mind that scaling is expensive. If MVP is planned right after PoC it’s probably better to use AWS especially since Elastic Beanstalk helps you with the configuration a lot.

Which solution suits you better? Feel free to share your thoughts below in the comments!