Functions or Webjobs? Choosing background services in Azure

When developing a web app that runs in Azure, you may need to create a background service to do some processing. In the on-prem world, a Windows Service or Scheduled Task that kicks-off a console app could do the trick, but how does this work in the Azure world where you don’t have a ‘server’ to deploy services to? This article discusses two options that work well for this: Azure Functions and Azure Webjobs—code-first options for writing background services in Azure.

First, the similarities:

Both are fully supported by Visual Studio. You can develop and test locally before deploying your solutions to Azure (and incurring the costs associated with that deployment). Both are fantastic options for any background processing tasks (image processing, nightly notifications, overnight order processing), or any task you want to run on a schedule.

The following table highlights the major differences between the two. Most of the time, either option will allow you to accomplish the same goal, but Azure Functions allow for more flexibility with architectural design.

¹WebJobs (without the WebJobs SDK) supports C#, Java, JavaScript, Bash, .cmd, .bat, PowerShell, PHP, TypeScript, Python, and more. This is not a comprehensive list. A WebJob can run any program or script that can run in the App Service sandbox.
²WebJobs (without the WebJobs SDK) supports NPM and NuGet.

Azure Functions
One of the first things to consider with Functions is the pricing plan you’ll be deploying to. You have two choices with Functions, the Consumption Plan or the App Service Plan.

Consumption Plan
Under this plan, you only pay for the time your Functions run. This can be ideal if you know the number of times your Function will run. For example, if you send out email notifications, or do overnight processing, you can easily estimate your total usage and cost this way. If you have Functions you can’t estimate the usage of, but you don’t want to incur any large costs, the better option is to look at the App Service Plan.

Azure provides a free grant for Functions under this plan. Every month, you get 400,000 GB-s (gigabyte seconds) of execution time and 1 million executions for free. This is a great offer to allow you to determine if Functions can suit your needs.

App Service Plan
Under this plan, your Function runs under the same plan Azure uses for web apps, api apps, and mobile apps. If you have one of these three deployed, it might make sense to use the App Service Plan to deploy your Functions to, since your platform costs won’t increase. Another advantage of running under an App Service Plan is your functions now can run up to 30 minutes (or unlimited with configuration changes).

Azure Webjobs
One requirement of Azure Webjobs is they need to run under the context of an Azure App Service (web app). Azure Webjobs don’t have a maximum run time. Like Functions, however, they do share their memory & CPU with the web app. If your Webjob uses large amounts of memory or CPU your web app performance will degrade.

Choosing Functions or Webjobs

Some factors you might want to consider in choosing one:

Webjobs

• For an existing web app, deploying a webjob to that app service will not add any additional costs.
• If you need to listen to additional events by modifying the JobHost object, you must use a Webjob.

Functions

• The ‘free’ tier of functions (allows for 1 million free executions) is slightly deceptive. There’s another limit you will likely hit first; you are allowed a max of 400,000 GB/s (gigabyte seconds).
• If you want to leverage HTTP/Webhooks, you will have to use Functions. This can be useful when you want a true serverless architecture.
• Microservices – functions slide-in well for a microservice architecture.

Azure Functions are built on top of the Web Jobs SDK, so they can do all that Webjobs can do and more. Microsoft recommends Azure Functions for all new development (and I would agree). Version 2 of Functions eliminated many of the limitations of the first version. In particular, allowing Functions to run longer than ten minutes is a huge advantage. Finally, if your organization has any additional questions around Azure Functions, please don’t hesitate to reach out to us. We’d love to help you get started.