用于批处理的Azure Windows服务

Question

I'd like to build the Azure PaaS equivalent of a "Windows Service". I could of course create a VM and deploy a Windows Service, but I'm looking for scalable/PaaS way to do this. Essentially my app is a back end service that monitors a queue (Azure Service Bus for example) and when a message comes in on the queue it will perform a bunch of processing logic (processing logic, accessing a database, invoking other web services, queuing other processes etc.). Some services might need to do some more "advanced" operations like create a child app domain, write temporary files to disk, etc.

What kind of Azure solution should I be looking for to meet this need?

It feels like Azure has evolved a lot in the last couple of years and I'm confused when trying to figure out the best service to use to meet my needs. Some project types seem obsolete now but there is still a lot of old documentation/blogs. I see references to WebJobs, Worker Roles, Logic Apps, and Functions. Can someone more experienced in building Azure services tell me which technologies I should be looking at to meet my needs?

I feel like this should be sort of obvious and a common need, but perhaps I'm just using the wrong search terms and I'm not really finding a lot of info that seems to match my exact need, or the info I do find is from 2011 and I'm worried the landscape has changed a lot since then.

Answer 1

You have choices, like you say - WebJobs, Logic apps, Service Fabric or Functions, and it depends on how much control you need or want over the code you're deploying. Worker Roles are a Cloud Services term and although they're still supported, are generally not recommended, since the deployment, scalability and management of the other services listed is far better.

Web Jobs and Functions both use the same WebJobs SDK to provide you a load of support for triggering from queues, blobs or scheduling execution. They both run within (and scale with) an app service plan, but Functions are "serverless" in that you don't need to see or manage the web app service instance, and can just deploy the source code - it will be compiled on deployment.

Service Fabric is a different beast altogether, and provides resilience and low latency state (data) replication, but could also be an option for stateless batch execution. It creates a cluster of VM nodes under the covers which will manage the resilience and deployment for you, there's a bit more to understand and manage, but it's great for things like massive scale stateful services.

Logic apps have a different execution/charging model, and will scale on demand, but it's more for orchestrating workflow and joining components together than actually executing your operation. Ie. to process the data from your queue might be a component, which needs to run somewhere - probably in an API app or an Azure function you're also hosting.

Answer 2

Logic Apps is designed for the exact scenario you described.

You should be able to create a Logic App that triggers on new message in a Service Bus queue.

Then, Logic Apps natively supports interaction with SQL/Queue/REST, even on-premises file system, XML validation, X12/AS2/EDI, along with built-in functions such as parsing JSON/XML, conditions, looping, etc.. For more advanced actions not currently supported in Logic Apps, you can extend Logic Apps with Azure Functions.