Heroku Isn't for Idiots

I love this post, and hope it keeps coming up. Some day, developers will learn that even though they could do it as well as Heroku, given enough time and effort, it's just a lot cheaper not to!<p>This comes up all the time with my company. We make hosted Continous Integration (<a href="https://circleci.com" rel="nofollow">https://circleci.com</a>), and often hear "can't I just set up Jenkins?". And the answer is the same, "you could, but ...". Run it on EC2, where your tests fail because the IO is bad? What about when three people push at once and you want to get results ASAP? Are you going to manually compile Postgres 9.1? And again when you add a second box to you cluster?<p>I could go on.

Previous discussion here: <a href="http://news.ycombinator.com/item?id=4062364" rel="nofollow">http://news.ycombinator.com/item?id=4062364</a>

I'd love to see an example of someone saying Heroku is for idiots. Although it's a bit pricey[1], I love it to pieces because it lets me focus on what I like to do: shipping product.<p>That said, I'd be delighted if Heroku would introduce a high-memory dyno. I've been working on something for the past few days where their soft'ish 512MB cap has been biting me in the ass.<p>[1] Assuming you value your time at something around $0/hour.<p>edit: thanks for the link!

This is just like the garbage collection versus manual memory management debate.

I also save significant time and money using Heroku and it's awesome being able to scale up and down automatically using HireFireApp. Most of this article rings true with my experience however some of it doesn't feel that valid for me having a high volume NodeJS app, not to mention the entire "Let's talk about bad ideas" section is just lame.<p>1) If your app crashes it takes <i>ages</i> to restart dynos "automatically", there's nothing at all instant about it and if it's a bug and you have a high volume of requests it's going to hit every dyno which means you are offline.<p>2) Performance can be variable and it can be hard to be sure an optimization has done anything. This will be easier when New Relic supports NodeJS but right now you're stuck using less elegant solutions. It is shared hosting and it's not necessarily anybody's fault if something is slow, and I know this because the same requests frequently have orders of magnitude difference in response time for me.<p><pre><code> dyno=web.10 queue=0 wait=0ms service=3ms status=200 bytes=25 dyno=web.7 queue=0 wait=0ms service=207ms status=200 bytes=28 </code></pre> Between Heroku and NodeJS I run my API server usually on just 8 dynos doing 6,000 - 10,000 requests per second and having come from C# and dedicated Windows servers it is a dream - nothing to maintain and easy deployment and easy debugging on Heroku's side, and NodeJS is just amazing once you start realizing what's possible with it.

&#60;quote&#62; Heroku is Just Unix<p>At its core, Heroku is just a simple unix platform; specifically, Ubuntu 10.04 LTS. &#60;/quote&#62;<p>I just threw up a little

"Each instance (Heroku calls them dynos), has:<p>512MB of RAM, 1GB of swap. Total = 1.5GB RAM. 4 CPU cores (Intel Xeon X5550 @ 2.67GHz)."<p>That is very interesting. So you get 200% of the CPU from a c1.medium but only 1/6 that memory? For 1/8 the price that Amazon charges? Maybe this is a the new math I keep hearing about.

Honest question: Why do startups continue to setup their own infrastructure on AWS with ops? Scaling? Cost?

"Heroku Isn't for Idiots " But going by current trends there could soon be a "Heroku for Idiots" :-)