Look at Heroku first when designing a web application
April 15, 2013

Look at Heroku first when designing a web application

David Hart | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User

Overall Satisfaction

  • Very easy to use platform as a service. If you are running a node.js application, the only thing you need to do is to specify the node and npm versions in your package.json and be sure that you are referencing the port provided in your environment rather than hard-coding a port number.
  • Really good set of partners. It's easy to try out a wide range of partner applications from within the Heroku environment. Most have a free trial option.
  • Single management console for your application. You can access the administrative function for any application from within Heroku.
  • For node.js, the platform does not support websockets and because you do not have sticky sessions, it is virtually impossible to do any socket.io applications if you want to run multiple dynos. There is an add-on that will allow you to do push style APIs, but one of the benefits of using node.js is its natural support for this programming model.
  • It would be really nice if you could configure your application to spread dynos across multiple availability zones and control this. Heroku runs on top of AWS in the US EAST region. We run all of our other services there as well. For many of these services, we are able to create a scenario where we have a master-slave configuration across different availability zones (i.e. Amazon data centers). I wish we could do that with Heroku.
  • Platform as a service is an absolutely unbeatable way to build out a scalable web application with minimial up front investment. When I compare building out on Heroku to building out on AWS with RightScale, Chef, or Putty, I think that it is an order of magnitude faster. And those options are at least an order of magnitude faster and cheaper than building your own server cluster.
  • Heroku also provides a very reliable production environment that dramatically reduces any ongoing operational cost from a manpower perspective. You would have to have a very large production environment to reach the point where the incremental expense that you pay for the platform as a service is greater than the cost of hiring a devops engineer to create/manage an equivalent capability.
  • The other big benefit is the rapid deployment of test systems.
The primary alternatives I considered were running our own images directly on top of Amazon Web Services and Nodejitsu in conjunction with Joyent hosting.

The big advantage of Heroku over a direct AWS implementation is that you don't have to mess with the web dispatcher tier of the application at all. Doing a scalable web application on AWS is a well-known configuration, but it is a bit of a grind to set everything up and have it switch over when you upgrade your application tier automatically. With Heroku, it's automatic. For a small startup, time is your most precious resource so having this done for me was invaluable.

I chose Heroku over Nodejitsu/Joyent primarily because of maturity. I will definitely be keeping my eye on them in the future though. At the time of the decision, my biggest show-stopper was that we could not do custom SSL without jumping up to a dedicated environment. This may have changed since then.
We will stay with Heroku until we either outgrow it or a better platform becomes available. The great thing about this environment is that I didn't have to make major changes in the application so I'm not locked into it.

Product Usage

1 - Engineering/IT
  • We run our production application servers on top of Heroku.
  • We also run a number of test applications in Heroku mostly using a configuration with just one dyno (i.e. free). Many of the third-party services we use also provide scaled down free options, so we can set up very small test sites for little or no cost.


The one thing that I would recommend is that once you have established the add-ons that you want to use, set up a separate account with those vendors rather than doing it through Heroku. The cost is the same, but doing it with the partner lets you consolidate management of multiple applications and may give you some additional capabilities in the console.


Very easy to learn. Your best bet is to just jump in with the Hello World application in your language of choice.


I've honestly never had the need to contact their support, so this is just based on the documentation. I would call the documentation usable but not fantastic.


Easy to use web based console and easy to use command line tools; deployment is done directly from a GIT repository. What more could you ask for?

The one thing that keeps me from giving it a 10 is that custom build packs are almost incomprehensible. We used one for a while because we needed cairo graphics processing. Fortunately, I was able to figure out a different way to do what we needed so that we could get off the custom build pack.


Heroku availability correlates pretty strongly to AWS US EAST availability. We had a couple of times where there was a Heroku-specific issue but not for the last 7-8 months.
The only issue that I ever have is that about 1 out of 20 deployments (git push) will hang and need to be cancelled and done again.