Best practices for Hangfire on Azure

[parthopdas]

Hi,

I am attempting to migrate an OnPrem solution to Azure. The application uses Hangfire fairly heavily. Hangfire is hosted in a windows service and is backed by SQL Server.

I prefer not to remove this dependency unless absolutely required. (alternatives being functions/webjobs.)

Are there any guidelines/best practices for running Hangfire on Azure?

Barring the differences in storage characteristics, is Hangfire expected to work exactly on azure as it does OnPrem?

On googling + scanning github issues & SO:

People do seem to be using Hangfire on Azure. Could not find any best-practice/migration documents around this.

Thanks, Partho

[thiagodds]

I'm facing the same scenario here.

My hangfire instance is running in a Windows Service on my onprem farm. I'll move to Azure on the next few weeks and now I'm testing running the Hangfire instance in a WebApp and in a WebJob, but I don't know what is the best way.

I don't know if running in a WebApp is a good ideia because the IIS process has some limitations and different setup. I think that WebJob has the same problem, because a WebJob run in a IIS process to.

In my onprem farm I have 20 machines and the Hangfire runs 1 milion jobs per month. I need a robust way to run Hangfire and I think that IIS process isn't a good ideia.

[parthopdas]

From my investigations - Azure functions is the most appropriate mechanism for the numbers you are stating.

Note that I didn't proceed with the original problem - so I could give you my experience in terms of numbers.

[thiagodds]

To change to Azure Functions I need to refactory a lot of code 😢

My app has 12 queues, 15 recurrent jobs, 100+ kinds of jobs.

[parthopdas]

Yeah I know what you mean.

This also indicates that hosting concerns have leaked into the core. i.e. anti-clean architecture. On the other hand, refactoring to bob martin's clean architecture will automatically lend your code to be hosted anywhere - azure functions, azureapps, webjobs, hangfire...

So its worth the effort.

Happy to pair up with you.

[bbrandt]

@parthopdas @thiagodds Any best practices come out of your journey since Aug 2019?

[odinserj]

By the way, this is Hangfire on SQL Azure Basic plan with 5 DTUs with recommended settings and web application based on B1 AppService with 1 core – https://hangfire-harness.azurewebsites.net/hangfire/ and it already processed more than 1,000,000,000 of background jobs with 724,000 daily.

[bbrandt]

Thanks for the links @odinserj! Is that this repo? https://github.com/HangfireIO/Hangfire.Harness/tree/master/Hangfire.Harness

Is that a ASP.NET MVC/Owin app running in the Azure AppService?

[bbrandt]

The reason I'm asking around is we've been using Hangfire for a few years across 3 products and it's working great for us. One of the things that really sets it apart from using Azure Functions or WebJobs directly is the quality and functionality of the Hangfire Dashboard.

However we've been running the Hangfire workers inside the same process as our ASP.NET Core web app and are now trying to prepare for more load with several CPU intensive jobs that are running in Hangfire.

Our idea right now is to move the workers out into either their own ASP.NET Core app, without any HTTP endpoints or a Continuous WebJob as described here. I was looking into if either of these is the best way to run the workers or if there's something like Azure Batch or other job runner type services that could be adapted to running Hangfire jobs. I did not find any references to anyone running Hangfire workers in Azure Batch though.

[odinserj]

Is that this repo? https://github.com/HangfireIO/Hangfire.Harness/tree/master/Hangfire.Harness

Yes, exactly.

Is that a ASP.NET MVC/Owin app running in the Azure AppService?

Yes, but it doesn't matter, because almost everything is the same for OWIN or ASP.NET Core.

But I can't say anything regarding the Azure Batch at the moment, looks like it's for specialized workloads.