Typically with ASP.NET Core 3.1 when no specific authorization requirements are set all endpoints are publicly accessible. When you’re wo...asp.net core
Applications are known to break, but erosion is a much sneakier adversary of the modern web developer. That is why it is important to understand your options to deal with this unwanted problem. The most common approach is to build asynchronous tasks that run in the background, commonly referred to as jobs. Jobs can sync data, remove unwanted resources, and more; something a developer doesn’t want to keep doing manually.
There are two categories that we want to consider when choosing our approach, and maybe you should too:
Azure WebJobs is a very competent approach to running jobs, as they are simply
console applications. The development experience is something many developers are comfortable with, and you can undoubtedly complete. Another advantage is these jobs can be run locally by executing the
The deployment process fits into the
git strategy we have adopted as a team. If a job is present in a solution, it automatically gets added to the App Service. We also have two flavors of a job to pick from, Continuous and Scheduled (Cron).
The Azure WebJob experience is an enjoyable one. The console output is displayed in a tool found in the Azure Portal and can give insight into what is happening.
The issues we find with Azure WebJobs is the following:
If these are not issues, then Azure WebJobs is a suitable approach. You can overcome some of these matters by writing custom logic to account for them, but that may introduce more problems.
Azure Scheduler is a task scheduler for the cloud. It can perform actions suited for Windows Azure:
The development experience is similar to Azure WebJobs as you write your task into a console application, or write an HTTP endpoint to perform an action.
As for setting up the scheduled task, you have two options currently:
You technically can’t test Azure Scheduler locally, but you can mimic its behavior. I guess that’s ok, right?
Once setup, we found that the Azure Scheduler worked dependably and as advertised. It solved the load balancer issue we had with Azure WebJobs as we were triggering execution through the TLD in front of the load balancer and it just worked.
Note: Security is not available on the free tier of Azure Scheduler. The standard tier will cost you $15 USD a month.
Hangfire is an integrated job scheduler designed to work in multiple hosting environments: ASP.NET and console applications. It supports .NET 4.5+ and .NET Core.
Hangfire works the same locally as it does in production. It is part of the application and exercising the jobs happens the same way. It supports multiple backing stores like SQL Azure, Redis, and more.
Since it is part of the application, it can be deployed using our approach without any changes. It just works!
Hangfire also supports many other types of jobs that are not currently available to us with Azure WebJobs: Fire and Forget, Continuation Jobs, and Logical Retries.
We have done preliminary tests and found the problems present with Azure WebJobs and Scheduler just are not there. Since we use SQL Azure as the backing store, it doesn’t matter what regions we use for load balancing. It is also very easy to know what’s happening as the included dashboard is very informative.
At some point, a background job is necessary to fend off the erosion of your application. In our current tech landscape, we have many options available to us. I mentioned a few above, and currently, Hangfire is the most compelling one we found. It addresses the issues we found using Azure WebJobs and then brings more to the table. It works for our developers locally, and for our users in production.