Azure WebJobs - where hosted? Are they safe as lon

问题:

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:

• Can I use threads to carry out long-running jobs on IIS?
• Concerns with long-running process on IIS
• ASP.NET long running task. Thread is being aborted exception

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?

回答1:

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.

回答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,