Best Practices: On-Premises .NET Core App Checking Storage Queue for Messages

Question

I'm seeking best practices guidance for a .NET Core app, running on an on-premises server, that checks for messages in an Azure Storage Queue. When a message is detected, an action is performed on the on-premises server. (We do not want to use Azure Hybrid Connections.)

I have 2 working prototypes but don't know if either would be considered a best practice for this scenario.

1. a locally-running Azure WebJob that handles a QueueTrigger
2. a locally-running app with a BackgroundService that uses a QueueClient instance to check the queue for messages
   * I did consider a locally-running Azure Function, but all the documentation for the Core Tools suggests they're only for local testing and debugging.

Each of these approaches is running inside a Windows Service so they can be monitored to ensure they're running 24/7. Bearing in mind that the sole purpose of the on-premises app is to check for Azure Queue messages, do either of these 2 approaches appear to be sound? If not, can someone please advise on a best practice for this scenario?

Answer 1

Hi, @Mark Key

You probably don't mind either.

https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-storage-queue-trigger?tabs=in-process%2Cextensionv5&pivots=programming-language-csharp#polling-algorithm

According to the above, QueueTrigger's approach is also a polling model.
Therefore, the mechanism is the same for both 1 and 2.

If you are hosting with App Service, the Azure WebJob SDK will make the migration easier.

Answer 2

we use continuous web job which has QueueTrigger handler and it works both when deployed to Azure and from on-prem. Azure function also will work in both cases - we use that too. The only thing which you need to keep in mind is that on-prem server should allow Azure traffic through internet (may require firewall configuration).