6 ms·

EDIT: I don't necessarily support a class action lawsuit against Heroku, but in the interest of conversation... Scalability is not a magic knob you can twist a

EDIT: I don't necessarily support a class action lawsuit against Heroku, but in the interest of conversation... Scalability is not a magic knob you can twist as far as you want… Isn't that the problem? That's Heroku's selling point is that scaling is basically a magic knob. Here are some of the things on their homepage right now: deploy and scale powerful apps Focus 100% on your code, and never think about servers, instances, or VMs again. Run any web or background process with any web framework or worker type. Scale distributed processes effortlessly with a single command. Easily scale to millions of users. Your comment seems to be defending Heroku, by saying Heroku is lying.

deleted 14y ago
[deleted]
- JangoSteve 14y ago
  If you build your app in the correct way That's interesting terminology to use, "the correct way". Heroku's own devcenter article on deploying Rails apps to Heroku [1] still recommends the thin webserver, which isn't concurrent, and therefore causes all the issues being discussed for any rails app. In other words, if you're using thin, it doesn't matter how you architected your app, it's not going to run in concurrent processes on one dyno. So I'll assume by "the correct way", you're referring to both building your app for concurrency and using unicorn as your webserver. Doing only one of those things will not work, both are necessary. But their article only mentions unicorn only as an alternative, and up until recently their documentation actually said "We recommend thin" [2] over unicorn and that unicorn was possible but wasn't officially supported (EDIT: actually the most recent version of the article in wayback machine doesn't even mention unicorn on the page). I wouldn't call using thin "naive", given that it's what Heroku's docs have recommended for a long time. I don't think it's fair to call customers of Heroku naive for not knowing that when Heroku says "easily scale" and "use thin", they are talking about two mutually exclusive possibilites. [1] https://devcenter.heroku.com/articles/rails3 https://devcenter.heroku.com/articles/rails3 [2] http://web.archive.org/web/20120801214821/https://devcenter.heroku.com/articles/rails3 http://web.archive.org/web/20120801214821/https://devcenter.... EDIT: Added quotes with references.

deleted 14y ago

[deleted]

JangoSteve 14y ago
If you build your app in the correct way That's interesting terminology to use, "the correct way". Heroku's own devcenter article on deploying Rails apps to Heroku [1] still recommends the thin webserver, which isn't concurrent, and therefore causes all the issues being discussed for any rails app. In other words, if you're using thin, it doesn't matter how you architected your app, it's not going to run in concurrent processes on one dyno. So I'll assume by "the correct way", you're referring to both building your app for concurrency and using unicorn as your webserver. Doing only one of those things will not work, both are necessary. But their article only mentions unicorn only as an alternative, and up until recently their documentation actually said "We recommend thin" [2] over unicorn and that unicorn was possible but wasn't officially supported (EDIT: actually the most recent version of the article in wayback machine doesn't even mention unicorn on the page). I wouldn't call using thin "naive", given that it's what Heroku's docs have recommended for a long time. I don't think it's fair to call customers of Heroku naive for not knowing that when Heroku says "easily scale" and "use thin", they are talking about two mutually exclusive possibilites. [1] https://devcenter.heroku.com/articles/rails3 https://devcenter.heroku.com/articles/rails3 [2] http://web.archive.org/web/20120801214821/https://devcenter.heroku.com/articles/rails3 http://web.archive.org/web/20120801214821/https://devcenter.... EDIT: Added quotes with references.