1172

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.

Anna S
  • 157
  • 1
  • 9
Bryan
  • 11,925
  • 4
  • 15
  • 12
  • 297
    I actually use it because of the free plan ;). – weddingcakes Dec 28 '12 at 14:18
  • 62
    You should have asked whats the difference between Heroku and AWS elastic beanstalk.. Otherwise you'll get the usual "PaaS vs IaaS" answers, not what you are probably looking for. – Jus12 Oct 04 '13 at 08:53
  • 43
    develop on heroku, scale it on heroku, innovate on heroku...then once idea is the business hit then transfer to aws...like when you are hiring. – Muhammad Umer Jul 18 '14 at 05:21
  • 12
    It may be difficult to migrate once you are using a few services and need to trasfer, configure, test everything... It will definetly have a cost – Paolo Mar 29 '15 at 16:25
  • 41
    One of my favorite things about Heroku is it auto-deploys from Github, so I can have a `production` branch on my repo. Whenever a new commit is pushed to that repo, Heroku automatically grabs it, builds it, and deploys it. I don't need to worry about anything server-side at all! – Razi Shaban May 02 '15 at 01:47
  • @RaziShaban In case of any error while deploying your commit what Heroku does? How they handle it? – Shivang Agarwal Mar 29 '18 at 05:30
  • 4
    @ShivangAgarwal Heroku deploys whatever I write. Quality-control is the user's responsibility. – Razi Shaban Mar 30 '18 at 18:56
  • 1
    For what it's worth, we utilized AWS ElasticBeanstalk but found dealing with capistrano/puppet/chef scripts to restart our servers and deal with bizarre things where servers would crash or not connect after restart became such a pain and detriment to productivity, managing and installing add-ons also became a chore. We still have a lot on AWS, but all of our web servers are maintained on Heroku, and what extra we're paying for Heroku we're saving on not needing a dedicated DevOps person. Obviously you need to ensure everything's secure, but it's mostly fire and forget, so we can focus on code – Michael Apr 13 '18 at 20:05
  • 1
    Look it like this: why do people go to restaurants when there is cheaper food in the market? Sometimes you need the service already prearranged for you. Sorry if it sounds off topic. – Jesús Flores May 30 '18 at 14:58
  • 1
    > Heroku's physical infrastructure is hosted and managed within Amazon's secure data centers and utilize the Amazon Web Service (AWS) technology. Amazon continually manages risk and undergoes recurring assessments to ensure compliance with industry standards. Amazon's data center operations have been accredited under... From https://www.heroku.com/policy/security – Sista Fiolen Dec 23 '18 at 13:19
  • Heroku is perfect for focusing on what you are building and get free of infrastructure management. Even if AWS makes complete abstraction of servers and networks, you still need to dig into the details and know how things work. This is the main difference between PaaS (Heroku) and IaaS (AWS). But today, there is a new generation of platforms like https://www.qovery.com - where you have the best of both worlds. Meaning, the simplicity of Heroku on top of your AWS account. – eVoxmusic Sep 16 '21 at 19:59
  • I use Heroku partly because [Matz works there](https://blog.heroku.com/matz_joins_heroku) – Tun Oct 01 '21 at 10:35
  • A simple summary is that Heroku is an EZ solution for simple cases. It's utterly useless for real major scaled sites. No major properties run on Heroku. AWS rules. There's no contest of any type between the two. The only contest is between AWS and Google Services, and for now AWS utterly crushes them. (Note that all of Heroku is nothing more than a company running on AWS! :) It would be inconceivable to have Heroku running "on Heroku".) – Fattie Sep 15 '22 at 19:55

15 Answers15

2149

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:

Speed

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.

Security

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.

Scaling

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 Heroku Architecture - The 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.

Conclusion

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

Abdullah Khawer
  • 4,461
  • 4
  • 29
  • 66
Kristian Glass
  • 37,325
  • 7
  • 45
  • 73
  • 2
    This is a great answer for any question but for something that many people look on as flame bait it is simply glorious. – nasmorn Nov 13 '12 at 20:30
  • 37
    Note that now elastic beanstalk fully supports ruby apps behind passenger. – rewritten Nov 26 '12 at 16:19
  • 5
    Heroku now also supports servers in the EU not just the US region. – Thomas Welton Jul 01 '13 at 15:43
  • Also : I don't think Dyno can be compared with Micro instances. A Dyno is not multithreaded which mean it can only serve one request at the time. – Roch Aug 12 '13 at 12:46
  • 2
    @Roch A Dyno is perfectly capable of running processes with multiple threads (with a limit of 256 {processes and threads} - https://devcenter.heroku.com/articles/dynos#processes); I suspect you've hit some limitation/failure of your app... – Kristian Glass Aug 12 '13 at 15:28
  • Just noticed Heroku uses AWS at the base level... – CodeMonkey Oct 17 '13 at 21:37
  • 8
    Given AWS BeanStalk, isn't the entire discussion on how Heroku is a PaaS solution while AWS is "just" an IaaS offering stand invalidated? – Gmu Jan 03 '14 at 23:39
  • 6
    @KristianGlass It would be awesome if we could get an updated answer that really looks at the two PaaS offerings (Beanstalk and Heroku) –  Jan 05 '14 at 19:15
  • 3
    Glad this has been useful to people :) @Gmu At the time of answering, EB was sufficiently limited that assuming "AWS" meant "EC2" seemed quite reasonable, but as Alex suggests, I'll look at re-answering now EB has improved significantly. – Kristian Glass Jan 06 '14 at 14:52
  • thanks Kristian, look forward to and appreciate an updated comparison- very timely for my case. – Gmu Jan 08 '14 at 01:02
  • Now that Google has GCE it would be interesting to see an update to the "competition" topic. – Paulo Scardine Jan 13 '14 at 23:38
  • 1
    Note that AWS Elastic Beanstalk now supports the following : "Apache HTTP Server for Node.js, PHP and Python, Passenger for Ruby, IIS 7.5 for .NET, and Apache Tomcat for Java" ([source 1](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/GettingStarted.Walkthrough.html#GettingStarted.Walkthrough.DeployApp), [source 2](http://aws.amazon.com/elasticbeanstalk/)) – Simon Jan 15 '14 at 09:52
  • To add to the discussion pointing to a blog which I recently wrote on this topic: http://notingon.com/2014/02/07/your-cloud-platform-iaas-paas-and-the-providers/ – Sony Kadavan Feb 14 '14 at 18:13
  • Amazing answer, @Kristian. So - is cloudFlare.com for example, also "a competitor to Heroku and ElasticBeanstalk? Or ... is that something different again?! – Fattie Jun 22 '14 at 11:35
  • 1
    Thanks @JoeBlow ! CloudFlare is completely different; it's a CDN (https://en.wikipedia.org/wiki/Content_delivery_network) much like Akamai or Amazon CloudFront, which you effectively put "in front of" your content to assist in delivery (rather than "somewhere you run your software") – Kristian Glass Jun 22 '14 at 19:08
  • 1
    Amazon Elastic Beanstalk supports nowdays Java, .NET, PHP, Node.js, Python, Ruby, and Docker – Maksim Luzik Sep 16 '14 at 07:46
  • Problem: Google app engine locks you into everything. What happened to django? – noɥʇʎԀʎzɐɹƆ Jun 21 '15 at 21:45
  • 1
    Conclusion: Use AWS for anything real. – Hal50000 Mar 22 '16 at 02:53
  • 1
    You may like to know there is a direct competitor to Heroku, providing the same service and whose infrastructure uses the same protocol for buildpacks: https://scalingo.com – Nowhere man Jun 04 '16 at 02:06
  • AWS Lambda is serverless and would qualify as PaaS. Auto-Scaling means you don't need Puppet to spin up/down instances. – rob2universe May 31 '18 at 01:18
  • So does Heroku itself run on AWS? – Jared Nielsen Oct 18 '19 at 18:45
  • AWS (select services combined) is also a PaaS, not just IaaS. – Anjan Biswas Oct 21 '19 at 15:38
  • Heroku [won't have a free tier starting 11/28/22](https://blog.heroku.com/next-chapter). – ggorlen Aug 25 '22 at 19:35
  • The first sentence here is **completely wrong and totally misguided**. There's no such clear distinction between the two acronyms mentioned. Also, as an almost regular matter, yearly or more often, AWS and the others introduce utterly amazing new services which are such a paradigm change that acronyms from 10 yrs ago don't even apply. – Fattie Sep 15 '22 at 19:52
286

AWS / Heroku are both free for small hobby projects (to start with).

If you want to start an app right away, without much customization of the architecture, then choose Heroku.

If you want to focus on the architecture and to be able to use different web servers, then choose AWS. AWS is more time-consuming based on what service/product you choose, but can be worth it. AWS also comes with many plugin services and products.

Heroku

  • Platform as a Service (PAAS)
  • Good documentation
  • Has built-in tools and architecture.
  • Limited control over architecture while designing the app.
  • Deployment is taken care of (automatic via GitHub or manual via git commands or CLI).
  • Not time consuming.

AWS

  • Infrastructure as a Service (IAAS)
  • Versatile - has many products such as EC2, LAMBDA, EMR, etc.
  • Can use a Dedicated instance for more control over the architecture, such as choosing the OS, software version, etc. There is more than one backend layer.
  • Elastic Beanstalk is a feature similar to Heroku's PAAS.
  • Can use the automated deployment, or roll your own.
Arsen Khachaturyan
  • 7,904
  • 4
  • 42
  • 42
SuperNova
  • 25,512
  • 7
  • 93
  • 64
  • 11
    ElasticBeanstalk is far more cost effective than Heroku as there is no markup for the service beyond the servers you use. You can also use ElasticBeanstalk with the AWS free tier https://aws.amazon.com/elasticbeanstalk/pricing/ – Zags Feb 10 '17 at 22:03
  • 33
    @Zags "cost effective" is a matter of opinion. If I can create and deploy a Heroku app in less than a minute and it takes potentially hours to setup Beanstalk -- that isn't cost effective considering several hour of developer time destroys any "savings" one might have from Beanstalk. It really depends on priorities -- is shipping features more important or is setting up and maintaining infrastructure more important? – Brian Dear Mar 03 '17 at 12:25
  • 6
    @BrianDear ease of setup depends on your familiarity with the various systems. Even if ElasticBeanstalk takes longer to set up given equal familiarity, AWS is typically 60% the cost of Heroku (compare a Heruku performance-m to an AWS m4.xlarge). With a server bill is as low as $100/month, a 40% savings will recover the cost of "several hours of engineerng" within a year. The higher the server bill, the stronger the argument for AWS. – Zags Mar 07 '17 at 19:21
  • 4
    It takes ~5 minutes to deploy on Beanstalk. Choose platform -> Upload zip -> Rejoice. Want to deploy by pushing to master? Spend another 5 minutes setting up CodePipeline. Both of these workflows can be done using just the GUI console if the CLI is intimidating for you. – Anthony Manning-Franklin Oct 15 '17 at 16:43
  • 1
    Unfortunately, documenation is not listed under AWS. AWS has one of the best documentation of any technology/platform. I had used it even before this answer was posted, circa 2013. – lupchiazoem May 15 '18 at 07:45
76

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.

simhumileco
  • 31,877
  • 16
  • 137
  • 115
Pravin Mishra
  • 8,298
  • 4
  • 36
  • 49
  • 3
    I see EngineYard and Heroku, and of course ElasticBeanstalk ... all run on AWS underneath. In fact, **are there any major PaaS which do NOT run on aws underneath?** Any ideas? Cheers – Fattie Jun 22 '14 at 11:41
  • 5
    Joe, I know this is late, but to answer your question IBM Bluemix runs on SoftLayer. – Antonio Cangiano Nov 20 '14 at 22:42
  • *PaaS manages all security requirements* Securing the server, perhaps, but highly misleading (especially in a world where developers seem to assume their system is secure by default). It's certainly not going to protect you from XSS, CSRF, and probably won't be setting any important HTTP headers for you. I can just see it now: `Thank you for your concerns. We assure you that we take security very seriously and run or systems on secure servers. There is no need to worry about [insert security issue here] as all that is handled by...`. -1 but I'd reverse it if properly edited. – Nateowami Oct 07 '16 at 09:23
  • 4
    There is increasingly a category of PaaS solutions (DIY PaaS) that work on your own infrastructure thus addressing some of the concerns with PaaS flexbility/control. Some examples: [openshift](https://www.openshift.com), [cloudfoundry](https://www.cloudfoundry.org/), [Hasura](https://hasura.io). Disclaimer: I work at Hasura. – iamnat Mar 16 '17 at 12:28
37

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.

BricoleurDev
  • 827
  • 9
  • 14
36

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

sivi
  • 10,654
  • 2
  • 52
  • 51
  • 19
    What's the benefit of using the micro instance as a development machine, instead of using your local computer ? I don't see the added benefit of adding the AWS on this particular case. Thanks! – Mateo Feb 16 '15 at 23:03
  • 6
    probably because in an academic setting it will make it so the instructions for setting up the dev environment more consistent and they don't have to worry about making it work on windows – Jeff Dickey Feb 17 '15 at 19:17
  • 2
    That architecture helps to avoid a lot of the Windows/Linux OS dis-compatibilities. And also learn the Linux OS without having to install it on your local machine. If you have a Mac it is a less of an issue but many people use Windows. – sivi Feb 18 '15 at 09:24
  • 14
    It's called a virtual machine, I still don't see much point in doing this. – Abe Petrillo Feb 25 '15 at 15:59
  • 1
    The benfit that moving between production and development is much faster. And you already dealing with TVE remote issues un the development stage. Also if you dont want a certain setup you can build it on the cloud. There are many benefits in that. – sivi Mar 04 '15 at 16:34
  • 2
    @sivi: or, you could just use [Cloud9](https://c9.io) for cloud development. – Nuclearman Sep 29 '16 at 01:49
  • 3
    Having a separate platform for staging and production is a super terrible idea; major software versions are going to differ in incompatible ways. You should be able to run your code locally for development, even if the native OS differs from the production OS (at worst case with something like VMware or vagrant or with an emulator if building for an embedded platform; but natively is generally easier to work with). Only ever being able to deploy code remotely to the cloud is a horrible hurdle to rapid application development that makes testing and debugging unnecessarily time consuming. – Iain Collins Jan 12 '17 at 07:40
  • 1
    Except for a nice diagram, I don't see any point here. – nehem May 15 '17 at 06:47
  • 1
    That you no point does not mean there is no. This is an example for someone that is not you specifically. I'm pretty sure there are many things in this world that you see no point in, yet they have some logic. The attitude that one should see point to validate it for anyone else -- that is, that someone knows everything is misleading.Obivously some other users did find it helpful so it makes your comment even more whimsical – sivi May 16 '17 at 07:50
30

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:

Heroku

  • One 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 scale up/down manually
  • Cost is expensive, especially, when system needs more resources
  • Free instance available
  • The free instance goes to sleep if it is inactive.
  • Data center: US & EU only
  • CAN dive into/access to machine level by using Heroku run bash (Thanks, MJafar Mash for the advice) but it is kind of limited! You don't have full access!
  • Don't need to know too much about DevOps

AWS - EC2

  • 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 quite 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

  • 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 and cheaper!

Summary

  • 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!

Hieu Pham
  • 6,577
  • 2
  • 30
  • 50
  • 3
    I like the way you answer the question. I've tried Heroku and AWS. I agree with you to recommend: `Use Heroku for staging, and Beanstalk for production!` – eQ19 Jul 01 '16 at 20:04
  • 1
    `heroku run bash` and you have shell access to your dyno – Mohammad Jafar Mashhadi Aug 08 '16 at 06:41
  • Can you give some prices estimation? i'll have to publish Java Web App on Tomcat (Spring framework, angularJS etc.), let's think about 1000 users a month, each using app for 5 minutes. What's the estimated price? (like very low usage, but availability for full month) – razor Sep 01 '16 at 10:46
  • 1
    @razor if you use t2 micro instance (good for pre-production or small project), the price is so cheap, it is about 5$ to 10$ per month as my memory in the previous project. The detail here https://aws.amazon.com/ec2/pricing/ – Hieu Pham Sep 01 '16 at 11:46
  • and Heroku will be much more expensive? (2 times?) with simiar usage ? i know the pricing pages, but it's hard to calculate/imagine how much CPU power such a simple app will take or what will be the DB usage after a months (DB will be quite small of cource) – razor Sep 02 '16 at 13:54
  • @razor If you don't want your server is 24/7 available, Heroku will be a good choice (free), so you enable to run 1 webserver + 1 background server, the fee will be 14$/month. AWS doesn't offer free instance, but the price is cheaper actually, under the hook, heroku uses AWS server to run their instance, so you know what I mean – Hieu Pham Sep 03 '16 at 02:15
  • ok, thanks. i thought that maybe using just 5% of CPU for an hour, means i've used 5% of an hour, but it looks likes it's just 'an hour'. i'll stick to AWS EC2, as i need a simple webapp but being available all the time. – razor Sep 07 '16 at 15:16
29

The existing answers are broadly accurate:

  • Heroku is very easy to use and deploy to, can be easily configured for auto-deployment a repository (eg GitHub), has lots of third party add-ons and charges more per instance.

  • AWS has a wider range of competitively priced first party services including DNS, load balancing, cheap file storage and has enterprise features like being able to define security policies.

For the tl;dr skip to the end of this post.

AWS ElasticBeanstalk is an attempt to provide a Heroku-like autoscaling and easy deployment platform. As it uses EC2 instances (which it creates automatically) EB servers can do everything any other EC2 instance can do and it's cheap to run.

Deployment with EB is very slow; deploying an update can take 10-15 minutes per server and deploying to a larger cluster can take the best part of an hour - compared to just seconds to deploy an update on Heroku. Deployments on EB are not handled particularly seamlessly either, which may impose constraints on application design.

You can use all the services ElasticBeanstalk uses behind the scenes to build your own bespoke system (with CodeDeploy, Elastic Load Balancer, Auto Scaling Groups - and CodeCommit, CodeBuild and CodePipeline if you want to go all in) but you can definitely spend a good couple of weeks setting it up the the first time as it's fairly convoluted and slightly tricker than just configuring things in EC2.

AWS Lightsail offers a competitively priced hosting option, but doesn't help with deployment or scaling - it's really just a wrapper for their EC2 offering (but costs much more). It lets you automatically run a bash script on initial setup, which is nice touch but it's pricy compared to the cost of just setting up an EC2 instance (which you can also do programmatically).

Some thoughts on comparing (to try and answer the questions, albeit in a roundabout way):

  1. Don't underestimate how much work system administration is, including keeping everything you have installed up to date with security patches (and occasional OS updates).

  2. Don't underestimate how much of a benefit automatic deployment, auto-scaling, and SSL provisioning and configuration are.

    Automatic deployment when you update your Git repository is effortless with Heroku. It is near instant, graceful so there are no outages for end users and can be set to update only if the tests / Continuous Integration passes so you don't break your site if you deploy broken code.

    You can also use ElasticBeanstalk for automatic deployment, but be prepared to spend a week setting that up the first time - you may have to change how you deploy and build assets (like CSS and JS) to work with how ElasticBeanstalk handles deployments or build logic into your app to handle deployments.

    Be aware in estimating costs that for seamless deployment with no outage on EB you need to run multiple instances - EB rolls out updates to each server individually so that your service is not degraded - where as Heroku spins up a new dyno for you and just deprecates the old service until all the requests to it are done being handled (then it deletes it).

    Interestingly, the hosting cost of running multiple servers with EB can be cheaper than a single Heroku instance, especially once you include the cost of add-ons.

Some other issues not specifically asked about, but raised by other answers:

  1. Using a different provider for production and development is a bad idea.

    I am cringing that people are suggesting this. While ideally code should run just fine on any reasonable platform so it's as portable as possible, versions of software on each host will vary greatly and just because code runs in staging doesn't mean it will run in production (e.g. major Node.js/Ruby/Python/PHP/Perl versions can differ in ways that make code incompatible, often in silent ways that might not be caught even if you have decent test coverage).

    What is a good idea is to leverage something like Heroku for prototyping, smaller projects and microsites - so you can build and deploy things quickly without investing a lot of time in configuration and maintenance.

    Be sure to factor in the cost of running both production and pre-production instances when making that decision, not forgetting the cost of replicating the entire environment (including third party services such as data stores / add ons, installing and configuring SSL, etc).

  2. If using AWS, be wary of AWS pre-configured instances from vendors like Bitnami - they are a security nightmare. They can expose lots of notoriously vulnerable applications by default without mentioning it in the description.

    Consider instead just using a well supported mainstream distribution, such as Ubuntu or Debian (or CentOS if you need RPM support).

    Note: Amazon offer have their own distribution called Amazon Linux, which uses RPM, but it's EC2 specific and less well supported by third party/open source software.

  3. You could also setup an EC2 instance on AWS (or Lightsail) and configure with something like flynn or dokku on it - on which you could then deploy multiple sites easily, which can be worth it if you maintain a lot of services or want to be able to spin up new things easily. However getting it set up is not as automagic as just using Heroku and you can end up spending a lot of time configuring and maintaining it (to the point I've found deploying using Amazon clustering and Docker Swarm to be easier than setting them up; YMMV).

I have used AWS EC instances (alone and in clusters), Elastic Beanstalk and Lightsail and Heroku at the same time depending on the needs of the project I'm working on.

I hate spending time configuring services but my Heroku bill would be thousands per year if I used it for everything and AWS works out a fraction of the cost.

tl;dr

If money was never an issue I'd use Heroku for almost everything as it's a huge timesaver - but I'd still want to use AWS for more complicated projects where I need the flexibility and more advanced services that Heroku doesn't offer.

The ideal scenario for me would be if ElasticBeanstalk just worked more like Heroku - i.e. with easier configuration and quicker and a better deployment mechanism.

An example of a service that is almost this is now.sh, which actually uses AWS behind the scenes, but makes deployments and clustering as easy as it is on Heroku (with automatic SSL, DNS, graceful deployments, super-easy cluster setup and management).

I've used it quite lot for both Node.js app and Docker image deployments, the major caveat is the instances are shared (something reflected in their lower cost) and currently no option to buy dedicated instances. However their open source deployment tool 'now' can also be used to deploy to dedicated instances on AWS as well as Google Cloud and Azure.

Iain Collins
  • 6,774
  • 3
  • 43
  • 43
8

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
  • 81
  • 1
  • 1
  • Can you give some prices estimation? i'll have to publish Java Web App on Tomcat (Spring framework, angularJS etc.), let's think about 1000 users a month, each using app for 5 minutes. What's the estimated price? (like very low usage, but availability for full month) – razor Sep 01 '16 at 10:48
4

Funny thing is Heroku actually uses AWS on the backend. It takes away all the overhead and does architecture management on EC2 for you. (Got that knowledge from a senior engineer at a Big Company during an Interview)

Saurav Prakash
  • 1,177
  • 1
  • 11
  • 25
2

Well Heroku uses AWS in background, it all depends on the type of solution you need. If you are a core linux and devops guy you are not worried about creating vm from scratch like selecting ami choosing palcement options etc, you can go with AWS. If you want to do things on surface level without having those nettigrities you can go with heroku.

prasoon
  • 901
  • 8
  • 25
  • Actually, the critical part here is that the Heroku does not require an educated Cloud Admin person. Any developer can add/scale/remove hosts from Heroku. – mirik Jul 03 '23 at 07:44
1

Well! I observer Heroku is famous in budding and newly born developers while AWS has advanced developer persona. DigitalOcean is also a major player in this ground. Cloudways has made it much easy to create Lamp stack in a click on DigitalOcean and AWS. Having all services and packages updates in a click is far better than doing all thing manually.

You can check out completely here: How to Host PHP on Amazon AWS EC2

Abdullah Khawer
  • 4,461
  • 4
  • 29
  • 66
Shahroze Nawaz
  • 589
  • 5
  • 9
1

Sometimes, I wonder why people compare AWS to Heroku. AWS is an IAAS( infrastructure as a service) it clearly speaks how robust and calculative the system is. Heroku, on the other hand, is just a SAAS, it is basically just one fraction of AWS services. So why struggle with setting up AWS when you can ship your first product to the prime using Heroku.

Heroku is free, simple and easy to deploy almost all types of stacks to the web. Heroku is specifically built to bypass all the hassles of shipping your application to a live server in less than no time.

Nevertheless, you may want to deploy your application using any of the tutorials from both parties and compare

AWS DOCS and Heroku Docs

Sammy Joseph
  • 51
  • 3
1

Even though both AWS and Heroku are cloud platforms, they are different as AWS is IaaS and Heroku is PaaS

P.W
  • 26,289
  • 6
  • 39
  • 76
Gopinath J
  • 11
  • 2
0

Amazon Web Services (AWS) offers lots of services from IaaS to PaaS with assured 99.9999999% durability and availability of data and infrastructure. AWS offers infrastructure automation along with several tools for developers to pipeline their application deployment process.

On the other hand, Heroku is just PaaS which offers services to manage your platform on their cloud. It nowhere stands with AWS whether it is infrastructure or security.

simhumileco
  • 31,877
  • 16
  • 137
  • 115
Prash
  • 558
  • 5
  • 8
0

Heroku is like subset of AWS. It is just platform as a service, while AWS can be implemented as anything and at any level.

The implementation depends on what the business requirement. If it fits in either, use accordingly.

Krunal Barot
  • 914
  • 6
  • 17