We switched over to these shortly after they were available. The primary solution to the technical problem facing Rails apps on Heroku (made broadly known by the excellent Rap Genius blog posts) was to switch from the stock 'thin' web server to 'unicorn' or similar web server. 2X dynos make this solution even more effective, by providing two times the RAM which allows you to run more unicorn workers per process (e.g. from 2 to 4 for us) and have allowed us to reduce our Heroku bill by a couple hundred dollars a month. On top of that, the double CPU share means that workers will generally return the same results faster. It's sort of a no-brainer for Rails apps.

The other big win for us on Heroku recently was that Adept Scale came out of beta, which is a Heroku add-on which will monitor your traffic levels, response times, and related error rates and automatically scale up your dynos as needed. I'm not really sure why this isn't a core feature of the Heroku platform. We pay $36/mo. for Adept Scale, but they save us probably $200/mo, at least.

So how do you handle slow clients? since Heroku doesn't do any caching and Unicorn is designed to server fast clients only.

a worker is a process in this case?

Yeah, I was a little confused by this at first because Heroku also has "workers" which are dynos provisioned to churn through queued background jobs, but unicorn "workers" are totally different: They're processes forked within the web dyno so a single server can process requests concurrently. Each forked process has the entire memory footprint of the Rails app (about 200-250 MB for us), so the more memory you have the more forked processes you can run on a single dyno.

This reduces H12 errors because the more concurrency you have in a single process the less likely it is that Heroku's random routing layer is going to send a request to a dyno that is unable to handle the request because it's busy handling another long running request. As long as long running requests are the exception and not the rule, this should solve the problem.

There's also HireFire, which has support for scaling all your Heroku process types, not just your web processes: http://hirefire.io/ .

I've used them for a few projects which honestly have never actually needed auto-scaling, but they're very easy to use overall and at $10/month are way underpriced. They do have a slower polling frequency (1 minute instead of 15 seconds) though.

HireFire is fantastic (can't recommend it enough for people using Heroku). We use it at backstitch (http://backstit.ch) and it has saved us a ton of cash early-on.

These cost $0.10 per instance hour. AWS Small instances, which have 1.7GB of memory, cost $0.06 per instance hour.

Edit: corrected.

Heroku has always cost more than raw EC2 because it does more.

How about Elastic Beanstalk? It seems like that's still cheaper than Heroku, especially when you start to scale up the dynos.

AWS sells convenience at a huge markup. Heroku also sells convenience, and (for what it does) a lot more of it than Amazon.

When and where that convenience is worth it depends entirely on you, personally I cannot imagine building directly on servers again without a very good reason.

Azure is $0.06 per instance hour too for their small (1.75GB).

A whole 1.7MB of memory!

And it's still horrendously expensive...

Thanks to Heroku, my startup pays $0/year for a sysadmin/devops team.

I can't agree enough (with the sentiment about savings, though I guess I also agree that you pay $0/year for sysadmins).

I think we must have a collective blind spot here - we're so excited to save money by renting virtual servers by the hour with AWS, but not so excited to save money by not having to hire sysadmins.

Not quite. Your pricing for ops is just included in the price of your Heroku deployment.

Could you elaborate? I used to think Heroku was a premium "managed" service with pricing to match, and I paid for it because I really didn't want to think about servers, routing, etc. etc. But I just recently provisioned a small "cloud server" (their name, not mine) from Rackspace and while I was in there I decided to price out a comparable setup to what we have with Heroku and I found that the pricing was pretty comparable, and I like Heroku's horizontal scalability (and how much of the stack they manage for us) much better.

We've been taking advantage of these from the day they went beta. It's a shame they're finally switching on the full price, we had quite a savings in the interim (they had been priced at the same level as "1X" dynos during the beta period, the last few months).

Our apps (Rails) tend not to be incredibly hogging, so we've been running 8-9 Unicorn workers per dyno, depending on the app, up from 4, and it's worked fantastically. With one app, we were able to scale down from 12 to 6 dynos, which helps with the routing mesh "issue" that begins to really present itself with that many dynos.

Per aculver's post, I'll have to take a look at Adept Scale - it sounds killer.

Can we have a price drop of the "Small" dyno then? I can pay for both a Cloud66 account and a Digital Ocean 1GB box for less than a single Heroku dyno. Im on the edge of switching, but I do really like Heroku and would prefer not to.

I'm a bit surprised that Heroku doesn't give you the option to do bigger instances on EC2. It seems incredibly obvious that in many cases, going vertical makes a lot of sense and can be cheaper than going horizontal.

This is exactly what 2X dynos do. They've also mentioned - somewhere, having trouble finding it - that they're exploring further scaling (ie. "3X", "4X", etc.).

EDIT: Here's the mention of "4X" dynos - in the "FAQ". https://blog.heroku.com/archives/2013/4/5/2x-dynos-beta

Its frustrating that they do this while also stealthily changing the price structure for new users (and who knows when for legacy)