5

From Azure WebSite Always On and Meaning of "Always On" setting on Azure Web Site I assume that Azure WebJobs are hosted in IIS and uses IIS resources (and this our website resources).

Furthermore, in the pricing page: http://azure.microsoft.com/en-us/pricing/details/websites/ there is a statement:

Run custom executables and/or scripts on demand, on a schedule, or continuously as a background task within your Websites instance. Always On is required for continuous WebJobs execution. Azure Scheduler Free or Standard is required for scheduled WebJobs.

Therefore I assume that is true. Indeed Azure WebJobs are hosted in Azure Website's IIS. Note: WebJobs can be continuous and long running.

However, what worries me then, is that executing long running processes/background processes is often seen as anti-pattern:

So does Microsoft Azure propose something, which seems to be anti-pattern or not? Additional question: would it be a good idea then to run Quartz.NET as continuous task and have "free" simple background task scheduling?

Community
  • 1
  • 1
piotrwest
  • 2,098
  • 23
  • 35

2 Answers2

8

I'll try to address your two questions separately.

1. Where are WebJobs hosted?

A given WebJob lives inside a Web App (or Mobile/API App). Each site has a Kudu instance running which manages things like deployments, IIS, and, important for us, WebJobs. So it is Hosted in a Web App, but it isn't necessarily managed by IIS, it's managed by the same thing that manages IIS for Web Apps. All this is available for review by you in the Kudu GitHub.

2. Are they safe as long running processes?

They're about as safe as any long running process, in that they aren't by themselves. If you just upload a console app as a continuous job and have it running in a while loop, it may crash at any time for any reason. With 'Always On', Kudu will always be awake to start it up again.

If you want some amount of assurance that things will be executed and not lost, try taking a look at the WebJobs SDK. It will actually track fail/success for Jobs and uses a Storage Queue to track history, allowing for retry and normal patterns for processing like poison messages, etc.

David Makogon
  • 69,407
  • 21
  • 141
  • 189
Chris Anderson
  • 8,305
  • 2
  • 29
  • 37
  • Thx for great answer! Just to be clear: Kudu process(es) and WebJobs are separated from IIS? Statements like "WebJob is executed by request/pinging IIS" are false? – piotrwest Sep 15 '15 at 23:36
  • 1
    Kudu is itself managed by IIS. You can learn about how it works in the [Kudu Wiki's Architecture](https://github.com/projectkudu/kudu/wiki/Kudu-architecture) article. To trigger a triggered WebJob, you execute a request against Kudu ({site}.scm.azurewebsites.net/AzureJobs/...), which is technically going through IIS, but the WebJob is being executed and monitored by Kudu. Bottom line, it's still to be treated as the equivalent to a stateless service with all the same expectations. If you need a deterministic flow, look to the WebJobs SDK and Queues. – Chris Anderson Sep 15 '15 at 23:43
  • Great. For future reference: despite WebJobs SDK you can even write your own extensions, or use extensions written by someone else: https://github.com/Azure/azure-webjobs-sdk-extensions – piotrwest Sep 16 '15 at 10:10
  • Yup. We even created a new type of Job recently (WebHooks) which allow you to call your WebJob like you would a triggered Job, but with the benefit of tracking success/failures. – Chris Anderson Sep 16 '15 at 16:16
2

If you are after a long running task, consider running the task as a 'WebJob'. This is specifically for such cases. On AWS you can use AWS lambda as well,

Jerome Anthony
  • 7,823
  • 2
  • 40
  • 31
  • 1
    Yes, but WebJobs are hosted in IIS, right? So how they are specifically for such cases, if they are basically long running processes/threads in IIS, which is an anti-pattern? Do you get my point? – piotrwest Sep 15 '15 at 23:23