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