Azure webjobs vs scheduler

Question

A very simple question:
Why would someone use the Azure Scheduler if Azure WebJobs are free?

I couldnt find any topic regarding "azure webjobs vs azure scheduler"

The main difference is that the webjob contains everything that the scheduler can do:

• Scheduler can make HTTP calls
  
• WebJob can do that and more (run SQL commands, etc)

Horatius

Answer 1

It's 2016. The below answers are no longer accurate.

WebJobs now also has a built-in scheduler and the schedule can be defined by a cron expression.

When publishing to Azure, you can choose if you want to have the WebJob sparked off by the Scheduler or by the WebJob internal scheduler.

Important Note: The Azure Scheduler has limits to frequency of either 1hr or 1min depending on if paid or not. For the internal scheduler however, your App Service requires Always On to keep on running and firing off the job. This Always On status may affect your pricing.

Rew

So if I create a triggered web job with a cron expression, it's still free? Is continuous the one you pay for? I'm a bit confused. There's not a whole lot of options or explanation when creating a job: i.imgur.com/MDYd4yX.png – Baroque

@Baroque - Web jobs are 'free' regardless of if they are triggered or continuos because (I think) they use the same resources that your web app is using. However, if you want a job to be always running, then the web app itself needs to be set to 'Always On' (because by default they switch off after inactivity) which can be done through the app settings in the Azure Portal. Always On is only available, however, on the basic, standard and premium web app tiers. None of which are free. Hope that helps. – Loxodromics

Answer 2

The actual scheduling bits of WebJobs are built on top of the scheduler. When you set up a Web Job on a schedule under the hood it uses the scheduler to kick it off. WebJobs provides a nice little location to host the code that gets executed. In fact, if you create WebJobs for a web site look in the Scheduler on the portal and you'll see them listed there as well.

Also note that the scheduler could call out to other systems not running Azure. If you have something running in a Cloud Service that needs to be called regularly, or even if something was hosted elsewhere (another provider or on premises) the scheduler is where you can set that up.

Regarding the cost aspect, there is a free tier to the scheduler as well: http://www.windowsazure.com/en-us/pricing/details/scheduler/.

Stets

what doesnt make sense to me is that the Scheduler's free mode has the frequency limited to 1 hr (ie: every one hour, the task is executed). A higher frequency (eg. 1 min, 5 mins, etc) is not free. With webjobs you can have a continous task and its free... – Horatius

The continuous task runs on the web site and the scheduler isn't constantly calling it. It's spun up and left to run. This would be like you creating a task scheduler on Windows Server to fire on a schedule vs. simply launching an executable on startup that doesn't exit. One requires external input/trigger to execute (the scheduled ones) and the other doesn't. Continuous jobs run all the time on all instances. Scheduled jobs fire on their schedule and randomly get sent to an instance to run (load balancer ends up selecting the instance to run it on). – Stets

@Horatius I'm not sure I fully understand why you're confused about cost and frequency. But webjobs running continuously on your free/shared site only run for as long as the site is up, apparently 20 minutes per this. The compute cost is still counted against whatever your site is running as (free/shared/reserved), a job is just another consumer of that compute capacity. A reliably scheduled job requires guaranteed uptime of some service to initiate a task at a given time, hence the higher cost for high freq jobs. – Doris

Is the association between a WebJob and its corresponding scheduler entry something we can discover through the API? (I'm doing some automation work where it would be useful to discover this.) How does the management portal know that a particular scheduler job is the one for a particular WebJob? – Jeopardous

Ok but i want to call in the webjob my API endpoint blabla.com how to do it? i upload a .php file with a curl? – Jointer

Answer 3

1. Continuous jobs are monitored, and if they exit they are re-executed. In this way they act more like "services" in your local machine. There is a module that monitors and keeps your app working. Always-ON is a feature that will help your site stay alive and hence, your webjobs to continuously run.

2. Scheduler is used to trigger the webjobs. It uses the scheduler user account (not the back-end account). This way you can move out of the free tier for scheduler, sign up to higher tiers to suit your needs. But essentially, all the scheduler is doing is hitting an https endpoint (which is public, but required your auth).

3. Triggered jobs (scheduled and on demand) are invoked by an https call. These calls are load balanced - much in the same way that a web app with many instances is load balanced. Continuous jobs run concurrently by default, but can be set to be a singleton.

Babbitt

Answer 4

For Webjobs starting from version 2, there is no reason to use an Azure Scheduler anymore. As a matter of fact, the Azure Portal already flags this functionality as (Legacy).

From WebJob SDK v2 additional triggers have been introduced and one of them is TimerTrigger, which works with CRON expressions to schedule executions. This execution mode does not need any additional Azure construct, you just need the webapp to be set as AlwaysOn to guarantee the webjob to run.

Another azure service that works with TimerTriggers is Azure Functions, which is built on top of the WebJob SDK that allows a serverless execution.

Obese