Why do people use Heroku when AWS is present? What’s distinguishing about Heroku

Written by:

Why do people use Heroku when AWS is present? What’s distinguishing about Heroku
  • 0.00 / 5 5
0 votes, 0.00 avg. rating (0% score)

I’m a beginner RoR programmer who’s planning to deploy my app using Heroku. Word from my other advisor friends says that Heroku is really easy, good to use. The only problem is that I still have no idea what Heroku does..

I’ve looked at their website and in a nutshell, what Heroku does is help with scaling but… why does that even matter? How does Heroku help with:

  1. Speed – My research implied that deploying AWS on the US East Coast would be the fastest if i am targeting a US/Asia based audience
  2. Security – How secure are they?
  3. Scaling – How does it actually work?
  4. Cost efficiency – There’s something like a dyno that makes it easy to scale.
  5. How do they fare against their competitors? For example, Engine Yard and bluebox?

Please use layman English terms to explain… I’m a beginner programmer. Thank you.

Matthias Braun

First things first, AWS and Heroku are different things. AWS offer Infrastructure as a Service (IaaS) whereas Heroku offer a Platform as a Service (PaaS).

What’s the difference? Very approximately, IaaS gives you components you need in order to build things on top of it; PaaS gives you an environment where you just push code and some basic configuration and get a running application. IaaS can give you more power and flexibility, at the cost of having to build and maintain more yourself.

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.

So you’re this far, and you want to scale up. Great. You’re using Puppet for your EC2 deployment, right? So now you configure your Capistrano files to spin up/down instances as needed; you re-jig your Puppet config so Varnish is aware of web-worker instances and will automatically pool between them. Or you heroku scale web:+5.

Hopefully that gives you an idea of the comparison between the two. Now to address your specific points:


Currently Heroku only runs on AWS instances in us-east and eu-west. For you, this sounds like what you want anyway. For others, it’s potentially more of a consideration.


I’ve seen a lot of internally-maintained production servers that are way behind on security updates, or just generally poorly put together. With Heroku, you have someone else managing that sort of thing, which is either a blessing or a curse depending on how you look at it!

When you deploy, you’re effectively handing your code straight over to Heroku. This may be an issue for you. Their article on Dyno Isolation details their isolation technologies (it seems as though multiple dynos are run on individual EC2 instances). Several colleagues have expressed issues with these technologies and the strength of their isolation; I am alas not in a position of enough knowledge / experience to really comment, but my current Heroku deployments consider that “good enough”. It may be an issue for you, I don’t know.


I touched on how one might implement this in my IaaS vs PaaS comparison above. Approximately, your application has a Procfile, which has lines of the form dyno_type: command_to_run, so for example (cribbed from http://devcenter.heroku.com/articles/process-model):

web:    bundle exec rails server
worker: bundle exec rake jobs:work

This, with a:

heroku scale web:2 worker:10

will result in you having 2 web dynos and 10 worker dynos running. Nice, simple, easy. Note that web is a special dyno type, which has access to the outside world, and is behind their nice web traffic multiplexer (probably some sort of Varnish / nginx combination) that will route traffic accordingly. Your workers probably interact with a message queue for similar routing, from which they’ll get the location via a URL in the environment.

Cost Efficiency

Lots of people have lots of different opinions about this. Currently 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.

Heroku’s dyno documentation says you have about 512MB of RAM, so it’s probably not too unreasonable to consider a dyno as a bit like an EC2 micro instance. Is it worth double the price? How much do you value your time? The amount of time and effort required to build on top of an IaaS offering to get it to this standard is definitely not cheap. I can’t really answer this question for you, but don’t underestimate the ‘hidden costs’ of setup and maintenance.

(A bit of an aside, but if I connect to a dyno from here (heroku run bash), a cursory look shows 4 cores in /proc/cpuinfo and 36GB of RAM – this leads me to believe that I’m on a “High-Memory Double Extra Large Instance”. The Heroku dyno documentation says each dyno receives 512MB of RAM, so I’m potentially sharing with up to 71 other dynos. (I don’t have enough data about the homogeny of Heroku’s AWS instances, so your milage may vary))

How do they fare against their competitors?

This, I’m afraid I can’t really help you with. The only competitor I’ve ever really looked at was Google App Engine – at the time I was looking to deploy Java applications, and the amount of restrictions on usable frameworks and technologies was incredibly off-putting. This is more than “just a Java thing” – the amount of general restrictions and necessary considerations (the FAQ hints at several) seemed less than convenient. In contrast, deploying to Heroku has been a dream.


I hope this answers your questions (please comment if there are gaps / other areas you’d like addressed). I feel I should offer my personal position. I love Heroku for “quick deployments”. When I’m starting an application, and I want some cheap hosting (the Heroku free tier is awesome – essentially if you only need one web dyno and 5MB of PostgreSQL, it’s free to host an application), Heroku is my go-to position. For “Serious Production Deployment” with several paying customers, with a service-level-agreement, with dedicated time to spend on ops, et cetera, I can’t quite bring myself to offload that much control to Heroku, and then either AWS or our own servers have been the hosting platform of choice.

Ultimately, it’s about what works best for you. You say you’re “a beginner programmer” – it might just be that using Heroku will let you focus on writing Ruby, and not have to spend time getting all the other infrastructure around your code built up. I’d definitely give it a try.

Note, AWS does actually have a PaaS offering, Elastic Beanstalk, that supports Ruby, Node.js, PHP, Python, .NET and Java. I think generally most people, when they see “AWS”, jump to things like EC2 and S3 and EBS, which are definitely IaaS offerings


As Kristian Glass Said, there is no comparison between IaaS(aws) and PaaS(Heroku, EngineYard).

PaaS basically helps developers to speed the development of app,thereby saving money and most importantly innovating their applications and business instead of setting up configurations and managing things like servers and databases. Other features buying to use PaaS is the application deployment process such as agility, High Availability, Monitoring, Scale / Descale, limited need for expertise, easy deployment, and reduced cost and development time.

But still there is a dark side to PaaS which lead barrier to PaaS adoption :

  • Less Control over Server and databases
  • Costs will be very high if not governed properly
  • Premature and dubious in current day and age

Apart from above you should have enough skill set to mange you IaaS:

  • Hardware acquisition
  • Operating System
  • Server Software
  • Server Side Scripting Environment
  • Web server
  • Database Management System(Mysql, Redis etc)
  • Configure production server
  • Tool for testing and deployment
  • Monitoring App
  • High Availability
  • Load Blancing/ Http Routing
  • Service Backup Policies
  • Team Collaboration
  • Rebuild Production

If you have small scale business, PaaS will be best option for you:

  • Pay as you Go
  • Low start up cost
  • Leave the plumbing to expert
  • PaaS handles auto scaling/descaling, Load balancing, disaster recovery
  • PaaS manages all security requirements
  • PaaS manages reliability, High Availability
  • Paas manages many third party add-ons for you

It will be totally individual choice based on requirement. You can have details on my PPT Hosting Rails Apps.


There are a lot of different ways to look at this decision from development, IT, and business objectives, so don’t feel bad if it seems overwhelming. But also – don’t overthink scalability.

Think about your requirements.

I’ve engineered websites which have serviced over 8M uniques a day and delivered terabytes of video a week built on infrastructures starting at $250k in capital hardware unr by a huge $MM IT labor staff.

But I’ve also had smaller websites which were designed to generate $10-$20k per year, didn’t have very high traffic, db or processing requirements, and I ran those off a $10/mo generic hosting account without compromise.

In the future, deployment will look more like Heroku than AWS, just because of progress. There is zero value in the IT knob-turning of scaling internet infrastructures which isn’t increasingly automatable, and none of it has anything to do with the value of the product or service you are offering.

Also, keep in mind with a commercial website – scalability is what we often call a ‘good problem to have’ – although scalability issues with sites like Facebook and Twitter were very high-profile, they had zero negative effect on their success – the news might have even contributed to more signups (all press is good press).

If you have a service which is generating a 100k+ uniques a day and having scaling issues, I’d be glad to take it off your hands for you no matter what the language, db, platform, or infrastructure you are running on!

Scalability is a fixable implementation problem – not having customers is an existential issue.


Actually you can use both – you can develop an app with amazon servers ec2. Then push it (with git) to heroku for free for awhile (use heroku free tier to serve it to the public) and test it like so. It is very cost effective in comparison to rent a server, but you will have to talk with a more restrictive heroku api which is something you should think about. Source: this method was adopted for one of my online classes “Startup engineering from Coursera/Stanford by Balaji S. Srinivasan and Vijay S. Pande

Added a scheme so my explanation will be easier to understand

It’s been a significant percentage of our business migrating people from Heroku to AWS. There are advantages to both, but it’s gets messy on Heroku after a while… once you need a certain level of complexity no longer easy to maintain with Heroku’s limitations.

That said, there are increasingly options to have the ease of Heroku and the flexibility of AWS by being on AWS with great frameworks/tools.

Kendall Miller

Well, people usually ask this question: Heroku or AWS when starting to deploy something.

My experiment of using both of Heroku & AWS, here is my quick review and comparison:


  • 1 command to deploy whatever your project types: Ruby on Rails, Nodejs
  • So many 1-click to integrate plugins & third parties: It is super easy to start with something.
  • Don’t have auto scaling, that means you need to manually scale up/down
  • Cost is kind of expensive, especially, when system needs more resources
  • Free instance available
  • Free instance goes to sleep if it is inactive.
  • Data center: US & EU only
  • Can’t dive into/access to machine level
  • Don’t need to know too much about DevOps


  • This just like a machine with pre-config OS (or not), so you need to install software, library to make your website/service go online.
  • Plugin & Library need to be integrated manually, or automation script (public script & written by you)
  • Auto scaling & load balancer are the supported services, just learn how to config & integrate to your system
  • Cost is kinda cheap, depends on which services and number of hours you use it
  • There are several free hours for T2.micro instances, but usually, you will pay few dollars every month (if still using T2.micro)
  • Your free instance won’t go to sleep, available 24/7 (because you may pay for it :) )
  • Data center: around the world. Pick the region which is the best fit for you.
  • Dive into machine level. So you can enjoy it
  • Some knowledge about DevOps, but it is okay, Stackoverflow is helpful there!

AWS Elastic Beanstalk an alternative of Heroku, but cheaper

  • Elastic Beanstalk was announced as a public beta from 2010, it helps we easier to work with deployment. For detail please go here
  • Basically, Beanstalk is free, the cost you will pay will be for the services you use & number of hours of usage.
  • I use Elastic Beanstalk for a long time, and I think it can be the replacement of Heroku but cheaper!


  • Heroku: Easy at beginning, FREE instance, but expensive later
  • AWS: Not easy, free hours available, kind of cheaper, Beanstalk should be concerned to use

So in my current system, I use Heroku for staging, and Beanstalk for production!

AWS / Heroku – Both are free for small hobby projects(to start with). In Heroku you dont even need a credit card info.

Heroku is a Platform as a service, where you could use all the existing things. If you are fine with the architecture(that heroku provides), then heroku is great.


  • PAAS
  • Documentation is very good.
  • Have in built tools and architecture.
  • Limited control over architecture while designing app.
  • Heroku is best at what they provide.
  • Deployment is taken care(through git commands only).
  • Good support.
  • Not time consuming.


  • IAAS
  • AWS is versatile. They have many kinds of products. EC2, LAMBDA, EMR etc.,.
  • You can go for Dedicated instance. You have more control over the architecture. like choosing OS, Version of the sofwares, etc.,. more than one backend layers..
  • I have also used Elastic Beanstalk(AWS) which is heroku equivalent(PAAS). Still prefer Heroku to BeanStalk. BeanStalk is not free.
  • Can use the automated deployment. or have ur own.
  • Great support.


It depends on options/efforts that the developer wants to have/take.
If you want to start an app right away, without much customization of the architecture, then could choose Heroku.
If you want to build an app, and would like to focus on various things like architecture, using a different webserver, also want to use the other services that AWS provides, then you may have to choose AWS. Playing with AWS may be time consuming based on what service/product you choose but it is more than worth. AWS also comes with many services/products to plug/play.


well.. its not all that rosy..

first of all: AWS is not rocket science, and if you know your way around deploying “things” at the end of the day its better to use AWS, and cheaper .. instead of any other PaaS which tend to be always more expensive in exchange of doing “things” for you …
IMHO AWS is lot better and you have lot more control overall,

especially now when there is rightScale , bitnami, etc … and all those pre made EC2 images for so many different software stacks.


Leave a Reply