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.

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

[2] http://web.archive.org/web/20120801214821/https://devcenter....

EDIT: Added quotes with references.

But at least at the margin, the "magic knob" still worked a little. I think that's why the problem festered: there was always a default recommendation -- "more dynos!" -- that helped, which also just happened to fit the mental model Heroku promotes (while also boosting its revenue). In one of the older support logs RapGenius posted, it was evident that while RapGenius was suspicious about so many dynos being necessary, they let the ticket close once that expensive-but-temporarily-suitable 'fix' was in place. They (and Heroku) turned the magic knob and then let their attention move on to other things.

I won't argue that the lack of concurrency support in rails and ruby is not also a stupid horrible unacceptable choice - and I never understood why the rails community defended it.

Regardless, Heroku was originally built for and continues to market itself as a platform that can scale Rails by using intelligent routing, but it's quite clear that they can not.

Maybe you understand the above, though it seems you are just trolling rails for being single-threaded. This is not the place.