Hmm, you might be out of luck, but it does bring up the question of why Heroku doesn't have load-triggered scaling, or some sort of dead-man's switch option.
Having been a Heroku user for a while, and having looked into autoscaling for dynos and workers a few times (but not having really needed it yet), I really think they could do a better job of publicizing that these solutions exist.
I imagine that tons of their user base (especially for small hobby sites that only occasionally, if ever, see high traffic or run background tasks) look for this, and yet there's nothing pointing to it other than old posts on the mailing list. At least put information and resources for autoscaling in the Docs section of the site.
Acquiring resources only as long as you need them, and then releasing them when you're done, should be the standard service - complete user control should be the advanced feature set. They already do this for websites on a single dyno: they spin them down when they're idle for a while. But they don't do it with workers (what effect does the latency of starting a backup job up really have? it's already running in the background).
It's because they need to keep a process running all the time to poll the queue for new jobs. So basically, they keep an instance of your app booted at all times for job processing (if I understand how DJ workers work). And that's pretty much like a dyno, except it doesn't serve traffic. And there are no web requests to trigger it to spin up like there are for dynos.
One of Heroku's employees has a fork of delayed_job that handles autoscaling workers in the background. I use it in conjunction with several hourly cron jobs and it works like a charm. http://github.com/pedro/delayed_job/tree/autoscaling
Yes, I was aware of this, though I haven't had the need to use it yet.
But my question stands: why isn't this stuff very visible - i.e., on Heroku's DJ doc page: http://docs.heroku.com/delayed-job , or at least linked from there? Or published as an official piece of code on the Heroku github page?
Really? I would certainly hope that's not the case. Relying on customers overspending due to technical deficiency seems like a pretty poor business model.
I'd certainly be happier paying more per pro-rated unit of time that I actually use than I am feeling as though I'm in an arms race to not be fleeced.
Is there really that much revenue to skim off the top? Either way, they're paying Amazon out of those charges.
But I'm not so cynical as to think that their success is reliant on this income.
Either way, they're paying Amazon out of those charges.
I'd be extremely surprised if Heroku actually spools up EC2 instances the moment you move the slider. It'd be a far more intelligent (and profitable) design to simply make sure there are sufficient resources to maintain the desired service levels with a buffer to deal with spikes in demand.
It should be relatively straightforward to provide service levels that are functionally identical to actually starting each "dyno" or "worker" with a greatly reduced cost structure.
Relying on customers overspending due to technical deficiency seems like a pretty poor business model.
I didn't mean to say they're relying on it, simply that it's adding to the bottom line and it would be greatly missed.
