By Cory McIlroy (@coryio)
Recently, for the first time on the Wear Test project, we ran across something that needed to be done on a scheduled basis. Simple batch operations: loop over a set of records, apply some logic, send some daily emails to the users, and bob’s your uncle.
We knew that the basic Heroku scheduler was sufficient for just kicking a process off every day at a specified time. But, the Heroku scheduler causes a temporary dyno to spin up and it’s not intended for heavy lifting. The scheduler documentation states: “Anything that takes longer than a couple of minutes to complete should use a worker dyno to run.” Also, inexplicably, according to project architect Kyle Bowerman, “Any fish that doesn’t swim faster than the current will get eaten by the bear.”
We needed to introduce a simple work queue to the mix to help the scheduler communicate cross-dyno to a ‘worker’. This allows the scheduled service to remain extremely lightweight. When the scheduler fires up the job, it basically just throws a message on the queue and dies again; letting the dyno (and therefore the $$ meter) shut back down.
To read this post in full, please visit the CloudSpokes Blog.