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!
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.
6 comments
[ 4.3 ms ] story [ 25.2 ms ] threadWe'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!
http://devcenter.heroku.com/articles/how-much-memory-does-a-...
http://devcenter.heroku.com/articles/dyno-isolation