There are a few choices when it comes to implementing custom background processing tasks. The main options in the Microsoft Azure cloud are to use either Azure Functions or Azure Web Jobs. Functions are newer, cooler, and may seem to be the obvious choice going forward, however, the choice isn’t really that easy. This article outlines the points you need to consider when deciding between Azure Functions or Azure Web Jobs.
Azure Functions are Web Jobs
Before we get into the specifics of when Azure Functions are appropriate, or when Azure Web Jobs are appropriate, it’s best to mention that 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. You could almost say that between the two, it’s Web Jobs all the way down.
Azure Functions are built on top of the Azure Web Jobs foundation underneath, with some extra stuff on top.
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).
When you get down to it, Azure App Service is hosted on Managed VMs (Virtual Machines) underneath. An Azure App Service Plan is the way that the PaaS (Platform as a Service) services within Azure App Service (Web Apps, Mobile Apps, and API Apps) define the underlying VM.
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.
In an effort to make the implementation of background processing easier in Azure, Microsoft built out Azure Functions. Azure Functions are actually built on top of Azure Web Jobs in the underlying platform. Consequently, at the core of Azure Functions is the same functionality of Web Jobs. You can setup and run any command-line executable or script as an Azure Function too.
The main different with Azure Functions is that it’s 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.
Now with the true difference and similarity of Azure Functions and Web Jobs defined, let’s get into the specifics of when you would choose to use one over the other.
Choosing Web Jobs
Do you have background processing that you need to implement? If yes, then Azure Web Jobs is a viable solution to fill that need. You can implement any type of background processing task as an Azure Web Job. There really isn’t much of a limit to what you can do.
Here are some highlights of the 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
As you can see from the above list, Azure Web Jobs can be implemented to fill any background processing need. Implementing background processing with Azure Web Jobs in an App Service Plan is generally a cheaper option over other IaaS based approaches.
Azure Web Jobs can be implemented to fill any background processing need.
Choosing Azure Functions
All the same features listed above for Azure Web Jobs also apply to Azure Functions. You can implement Azure Functions in any language as either a command-line script or executable. They can be manually executed, scheduled, or even triggered by other Azure Services in a similar way.
Even though Azure Functions can be long or short running, there are some caveats to that. Let’s go through what those are.
Consumption Plan
With the Azure Functions Consumption Plan you only pay for your functions when they are actually executing. This helps save significant cost over paying for an entire VM or App Service Plan. If you have an Azure Function that’s only executed a few times per week, as example, this could be extremely cheap.
With the Azure Functions Consumption Plan you only pay for your functions when they are actually executing.
What does paying for when the Function is executing really mean? The cost of Azure Functions are calculated in relation to the memory usage and total execution time. This relation of memory and execution time is measured in terms of Gigabyte-Seconds (GB-s).
This is an ideal option for hosting Functions that are short running and only intermittently run. With the emphasis on short running there is a maximum timeout threshold to how long Azure Functions can execute. This timeout threshold is set to 5 minutes. If the Azure Function completes within this timeout, then you’ll be able to use the Consumption Plan pricing without issue. However, if the Azure Functions take longer than 5 minutes to complete execution, then it will timeout and the process will be terminated.
Due to the timeout threshold of Azure Functions there are certain architecture and code design practices that will need to be followed in order to get longer running processes to run successfully within an Azure Functions Consumption Plan. The main practice would be to break up the Function into smaller separate functions. These separate functions would then be implemented using one or more message queues to communicate.
App Service Plan
The Azure Functions App Service Plan pricing utilizes an App Service Plan (just as Web Apps, API Apps, or Mobile Apps) to host Azure Functions. This is a more costly option than Consumption Plan. With App Service Plan pricing you don’t pay for only when the Function is executing, but rather for the reserved resources of the underlying VM.
With App Service Plan pricing you don’t pay for only when the Function is executing, but rather for the reserved resources of the underlying VM.
The reasons to use the App Service Plan pricing may not seem obvious, but there are 2 very good reasons that can make it a very useful option:
- Share resources with a Web App, API App, or Mobile App by running within the same App Service Plan.
- Reserve dedicated resources for Azure Functions that are either longer running, executed more frequently, or both.
By using an App Service Plan to share resources between Azure Functions and another App Service app (Web App, API App, or Mobile App) then the Azure Functions an utilize a possibly under-utilized App Service instance. This also has the benefit of the Azure Functions essentially being Free to run since the App Service Plan is already paying for the server resources.
Longer running Azure Functions (over 5 minutes) won’t run well with the Consumption Plan due to it’s timeout threshold. When using an App Service Plan to host and execute Azure Functions, the timeout threshold does not exist. Azure Functions are subject to all the same features as Web Jobs when hosted in an App Service Plan. This means Azure Functions in an Azure Service Plan do not need to be architected or designed differently to be broken up into smaller executable pieces.
Longer running Azure Functions (over 5 minutes) won’t run well with the Consumption Plan due to it’s timeout threshold.
Consumption or App Service Plan?
As you can see above there are some valid reasons for choosing to use either Azure Web Jobs or Azure Functions. Even though Azure Functions are built on top of Web Jobs, there still are some differences. However, the largest difference with Azure Functions is the pricing plans. While Consumption pricing only has you paying for when Azure Functions are actually executed, it does have a fairly big limitation, under certain circumstances, which is mainly the timeout threshold. The App Service Plan pricing may be more expensive in certain circumstances, but it also allows you to have longer running Azure Functions, along with the ability to share the unused resources / capacity of an App Service Plan.
While Consumption pricing only has you paying for when Azure Functions are actually executed, it does have a fairly big limitation, under certain circumstances, which is mainly the timeout threshold.
Azure Functions are the newer edition of Platform as a Service and the Serverless wave of hosting background processing within Microsoft Azure. Although, Web Jobs are still viable, it’s likely better to use Azure Functions if you can moving forward. However, the choice between Consumption Plan and App Service Plan may be a slightly difficult one depending on the needs of the application.
About the Author
Chris Pietschmann
Chris Pietschmann is a Microsoft MVP, HashiCorp Ambassador, and Microsoft Certified Trainer (MCT) with 20+ years of experience designing and building Cloud & Enterprise systems. He has worked with companies of all sizes from startups to large enterprises. He has a passion for technology and sharing what he learns with others to help enable them to learn faster and be more productive.
Azure Resource Naming Conventions and Best Practices
Azure Regions: Interactive Map of Global Datacenters
Azure Functions: Extend Execution Timeout Past 5 Minutes
Terraform: Azure Resource Tags Tips
Terraform: Deploy to Multiple Azure Subscriptions in Single Project
Terraform: Deploy to Multiple AWS Accounts in Single Project
Reblogged this on The Flying Maverick.
Almost a year ago I had the need to execute a few actions per user for my application, once a day.
I needed the flexibility of auto-scaling as the number of users was massive, and we really only needed the code to run for a few seconds per user. At the time, Azure WebJobs were somewhat new and they suited my needs, though I did feel like I was misusing them to “execute a function” instead of their intended primary purpose of running clean-up or supporting tasks for a web app.
I didn’t realize it at the time, but I guess that was my first “serverless” app!
In today’s world, I’d use Azure functions for that use-case instead. I would go with a consumption plan and not have to pay for the App Service Plan for 23 hours of the day, nor worry about configuring the auto-scaling rules myself.
I’m mostly convinced at this point that I would only use Azure WebJobs for clean-up/supporting tasks for a website (like resizing images or deleting old log files…etc), and use Azure Functions for everything else.
The more interesting choice is now between “consumption-plan” or “app-service-plan” for Azure Functions, and this post clarifies the distinctions nicely (e.g. the execution-time limit), so thanks for that!
Cheers,
MJ
Thank you for the description of what you’ve done
My pleasure! Keep the great posts coming!
best explanation fount of Azure function vs web apps ever found on the web! Thanks man !
Just a note that you can increase the function timeout to 10 minutes by editing the host.json, 5 minutes is just the default. https://buildazure.com/2017/08/17/azure-functions-extend-execution-timeout-past-5-minutes/
I currently have a Web Job implemented in Node (JS) that processes messages/events from a service bus and works well (it is short running but high volume running all the time). I was curious if there are any benefits to switching it over to a Function. Based on this post, it doesn’t seem there is any point in re-engineering things. The section on “Choosing Azure Functions” is pretty sparse and doesn’t actually give any reasons to choose Functions (other than cost issues). I’m curious if there are any technical reasons (non-cost) to choose Functions? Easier to spin up multiple instances for parallel processing? Better reporting and logging? Better crash handling? Anything? My conclusion so far is that if you’re starting from scratch it might be a little less work to implement functions, but if you already have the plumbing of Web Jobs done there is no benefit to switch (unless I’m missing something).
Right, if you have existing Web Jobs there might not be much benefit to rewrite them as Azure Functions. However, Consumption Plan pricing may be worth it depending on how often the Web Jobs are executed and whether they are long running or not.
Hi Chris,
I want to run a Java batch job (.jar file created from a spring-boot-app) and the frequency of this job running will be configurable on a CRON scheduled (once a week).I have already deployed one spring boot app in Azure cloud and it’s running in one App service plan.
The batch job will do some background task (clean up/delete the documents which are expired from a collection in cosmos DB and archive them in another collection) for the already running app.
Can you suggest me, which one (WebJob or, Azure Function) will be the best way for the above background task processing ?
If I go with Azure webJobs and create a webjob (.jar file ) within the existing App service for the running app, shall the added .jar program be able to communicate with the cosmos Db ?
Thanks and Regards,
Sudipta
From what you’ve said it sounds like a WebJob within your App Service App/Plan would work best. And, yes your WebJobs app can access CosmosDB, you just need to code it to connect to that database.
Chris Please i am setting up a laravel app on azure and need to set cron jobs, any help has to how to go about this or what would you rather suggest.
If WebJobs work for you that may be the way to go if you jobs are written in PHP. However, if you can write them in a language supported by Azure Functions, I’d recommend that for more simplicity. Also, if you can do things without code, you may want to look at using Azure Logic Apps, or even mixing Logic Apps with other services like Azure Functions or Web Jobs to get a custom solution that works. Overall, though I’m not real familiar with Laravel, so I can’t say with more clarity.
Hello,
you said “When you get down to it, Azure App Service is hosted on Managed VMs (Virtual Machines) underneath. An Azure App Service Plan is the way that the PaaS (Platform as a Service) services within Azure App Service (Web Apps, Mobile Apps, and API Apps) define the underlying VM”
Can you clarify that please?
An App Service Plan is where you set the pricing tier for Azure Web Apps (using Web Jobs feature) or even with Azure Functions and App Service Plan pricing. This is how the VM is defined. You don’t have full access to the VM, but of course there’s a VM somewhere to host your app. The App Service Plan provides this layer of abstraction for the VM underneath and the automation layer that manages that VM for you as a PaaS hosting offering.
I have an application that sits on an Azure Virtual Machine. A couple of times a week, we need to upload and then unzip some large courses – 100 Mb to an Azure Storage account, What would be your suggestions regarding Azure Functions versus Web Jobs in this case? I am just beginning to use each of these and want to be as efficient in my learning as possible.
If that’s the only application on the VM, then it’d make sense to migrate that process to serverless hosting. If there’s other apps and the VM is being utilized, then you may want to leave it as-is. As far as Functions versus Web Jobs, it’ll likely be less work to use Web Jobs if it’s an existing command-line executable or script. Converting command-line applications to a Web Job on a schedule can be fairly simple to do. However, if you would need to rewrite it, then I’d recommend considering Azure Functions as that’s the best supported path going forward. I hope this information helps.
Hi Chris, are all the facts in the blogpost still case today ? (july 2019). ‘Cause its a really nice overview, but cloud _does_ change extremely fast 🙂 (just b4 I retweet it) 🙂
Yes, the blog post is still accurate today. It provides some foundational information about Azure Functions compared to Azure Web Jobs that still stands in the current state of Azure Functions. The current v2 runtime of Azure Functions builds on top of this same foundation of the Azure Functions serverless compute platform. Thanks for asking! 🙂
Hi Chris, Really appreciate the continuous updates on this thread.
I have created a Webjob, deployed on Azure and extracted the webhook details from Azure, as well
Now I am trying to integrate this webhook with Dynamics 365 , by registering this Webhook on Entity update; it says following error “The webhook call failed because the http request received non-success httpStatus code. Please check your webhook request handler”
This webhook is working fine when POSTed from Postman tool (with authorization keys)
Could you kindly help or guide me with right pointers, if possible?
Regards
Atanu
I’m not entirely sure what the issue is that you described. I assume you solved the problem by now. I would appreciate if you could post a short description of what the solution was. Thanks!