Heroku vs. Amazon Web Services, a Cloud Comparison

You can’t beat free, and this is actually quite a good offering. One dyno is plenty to run many kinds of apps. Brochure sites, simple APIs, and blogs are a few of the many possible uses for this free dyno. But to make the comparison fair, we need to know what this free dyno includes and what strings are attached.

Drawbacks

• Additional dynos/workers are $35 a month.
• No other services can be run on dynos. Dynos are strictly for application processes. Databases, background workers, and other services usually cost extra through Heroku’s add-ons or third-party services.
• No way to increase RAM, storage, or CPU performance. Additional storage must be hosted separately through a service such as Amazon S3. App performance can only be improved by increasing the number of running dynos. Heroku automatically load balances and routes visitors to all available dynos.
• No way to install system software. Heroku does provide some commonly used packages such as Imagemagick, but if you need anything else, you’ll have to resort to hacks.

Amazon Web Services (AWS)

Amazon Elastic Compute Cloud (Amazon EC2) is the closest equivalent to Heroku’s dynos. One EC2 micro instance is approximately equivalent in terms of RAM and compute power to one of Heroku’s dynos/workers. However, in our experience, the performance of a full-stack Rails application on a single micro EC2 instance is not quite as good as on a single Heroku dyno. This could be because we were running a database and workers on the same instance. We could have probably slimmed down the instance by removing unnecessary system processes, but instead we typically go with a small EC2 instance.

As you can see, EC2 is much cheaper when paid for in advance. Let’s just go with a one-year heavy-utilization-reserved small instance for this comparison.

Again, it’s hard to make a direct comparison, but some of these figures are considerably higher than Heroku’s (1600 times the storage space!).

Drawbacks

• You have to deploy your application yourself, either through Chef recipes, Capistrano, or manually.
• You have to administer the system yourself. EC2 has machine images of popular distros, such as Ubuntu, that are easily launched, but after that it’s up to you to keep it up to date and secure.
• Scaling horizontally (i.e. launching multiple app instances) is not as easy as with Heroku where it’s just a matter of moving a slider on their web interface. You’d better get familiar with Chef if you want to scale up and down frequently. This seems like a big drawback but in practice we rarely adjust the number of running instances for an app.
• AWS is more expensive for the basic offering. A specific free tier will give you one free micro instance for the first year (only available when you first sign up) but this is not as generous as Heroku’s free, unlimited, single dyno apps.

Real-life cost examples

Say we have an app that needs 10MB database storage, one worker, and SSL. With Heroku this will break down to the following:

To get the same thing on Amazon, you’d pay the following:

Admittedly it’s not a huge savings for the first month, but let’s say you need to add Redis and MongoDB. They both live mainly in memory, so it’s a good thing we went with the 1.7GB RAM on Amazon. We can easily run both of these services on our single small instance. On Heroku we’d need to add the following:

With Amazon it’s easy from a price perspective to add or remove services. If you go with Heroku, you may have to ask your client for an additional monthly payment for each service you add, making the decision more difficult and time consuming.

Other considerations

Besides costs, you will want to consider whether or not it’s even possible to run your application on Heroku before going that route. If you need to run custom binaries or compile from source, you will have to figure out how to hack Heroku, or you may be out of luck. If you need to store temporary files you should know that Heroku’s ephemeral file system does not make that task easy. You could end up exerting a lot of effort only to eventually run into a brick wall. Personally, I’ve had to hack gems and try to find workarounds for many Heroku-specific issues.
On the other hand, if you know your application will fit within the limitations, deployment on Heroku is a breeze. The web interface is beautiful, the CLI client works well for the most part (it can’t manage multiple Heroku accounts), and it’s easy to add other services through add-ons. But if you think your app’s needs might grow in ways that won’t be satisfied by simple horizontal scaling, you should definitely consider AWS. Of course, you can always start with Heroku and later migrate to AWS. But in that case you will have to configure your app for two environments and spend the time to migrate everything.

Other options?

In my experience, no other platforms compare well with Heroku or AWS. Some nice Heroku alternatives include Dotcloud, but they suffer due to Heroku's preponderance — they're consequently less integrative with third-party products, and they have less community support. Rackspace is the closest competitor to AWS, but it lacks the rich APIs and support that Amazon provides. Hopefully we'll soon see competitors offering us more choices and catching up to Heroku and AWS.

Conclusion

Both Heroku and AWS are excellent platforms. They are quite different in some key areas. Understanding what each offers is essential to picking the right platform for your application. There is no clear winner here. Personally, I like to use both. But my (simplified) mental test for which one to use is this: small app–Heroku; large app–Amazon. The winning platform is the one that most helps you achieve your goals through keeping your developers happy and productive while remaining affordable enough to be sustainable.