Azure Cloud
Architecture Azure Azure Function Azure Web Job Azure WebJob Best Practices

How to Decide between an Azure Serverless Function or an Azure App Service WebJob

Welcome to today’s post.

In today’s post I will be discussing the choice we face when deciding whether to use Azure Serverless Functions or Azure App Service Web Jobs.

In previous posts I have introduced as developers how to implement Azure Functions and how to implement an Azure WebJob. However, I have not discussed in what scenarios we would use one or the other service.

In most situations we would consider both the business and the non-functional aspects of our requirements. In this blog I will be discussing the non-functional requirements that we would consider before choosing one option over another.

Both Azure Functions and Web Jobs there some differences that we should be aware of.

Let us look at the areas that differ. The first difference that I will discuss in the first section is with trigger mechanisms.

Trigger Mechanisms

With Azure Functions they can only be triggered. The trigger source can be one of the event trigger sources (see later in the event trigger section).

Azure functions can also be triggered based on a scheduled timer.

Azure Web Jobs can be triggered manually or on a schedule.

The manual triggering can be done via the App Services portal within the Web App or Web API application.

The types of web job manually triggered are either continuous or scheduled.

In the next section, I will compare the running durations that we have available to us depending on what subscription plan we select and how the Azure function is hosted.

Running Durations

Azure functions can run either on a consumption plan or on a premium (or higher) plan.

On a consumption plan, we pay for the number of Azure functions we run and execution time. The plan scales according to how much resources we use while running our functions. This is a true serverless option.

On a premium plan, we pay for the number of seconds our functions run per CPU core and memory consumption. An Azure function that runs under premium plan must be hosted under an Azure App Service.

Azure functions running within a consumption plan have a maximum running duration before they timeout, whereas functions running within a premium plan can run indefinitely. By default, Azure functions running under consumption plan have a default timeout of 5 minutes, with a configuration of up to 10 minutes.

Azure Functions when running on a consumption plan are designed to run for a limited duration before they timeout.

In the next section I will look at the development options that are available to us with Azure Functions and Azure Web Jobs.

Development Options

Both Azure Functions and Azure Web Jobs provide developers with the option to develop within a Visual Studio IDE environment.

Azure Web Jobs can be implemented as either a pure Azure portal service, or they can be implemented using Web Jobs SDK within Visual Studio. Since Azure Web Jobs are console applications which can be run and debugged locally.

With the non-SDK option, Azure Web Jobs run continuously within an endless loop.

When running an Azure Web Job under a Web App Service and on a paid tier (Basic, Standard or Premium), enabling the Always On setting to allows it to run continuously including when web apps timeout.

Multiple Web Jobs can be deployed under the same Web App.

With Azure Functions, you can develop and debug the functions locally using the Azure Tools for Visual Studio, then when the function is fully tested, it can be deployed to Azure.

In the next section I will compare what event sources are supported for Azure Functions and Azure Web Jobs.

Event Sources

Another requirement we will need to consider is the types of event sources our chosen service will need to support. Both Azure Functions and Web Jobs support event triggers from the following sources:

  • Azure Storage queues and blobs
  • Azure Service Bus queues and topics
  • Azure Cosmos DB
  • Azure Event Hubs
  • Timer

Azure Functions support event triggers from HTTP and Azure Event Grids.

In addition, Azure Web Jobs support event triggers from the file system.

In the final section, I will show how to decide which Job processing platform to use.

Deciding which Job Service to use

The following questions are helpful in deciding whether to use the Azure Functions platform for job processing:

  1. How long do you want to run the job for? If longer than 10 minutes, then choose Azure web jobs.
  2. If you plan to use continuous jobs, then use Azure web jobs.
  3. If you wish to run jobs according to a scheduled, then choose Azure Web Jobs.
  4. If you have short running background tasks, then choose Azure functions under consumption plan.
  5. If you wish to have resource costs fixed and scale up as needed, then use Azure Functions.
  6. If you have a high number of short running tasks that run continuously, this requires more memory and CPU then use Azure Functions on a premium plan.
  7. If you have unlimited jobs and wish to pay only for the resources in an App Service plan, then use Azure Functions in a premium plan.

The following questions are helpful in deciding whether to use the Azure Web Jobs platform for job processing:

  1. If you have unlimited jobs and wish to pay only for the resources in an App Service plan, then use Azure Web Jobs within an App Service Plan.
  2. If you wish to run background tasks within your Web App, then use Azure Web Jobs.
  3. If the job will be a long running task that can impact a Web app, then use a Web Job hosted within an empty Azure App Service.

Azure Functions were introduced a few years after the release of web jobs, so there is currently more support and features for Azure Functions. As you can see from the above questions there seem to be more reasons to choose Azure Functions.

The choice is made easier by answering the above questions and choosing the platform that suits your requirements the most.

That’s all for today.

I hope you found this post useful and informative.

Social media & sharing icons powered by UltimatelySocial