Hacker News Reader

Comment by jacquesm | Hacker News Reader

That's actually really cool. I'm not ruby/rails user, but if I were I would certainly use Heroku, it is one of the YC backed companies that really stand out for me.

From the design of their website to the naming schemes, the price points and so on it all seems to be equally well thought out.

Back when considering which platform to try next (python/django or ruby/rails) I was very impressed with the way they did their best to minimize the surprise factor and to really inform the user up front of what they're getting in to.

The documentation is also excellent. I still don't know if I made the right choice, but I'm a bit too far in to django now to easily back out again so I guess I'll stick to it, but to see Heroku has now found very solid financing is definitely a factor to consider.

View on HN

In case you want to take the Rails plunge, my Ruby on Rails Tutorial book is available online at http://www.railstutorial.org/book, and it uses Heroku starting in Chapter 1 (i.e., http://www.railstutorial.org/book#sec:deploying). Three years ago (when my first Rails book came out), covering deployment in the first chapter would have been unthinkable, but with Heroku the unthinkable becomes

  $ git init && git add . && git commit -m "init"
  $ heroku create
  $ git push heroku master

Subsequent deploys go like this:

  $ git commit -am "Changed some stuff"
  $ git push heroku

(The book is currently in progress, but I've written 11 of 12 chapters, so it's likely to be done before you would have time to reach Chapter 12. Also, the current book uses Rails 2.3.5, but a Rails 3 version is also in the works.)

By the way, the Rails Tutorial site itself is also hosted on Heroku. By setting the appropriate header, I've arranged for Heroku to cache the site's static pages, which on subsequent requests get served with blazing speed (see, e.g., http://docs.heroku.com/http-caching). (Because of its read-only file system, Heroku doesn't support Rails page caching, but that's OK: their Varnish cache (http://varnish-cache.org/) is even faster. :-) Thus, though designed principally for dynamic applications, Heroku is also great for static content.

In case you (or others) weren't aware, they also introduced experimental support for Node.js a couple of weeks ago.

http://blog.heroku.com/archives/2010/4/28/node_js_support_ex...

Very cool, had no idea. Have that on my list of things to play with.

I've only used it for proof of concept (read: free) projects and I agree with you about everything but you see a lot of people bitching on HN about the pricing and how costly it is to scale an app on Heroku.

Not sure how much of that is just venting or how much it actually keeps some people at bay but it's pretty obvious some (anonymous people on an online forum, FWIW...) think it too costly.

I think they should factor in how much it would cost them to run this on their own infrastructure for comparison purposes at the same levels where they'll have to pay Heroku.

Only then you'd be comparing apples-to-apples and then you'd see that by the time you've factored in the 24x7 system administration, monitoring, guy-on-standby for when you're on the road and so on that it really isn't that bad.

Of course it will be higher in absolute dollars if you don't factor in your own time and how much that costs, maybe there is even a small premium if you do, but outsourcing has other advantages besides the ones that translate directly in to money, and those can be valuable by themselves (for instance the time freed up).

If you can't make your business model earn back what Heroku costs you at a given scale then that is of course a problem, but if you can't do that then you probably have a problem anyway, and even free servers wouldn't solve that.

Many people underestimate the cost to do (proper) system administration, as well as cost/time/skill required to do (proper) scaling

Reply on news.ycombinator.com