Heroku Isn't for Idiots: developer time and comparative advantage

Inaka has two clients (of many), that are particularly comparable. One used a very "cloudy" Heroku stack with SimpleDB, Ruby, Rails, and Redis. It a number of scalability problems mostly related to the different components not performing predictably under load.<p>A lot of time spent debugging this custom stack that was supposed to be seamless.<p>Another client was (boxes running on a hosted server provider),using Erlang, Riak, some Rails, deployed w/Puppet. Comparable data volume; similar "Rails w/Dynamo" architecture, but -- much, much less magic. Much smaller operations bill, less time spent working around cloud platform issues, like inconsistent IO, expensive Amazon charges, lack of visibility into what is happening behind the scenes, etc.<p>In some cases, Heroku is great; for us, particularly prototyping. But it's not always so clear when it's better to just boot some boxes and deploy some puppet or chef.

&#62; 512MB of RAM, 1GB of swap. Total = 1.5GB RAM<p>What!? Swap is considered equivalent to RAM?<p>From my experience, a single Heroku dyno performs better than a micro EC2 instance (613 RAM) but significantly worse than a small EC2 instance (1.7GB RAM). The first Heroku dyno is free, making it ideal for small sites, but as soon as you want to add anything outside of Heroku's sandbox, the prices are extremely inflated compared to AWS. For instance, adding an SSL cert to a Heroku app is $20. A small EC2 instance costs as little as $17.69 a month with 3 year buy-in (this is the average monthly cost with a 3 year heavy utilization reserved instance). Even if you pay monthly for an on-demand instance ($57.60/m) it's still much cheaper than Heroku considering you can comfortably run several services such as Redis, PostgreSQL, and Resque workers alongside your app. Each of those services will cost extra on Heroku.<p>Of course, the trade off is the relative ease of deployment. Heroku is the easiest place to deploy, until your app grows more complicated. AWS is 2nd easiest, until you need even more control over hardware configurations. The most difficult deployment is on your own hardware, but it should also be the cheapest option.

(Disclaimer: I work at one of the companies in this list).<p>In the interest of choice and healthy competition (and also in my own selfish interest, per the disclaimer above), I will point out that the arguments in this article apply to <i>all</i> good PaaS providers, of which there are plenty. As an insider in this particular crowd of vendors, I can tell you that the competition is fierce and it is entirely focused on delighting hackers - a trend which everyone here should be excited about.<p>- cloudfoundry.com/appfog/stackato/tier3 are competing deployments of the cloudfoundry open-source project by VMWare<p>- phpfog, pagodabox, orchestra: php-only<p>- engine yard: ruby-only, also the leader in revenue, probably by a wide margin ($28m)<p>- dotCloud: first multi-language paas, with a bunch of database services as well<p>- Openshift: previously Makara, now part of Red Hat. Also available open-source<p>- Djangozoom: django-only<p>- Nodejitsu, nodester, no.de: nodejs-only<p>- Cloudbees: Java only<p>- Azure: solid .Net stack, impressive database service. Didn't use it directly but I've heard it's a great product.<p>- AppHarbor: an alternate .Net provider<p>- App Engine: much more restrictive than the others, but super cohesive and a great product if you don't mind the straightjacket

My only real complaint with Heroku is that once you grow out of a basic no frills app, prices really rack up. For example I was looking to move an app I'm currently developing on a VPS to Heroku, but I use a ~200MB Redis database and just that will set me back $110/month.<p>Heroku is great if you can fit your app within the free tier and great if you're happy to spend a few hundred bucks a month, but in between those two I'm often better off with on or two $20/month 1GB VPS.

Note my bias: I am the founder of AppFog.com which deploys CloudFoundry to public clouds as a service.<p>"Heroku is Just Unix"<p>No. Heroku is not "Just Unix". This statement is completely 100% wrong. To claim that what Heroku or any other PaaS does is "just VPS" or "just Unix" is so far off. People vastly underestimate how difficult it is to run a PaaS and how much technology it takes to pull it off at scale.<p>I speak from experience, having built one PaaS from scratch and having used CloudFoundry to build a second one. The technology to get "just unix" into a fully managed, n-tier, scalable system is incredibly complex.<p>I have heard people complain that CloudFoundry is overly complex, but these people judge a piece of open source code that does something that for so long has been hidden behind the curtains. Heroku is at least as complex if not more so, you just never see that part of the equation because you don't have to.

So, I'm just a guy who makes video games. A one man operation. I'm mostly interested in interface and game design, I don't know, and don't really want to know anything about running the back end. Just the minimum to get the game running.<p>Right now I'm running my games on Google App Engine and hosting is about 10% of gross. (Don't know if that's good but it's fine by me). For me, scaling means going from 3 or 4 instances to 20 or 30 in busy times. This all "just works" and I don't have to really do anything.<p>I've been looking at Heroku because I've been working a little in node and there are some significant advantages to having js on the client and server. (rather than python on GAE)<p>I was under the impression Heroku would just work too. I may not be an Idiot, but I sure am a n00b.<p>Is Heroku not for me? Should I stick with App Engine?

my suggestion:<p>1. Rent a cheap box at <a href="http://hetzner.com" rel="nofollow">http://hetzner.com</a> (32GB RAM/59€ per month; 64GB RAM/109€ per month) or <a href="http://OVH.ca/" rel="nofollow">http://OVH.ca/</a>.<p>2. Install Proxmox VE 2.0 from <a href="http://proxmox.com/products/proxmox-ve" rel="nofollow">http://proxmox.com/products/proxmox-ve</a> Create virtual instances via RESTful API on demand: <a href="http://pve.proxmox.com/wiki/Proxmox_VE_API" rel="nofollow">http://pve.proxmox.com/wiki/Proxmox_VE_API</a><p>3. use chef or puppet.<p>=&#62; unbeatable price/value and it's up to you if/how you lock into technologies/abstractions/dynos/...

Really Heroku is a fine product but your paying a substantial cost for the service to manage <i>some</i> of the systems work. I say some because everyone using services like this should have a strategy to exit should some major event happen (prices raise, service becomes unreliable, company is acquired / folds)<p>Most of the arguments against running a dedicated server was a straw man argument. YES High Availability is expensive if your talking an app that fits on a single server, but once you can get most services running with a N+1 reliability making it substantially cheaper.<p>&#62;His harddrive / memory / NIC / etc fails?<p>Most dedicated hosting providers have an SLA to replace. Rackspace is 1 hour. If this SLA isn't suitable you setup a cluster.<p>&#62;He accidentally runs OS updates, and breaks versions of his packages?<p>Welcome to backups... you should have them. Yes its expensive, yes its a pain in the arse... but you should have them anyway even if your on heroku. Lets be professionals here.<p>&#62; He wants to instantly rollback to a previous release of his codebase?<p>Welcome to code deployment tools... Just because your not on heroku doesn't mean you can't have them<p>&#62;He wants to add another server to handle incoming HTTP requests?<p>Its called resource planning... You know what those pretty little graphs are for. Again you should be doing this regardless of the service you are on.<p>&#62; He needs to spin up a database read slave to handle a high amount of read requests?<p>See capacity planning.<p>&#62; His load balancer fails?<p>Fail to wire modules, Clustered load balancers, virtual load balancers on a cluster... many options<p>&#62; His Fabric script stops working because he renamed his project or reorganizes his application directory tree?<p>Testing... read about it... It really helps. You can also mess up any codebase by messing with the directory structure and not testing.<p>&#62; Or one of an infinite amount of other possible problems?<p>Ok... and Heroku has a bunch of other problems.<p>edit: fixed typos and Load balancer quote

What people are waiting for is a set of tools that lets them run their own "mini Heroku" across multiple IaaS providers.<p>I should be able to glue together my own cloud-based load balancer, deploying my app to webservers on different continents, with a monitored master-slave database set up -- all with freely available open-source software tools.

Heroku gets you into big trouble when their abstraction starts leaking and you need to dig deeper. If you never get to that point, this article makes sense, but when you turn that corner, expect a lot of pain.

Wow, this is awesome, so I must be an idiot. I've been playing around with Heroku with a simple NodeJS app that I don't care about the performance of for the last week. I've been scouring their website for information exactly like this and I couldn't find anything this comprehensive. Thanks so much for figuring this stuff out. Just answering the simple question of "Is the 750hr's free for each app or is it per account?" is golden.<p>Anyone have an example of a simple NodeJS worker dyno? The web one is easy, now I'd like to see the other. I've been searching around and haven't found any good examples. Thx.

I wonder where he got that great picture of Adam Wiggins.

"Yah--it isn't very hard to spin up some simple infrastructure services using Chef--pretty much anyone with a couple hours of free time can figure that out."<p>This person has obviously never touched Chef. Chef's learning curve is steeeeeep.

I have my own server that I keep in a colo for a reasonable fee; I run small sites for family members and my email off of it. However for things that actually get traffic I go to Heroku or AWS, I don't need the headaches that come with a traffic spike on my server it's just not worth the hassle.<p>git push heroku master FTW!

Thanks, but no thanks! I am happy with the control an EC2 instance gives me in return for little more complexity in handling.

We make a similar product to Heroku: Continuous Integration as a service (<a href="https://circleci.com" rel="nofollow">https://circleci.com</a>). I'm amazed at how many developers think their time is free.<p>"I can just set up Jenkins" is the CI equivalent of the behaviour the OP rants against. And you're right, if your time is free. But it isn't free, and just like Heroku handles your security, scalability and lets you get back to work, so too does hosted CI handle machine setup, test speed, optimization and parallelization, without having to manage it all yourself.<p>Long story short, developers significantly undervalue their time (and sometimes their bosses do too).

It's why it's the goto for hackathons these days.