Adding WebJobs to Azure App Service

In this post, I will explain how you can use WebJobs to execute tasks on Azure App Service.
 

The Requirement

You might require some sort of task to run in Azure, for example, when I upload an image via a Web App, a background task will pick up that image, do something to it, and then email me a link to download the results.
This sort of task was historically done by a WebJob, a task that could execute in the abstracted virtual machine environment of Azure App Services. A WebJob, in short, is some script or executable that can be run continuously, manually started, or triggered on a scheduled basis.

Functions as an Alternative

WebJobs run in Azure App Service plans. There are two considerations, especially for larger applications:

• Performance and Cost: When you have a large-scale mobile or web application, it is recommended that any WebJobs are placed into a different App Service plan (pool of abstracted virtual machines), giving you the ability to scale the background tier separately from the web tier and giving the web tier its own processor/memory capacity. This means that you will have an additional fixed cost for each virtual machine instance in the additional App Service plan(s).
• Scale-Out: You can auto-scale an App Service plan. This is very fast but it will reach a limit. And, there is a large increment in the cost (per-minute charge for the App Service instance).

 
Azure Functions are similar to WebJobs because they allow you to perform some task in the background. Functions are triggered by a schedule or event; in other words, an instance of the Function is instantiated by Azure in response to something happening to perform a task. When that task is completed, the instance disappears. There is no server, so there is no big incremental cost; instead you pay for each second of Function run time. On the plus side, smaller tasks should reduce your Azure costs and Functions can scale beyond the limitations of your App Service plans. On the downside, there is a potential for a huge bill if your Functions go wild. Azure App Service plans have a fixed/predictable per-instance (virtual machine) cost.
Functions currently support C#, JavaScript, and F# with another of other languages and scripting environments in an experimental stage. WebJobs however, support a number of scripting languages and .CMD, .BAT, and compiled executables:

• .cmd, .bat, .exe (using Windows cmd)
• .ps1 (using PowerShell)
• .sh (using Bash)
• .php (using PHP)
• .py (using Python)
• .js (using Node.js)
• .jar (using Java)

So while Functions are hot right now, WebJobs still have an important role to play, especially when one is migrating existing applications to Azure.

Creating a WebJob

This process is quite simple. Create a new Web App, which is confusingly called an App Service in the Azure Portal. Open the App Service and open Settings > WebJobs.
Click + Add and a Add WebJob blade will appear. Enter the following information:

• Name: Give the WebJob a name to identify it.
• File Upload: Click the folder button, and browse to and select the script or executable that you will be using. This file will be uploaded to your App Service.
• Type: Choose Continuous or Triggered.

If you selected Continuous you have two options for Scale:

• Multi Instance: The task will run on all instances (virtual machines) of the App Service plan.
• Single Instance: The App Service plan will ensure that the task is running on just one instance (virtual machine).

If you select Triggered, then you can choose between:

• Scheduled: You must enter a CRON expression for the schedule.
• Manual: It will be the responsibility of an operator to start the task.

 
Note that you must ensure that Always On is enabled in the Application Settings of the Web App before adding a continuous or scheduled WebJob.

Click OK, your script/executable will be uploaded, and the WebJob will be created.