Azure WebJobs - where is it organized? Are they safe as long-running processes?

Question

From Azure WebSite Always On and the Always On setting to the Azure Web Site I assume that Azure WebJobs are hosted on IIS and use IIS resources (and these are our site resources).

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

Run custom executable files and / or scripts on demand, on schedule, or continuously as a background task in your instance of websites. Always On is required to run WebJobs continuously. light blue Scheduled web applications require a free Free or Standard scheduler.

Therefore, I assume that this is true. Indeed, Azure WebJobs are hosted on the Azure IIS website. Note. WebJobs can be continuous and long lasting.

However, my concern is that running long processes / background processes is often seen as an anti-pattern:

• Can I use threads to do long jobs in IIS?
• Problems with the long-term process in IIS
• The long-term goal of ASP.NET. Thread cancels exception

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

Answer 1

I will try to deal with your two questions separately.

1. Where are WebJobs located?

This WebJob is located inside a web application (or Mobile / API application). Each site has a Kudu instance that manages things like deployment, IIS, and, important to us, WebJobs. Thus, it is hosted in a web application, but it is not necessarily managed by IIS, it is controlled by the same that IIS manages for web applications. All this is available for viewing by you in Kudu GitHub .

2. Are they safe as long-running processes?

They are as safe as any lengthy process, since they are not on their own. If you just load the console application as a continuous task and run it in a while loop, it can be corrupted at any time for any reason. With "Always On," Kudu will always be awake to launch it again.

If you need confidence that everything will be completed, and not lost, try a look at the WebJobs SDK . It really tracks failure / success for Jobs and uses the Storage Queue to track history, allowing it to repeat normal processing patterns, such as poisonous messages, etc.

Answer 2

If you are doing a long task, consider the task as "WebJob." This is specifically for such cases. On AWS, you can also use AWS lambda,