Heroku vs EC2

Posted by UpGuard

Amazon EC2 vs HerokuWith the increasing importance of cloud computing, services like Amazon’s EC2 on AWS and Heroku are coming under more scrutiny. Even better for the consumer, the increasing number of such services means more choice in the market. But with this increased choice comes an increased level of confusion, because it’s often difficult to do an apples-to-apples comparison of the various services. Even worse, their offerings aren’t strictly in the same domains, but let’s take a stab at it.

What They Are

EC2 is the major component of Amazon’s cloud offering AWS, together with a bewildering plethora of other services – RDS and MongoDB for database, S3 for storage, OpsWorks and Elastic Beanstalk for deployment/ config management, and several others that will give you a headache if you try to learn them all at once. But the main point is that EC2, or rather AWS, is a proper IaaS platform – it mainly gives you bare machine components. You then use those components to build your apps, databases, deployments - whatever software environment your heart desires.

Heroku, on the other hand, is a PaaS solution. You get a ready-made environment in which you push code and can make a restricted set of config changes to get your app up and running. It is not as open-ended as AWS, and that’s both good and bad. Good because it means you can migrate and start your apps relatively quickly on Heroku. Bad because it locks you into Heroku’s way of doing things. Oh, and if your apps don’t run on their ‘platform stack’ then you’re plain out of luck. With Heroku (and other PaaS’s) you don’t get access to the underlying infrastructure, because that’s not the point. The point is to get a ready-made environment without the hassle of machine setup. In this way, you see that Heroku and EC2 aren’t strictly competitors in the same market space. So you won’t be surprised to hear that the Heroku infrastructure is actually hosted on AWS!

Cost & Pricing

This is one area where things are not clear cut at all, and making a direct comparison isn’t easy. And to complicate things further, the cloud pricing wars have just started late last week with price reductions being announced by Amazon, Google and Microsoft. We could say that it's $0.05/hr for a dyno hour, compared to $0.025/hr for an AWS micro instance or $0.09/hr for an AWS small instance. But it’s not that simple and tied up in a neat little bow.

 

To start with, both offer a free virtual server for tiny, basic setups. In EC2 this is called a micro instance, and Amazon entices new customers with a free micro instance for the first year (0.6 GB RAM, unlimited swap up to your storage limit, 160GB storage) and all this costs roughly $15 a per month (on demand). Heroku’s server is called a dyno, and your first dyno is free for perpetuity. Great, right? Er, not so fast. Remember, a basic dyno won’t be able to do very much (512 MB RAM, 1GB swap), so you’ll likely need additional ones if your application has a larger memory footprint.

Heroku is set up to scale horizontally out of the box with no additional configuration and additional dynos cost $35 per month. Heroku also uses ephemeral storage volumes which means you will need to store any data generated by the application somewhere externally like S3. When you start mix-and-matching machine configs, the comparison is not very clear cut. Follow the links below for a more in-depth analysis of the pricing structures:

http://www.smashingboxes.com/heroku-vs-amazon-web-services/

http://www.quora.com/Heroku/How-easy-is-it-to-get-off-Heroku-once-you-grow-out-of-it

 

Platform Model

As mentioned, AWS is an IaaS platform, and Heroku is a PaaS platform. Heroku provides you a limited range of languages, databases and environments to work with (Linux, Node.js, Clojure, Scala, Ruby, Java, PHP, MongoDB, Cloudant, PostgreSQL). But the general consensus is that things run very well within that limited range, especially for Ruby-based apps and platforms like Ruby on Rails. For instance Heroku’s simple horizontal scaling means that the load on your app is automatically spread among all your dynos. The house is already built, so your role is mostly to just move in and arrange your furniture to make it a home, so to speak. The disadvantage is that your choice is severely limited. Also, you are locked into Heroku’s proprietary filesystem. This means any files you store on your server will disappear after the server is shut down, and it is not guaranteed to be on other servers your application is running on, and no other services can be run on dynos except those on the pre-approved Heroku list. There are hacks online to enable you to run unsupported platforms on Heroku, but the mere fact that you have to resort to hacks is still a cause for worry for many.

Amazon AWS is akin to having the wood, concrete, land and interior décor materials. Now build your own house. It is a much more powerful and flexible setup, but if you don’t know what you’re doing you are almost guaranteed to mess things up. You need a higher level of skill to set up and administer the OS and deploy your own apps, although things are made much easier by the fact that there is a huge number of preconfigured machine images of popular platform combos: Linux+Apache+MySQL, Windows Server+SQL Server, Unix+Oracle DB, and so on. Oh, Amazon also supports Windows and other Unix flavors, unlike Heroku. But AWS cannot scale horizontally as easily as Heroku.

To get your code running on AWS and looking a bit like a Heroku deployment, you'll want some EC2 instances - you'll want a load balancer / caching layer installed on them (e.g. Varnish), you'll want instances running something like Passenger and nginx to serve your code, you'll want to deploy and configure a clustered database instance of something like PostgreSQL. You'll want a deployment system with something like Capistrano, and something doing log aggregation. That's not an insignificant amount of work to set up and maintain. With Heroku, the effort required to get to that sort of stage is maybe a few lines of application code and a git push.

Scalability & Ease of Use

AWS outages are now legendary (http://www.networkworld.com/news/2012/102212-amazon-ebs-263592.html). Because of the sheer size of AWS and the number of high-profile websites it hosts, especially those with huge user bases like GitHub, Reddit, Imgur, Foursquare, Pinterest, Netflix, etc, any AWS downtime makes the news. And we mean mainstream news, not only in the tech world. The AWS interface is relatively easy to use, offering both a useful GUI for setup and monitoring, as well as a CLI for more advanced config. Corporate and community support are both excellent; not surprising given Amazon’s size.

Heroku, although actually running on top of AWS appears to fare better in the service outage department. It has only suffered one major embarrassing outage in June 2012. It is git-based, so deployments are a snap, and the user community is particularly active. The CLI is blissfully easy to use, and users of both platforms report they are happier with Heroku machines’ performance. But Heroku Apps are blocked in China, for some reason that most likely has to do with security.

Summary

So Amazon vs. Heroku? You decide for yourself, based on whether you prefer your house pre-built, or you would like to work with the architect to tailor it specifically to your needs. Also see the excellent comparison chart below:

AWSHeroku
AWS offer IaaS I.e Infrastructure as a Service. IaaS gives you components you need in order to build things on top of it. Heroku offer Paas I.e. a Platform as a Service. PaaS gives you an environment where you just push code and some basic configuration and get a running application.
You have to deploy your application yourself, either through Chef recipes, Capistrano, or manually. You can deploy your app by simply Pushing your code into git repo provided by Heroku.
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. No need to do anything Heroku does it for you.
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. You can easily install multiple horizontal app instances on Heroku.
AWS is more expensive for the basic offering. There is a free tier that 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. The bigger apps would be much better off in terms of costing on top of AWS. Heroku is free to use for first dyno. The cost will increase very steeply as you increase dynos. At this point you will be made to think ease vs money … ;) !!
AWS is not easy as Heroku is simply because its not managed. Heroku is also not managed by default but the tools offered are much more sophisticated. Easy to use web interface is beautiful, the CLI client works well for the most part (except it can’t manage multiple Heroku accounts), and it’s easy to add other services through add-ons.
You have the control over the file system in AWS. Its just like your dedicated server with root access. Can't save any file on Heroku explicitly, until you don't know filesystem of Heroku.
We can easily upgrade hardware requirements according to our needs in case of AWS. No way to increase RAM, storage, or CPU performance. Additional storage must be hosted separately through a service such as Amazon S3. Application performance can only be improved by increasing the number of running dynos. Heroku automatically load balances and routes visitors to all available dynos.
You can run services like redis or delayed job easily on AWS. 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.
You can install any system software like wkhtmltopdf or image magic easily on AWS. 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.

References

http://www.smashingboxes.com/heroku-vs-amazon-web-services/

http://www.quora.com/Heroku/How-easy-is-it-to-get-off-Heroku-once-you-grow-out-of-it

http://www.andrewmunsell.com/blog/moving-from-ec2-to-heroku

http://www.mytechlogy.com/professionals/questions/forum-details/1328/heroku-vs-amazon-aws-for-deploying-ruby-on-rails-applications/

http://www.onebloke.com/2012/04/heroku-versus-appengine-and-amazon-ec2-where-does-it-fit-in/

Topics: amazon, ec2, cloud, IaaS, Cloud Computing, Heroku

UpGuard customers