The New Heroku, Part 1 of 4: The Process Model & Procfile

blog.heroku.com

56 points·joshuacc··6 comments

This seems just obscenely convenient. Is there any other PAAS product out there that offers abstractions this sugary-sweet yet so powerful?

This is actually pretty similar to what we've got so far internally at ep.io, albeit without the procfile and with a slightly more complex definition instead.

We're even running things like Redis instances off of a similar codebase, albeit one modified so the >1 server case is different.

Edit: Oh, and of course we're not exactly as open and launched as Heroku are. Just pleased to see that other people think it's a sensible way to build this stuff!

I don't know what awesomeness could possibly be contained within parts 2, 3 or 4 to make this seem any better. Heroku is doing some incredible things.

What kind of resources are allocated to each dyno? Could you, say, run a Solr server from a worker dyno? What about some other custom service that uses a lot of memory? Are they hard or soft limits? This sounds really cool, but it doesn't really tell you much about what this is suited for; especially given how easy it is to devour memory in Ruby.

A couple of useful resources related to the Heroku Dyno:

http://devcenter.heroku.com/articles/how-much-memory-does-a-...

http://devcenter.heroku.com/articles/dyno-isolation

You can't run a Solr server because (1) present limits are 300MB RAM hard, and (2) disk is transient. There's a solr addon though.

Reply on news.ycombinator.com