Azure Web Job

WebJobs is a feature of Azure App Service that enables you to run a program or script in the same context as a web app, API app, or mobile app. There is no additional cost to use WebJobs.

WebJob types

The following table describes the differences between continuous and triggered WebJobs.

Continuous	Triggered
Starts immediately when the WebJob is created. To keep the job from ending, the program or script typically does its work inside an endless loop. If the job does end, you can restart it.	Starts only when triggered manually or on a schedule.
Runs on all instances that the web app runs on. You can optionally restrict the WebJob to a single instance.	Runs on a single instance that Azure selects for load balancing.
Supports remote debugging.	Doesn't support remote debugging.

Differences between Web Job and Azure Function :

Azure Web Job	Azure Function
With Azure App Service and Web Apps, Microsoft implemented Azure Web Jobs as a means to more easily host background processes, long or short running. Web Jobs are hosted within an App Service Plan either stand-alone or along side a Web App (or API App, or Mobile App).	Azure Functions are built on top of the Azure Web Jobs foundation underneath, with some extra stuff on top. So, essentially, Azure Functions are Web Jobs.
Web Jobs allow for you to share the resources of an App Service Plan between a Web App and Web Job if you wish in order to help save on hosting cost. Or, alternatively, you could choose to host the Web Jobs in their own dedicated App Service Plan.
With Web Jobs, your background processes can be executed as any command-line executable or script (.ps1, bash, executable, etc). This can be very convenient, but it still requires you to deploy out an entire application often times, since most custom background processes require more complex code bases than a PowerShell script or other command-line script.	Azure Functions is a service that takes the PaaS offering of Web Jobs and turns it up to the max. Instead of building an entire application, you only need to author and deploy individual methods (or functions) of code in an even further managed PaaS platform.
Features of Azure Web Jobs: ·       Web Jobs can be configured to be manually triggered or run on a schedule. ·       Web Jobs can be configured to be Continuously running (aka running constantly, all the time) ·       Web Jobs can be setup to be Triggered based on events in other Azure Services, such as a new messaged added to a Storage Queue or Service Buss Queue or Topic ·       Web Jobs can be long running ·       Web Jobs can be short running ·       Web Jobs can be implemented in any language as either a command-line executable or script	All the same features listed for Azure Web Jobs also apply to Azure Functions and the following: ·       Automatic scaling (CPU and memory is scaled according to needs determined at runtime) ·       Pay-per-use pricing (Consumption plan instead App Service plan) ·       More trigger events (like WebHooks) ·       In-browser development (Visual Studio still possible) ·       F# support

Here are two scenarios for which WebJobs may be the best choice:

• You need more control over the code that listens for events, the JobHost object. Functions offers a limited number of ways to customize JobHost behavior in the host.json file. Sometimes you need to do things that can't be specified by a string in a JSON file. For example, only the WebJobs SDK lets you configure a custom retry policy for Azure Storage.
• You have an App Service app for which you want to run code snippets, and you want to manage them together in the same Azure DevOps environment.

For other scenarios where you want to run code snippets for integrating Azure or third-party services, choose Azure Functions over WebJobs with the WebJobs SDK.

Source: https://docs.microsoft.com/en-us/azure/azure-functions/functions-compare-logic-apps-ms-flow-webjobs

Azure Function hosting plans and scaling

 There are three hosting plans available for Azure Functions: Consumption plan, Premium plan, and App Service plan.

The hosting plan you choose dictates the following behaviors:

• How your function app is scaled.
• The resources available to each function app instance.
• Support for advanced features, such as VNET connectivity.

Consumption Plan	Premium Plan	Dedicated Plan
When you're using the Consumption plan, instances of the Azure Functions host are dynamically added and removed based on the number of incoming events. This serverless plan scales automatically, and you're charged for compute resources only when your functions are running.	When you're using the Premium plan, instances of the Azure Functions host are added and removed based on the number of incoming events just like the Consumption plan.	Your function apps can also run on the same dedicated VMs as other App Service apps (Basic, Standard, Premium, and Isolated SKUs). With an App Service plan, you can manually scale out by adding more VM instances. You can also enable autoscale
The Consumption plan is the default hosting plan and offers the following benefits: ·       Pay only when your functions are running ·       Scale out automatically, even during periods of high load	Premium plan supports the following features: ·       Perpetually warm instances to avoid any cold start ·       VNet connectivity ·       Unlimited execution duration ·       Premium instance sizes (one core, two core, and four core instances) ·       More predictable pricing ·       High-density app allocation for plans with multiple function apps Consider the Azure Functions premium plan in the following situations: ·       Your function apps run continuously, or nearly continuously. ·       You need more CPU or memory options than what is provided by the Consumption plan. ·       Your code needs to run longer than the maximum execution time allowed on the Consumption plan. ·       You require features that are only available on a Premium plan, such as VNET/VPN connectivity.	Consider an App Service plan in the following situations: ·       You have existing, underutilized VMs that are already running other App Service instances. ·       You want to provide a custom image on which to run your functions.
On a Consumption plan, a function execution times out after a configurable period of time.	On a premium plan, code needs run longer than the maximum execution time allowed on the consumption plan.

Function app timeout duration

The timeout duration of a function app is defined by the functionTimeout property in the host.json project file. The following table shows the default and maximum values in minutes for both plans and in both runtime versions:

Plan	Runtime Version	Default	Maximum
Consumption	1.x	5	10
Consumption	2.x	5	10
App Service	1.x	Unlimited	Unlimited
App Service	2.x	30	Unlimited

Always On

If you run on an App Service plan, you should enable the Always on setting so that your function app runs correctly. On an App Service plan, the functions runtime goes idle after a few minutes of inactivity, so only HTTP triggers will "wake up" your functions. Always on is available only on an App Service plan. On a Consumption plan, the platform activates function apps automatically.

How the consumption and premium plans work

In the consumption and premium plans, the Azure Functions infrastructure scales CPU and memory resources by adding additional instances of the Functions host, based on the number of events that its functions are triggered on. Each instance of the Functions host in the consumption plan is limited to 1.5 GB of memory and one CPU. An instance of the host is the entire function app, meaning all functions within a function app share resource within an instance and scale at the same time. Function apps that share the same consumption plan are scaled independently. In the premium plan, your plan size will determine the available memory and CPU for all apps in that plan on that instance.

Function code files are stored on Azure Files shares on the function's main storage account. When you delete the main storage account of the function app, the function code files are deleted and cannot be recovered.

Service limits

The following table indicates the limits that apply to function apps when running in the various hosting plans:

Resource	Consumption plan	Premium plan	App Service plan1
Scale out	Event driven	Event driven	Manual/autoscale
Max instances	200	20	10-20
Default time out duration (min)	5	30	302
Max time out duration(min)	10	unbounded	unbounded3
Max outbound connections (per instance)	600 active (1200 total)	unbounded	unbounded
Max request size (MB)4	100	100	100
Max query string length4	4096	4096	4096
Max request URL length4	8192	8192	8192
ACU per instance	100	210-840	100-840
Max memory (GB per instance)	1.5	3.5-14	1.75-14
Function apps per plan	100	100	unbounded5
App Service plans	100 per region	100 per resource group	100 per resource group
Storage6	1 GB	250 GB	50-1000 GB
Custom domains per app	5007	500	500
Custom domain SSL support	unbounded SNI SSL connection included	unbounded SNI SSL and 1 IP SSL connections included	unbounded SNI SSL and 1 IP SSL connections included

1 For specific limits for the various App Service plan options, see the App Service plan limits.
2 By default, the timeout for the Functions 1.x runtime in an App Service plan is unbounded.
3 Requires the App Service plan be set to Always On. Pay at standard rates.
4 These limits are set in the host.
5 The actual number of function apps that you can host depends on the activity of the apps, the size of the machine instances, and the corresponding resource utilization.
6 The storage limit is the total content size in temporary storage across all apps in the same App Service plan. Consumption plan uses Azure Files for temporary storage.
7 When your function app is hosted in a Consumption plan, only the CNAME option is supported. For function apps in a Premium plan or an App Service plan, you can map a custom domain using either a CNAME or an A record.

Source: https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#timeout