Cronally vs Periodic Tasks

Amazon recently announced support for periodic tasks in Elastic Beanstalk. This can be an ideal solution for some users who:

  • are already using a worker tier
  • aren’t accessing data on the web server
  • can tolerate inaccuracies in job timing

If you’re not already using a worker tier for your Elastic Beanstalk environment, the costs involved with running a dedicated EC2 instance purely for a handful of scheduled tasks isn’t all that enticing. The other issue this creates has to do with how work is sent to the worker tier instances.

A worker tier uses SQS to pop messages off the queue and POST them to application endpoint running on the instance. The problem this creates is when a periodic task is expected to run at a particular time, but can’t because too many other tasks are ahead of it in the queue. This doesn’t mean the periodic task won’t run, it just might not be the time you expect.

Using a service like Cronally, you can avoid launching dedicated instances for scheduled tasks and have those tasks read from a dedicated queue, alleviating the stuck-in-the-queue problem. Additionally, Cronally offers the flexibilty to run tasks on any or all of your instances. This lets the same strategy as generating invoices work for clearing file-based session data, temporary uploads, and other common time-oriented tasks.