Azure service bus: Use functions vs service fabric vs web job? [closed]

Question

I am considering three ways to to build a service bus topic listener:

1. Azure functions: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-service-bus

2. Service fabric: https://iamrufio.com/2017/04/21/azure-service-bus-listener-with-azure-service-fabric/

3. Web job: https://code.msdn.microsoft.com/Processing-Service-Bus-84db27b4

I'm not sure which way to go. I'm leaning towards Azure functions since it has a direct out-of-the-box service bus integration. However since it's fairly new I'm not sure if it's a safe option.

Service fabric, from what I've read, offers most resiliency and support.

And a web job would be safest to pick since everything is easily configurable but I'm afraid I'll be reinventing the wheel as no out-of-the-box support is provided.

What direction would be best?

Answer 1

It's a very open ended question. You should look at the requirements that you have and other constraints such as budget. For example, running a production grade Service Fabric cluster would require at least 5 nodes. Versus running webjob that would require a hosting plan with some scale out (for HA). Versus running with Azure Functions using consumption plan, where you'd pay per execution only after free grant 1 million requests and 400,000 GB-s of resource consumption per month is used up.

I would suggest to start simple, with Azure Functions. Create your prototype and see if that's what you need. Are you running into issue or not. With Functions utilization of Azure Service Bus could be somewhat limited. For example, you can't dead-letter a message as you either have to return successfully to complete it or throw an exception to retry. You can't defer a message, rather instead would need to send another message. Nor can you use transactional option by using send-via feature of Azure Service Bus.

If you find yourself requiring those features, WebJob would be my next candidate. You will have to look how you'd utilize it. Most likely you'll need to create your own receiving pump and handle things Functions offered for free, but you'll have the flexibility required to create multiple connections, configure clients the way you need, etc.

And only after that, if you see that aside from Service Bus you have requirements like data partitioning, or HA, or DR, or deploying and scaling out multiple services, I'd be more serious about Service Fabric.

Each of these 3 technologies has its place and use cases.