Azure Service Fabric and Message Queues

Question

Now with Azure Service fabric, would there be a use-case for also using a separate queue solution such as Windows Service Bus? The downsides would probably be a new single point of failure, but are there upsides? Queues can add some buffering, but on the other hand, Service Fabric should be able to scale really well and offer stateful capabilities, so no queue buffers should be needed?

Answer 1

Sure, the upside is that services like Azure Service Bus and Azure Storage Queues offer features that are not included out-of-the-box in Service Fabric. So the question to ask yourself is: do you add an external service dependency to get that functionality, or do you stay self-contained by building it yourself on Service Fabric? A self-contained application on Service Fabric is good, but re-inventing existing functionality is bad, so you have to decide where the most value is for you and lean in that direction.

For example, think about..

• Portability. An application that is self contained on Service Fabric can be hosted wherever Service Fabric can run, which is pretty much anywhere (Azure, other public clouds, your own machines or data center, etc.).
• No external dependencies means fewer points of failure, a single toolset, and a unified development, deployment, upgrade, and maintenance process.

On the other hand..

• Services like Service Bus offer a rich set of features. Is it worth spending the time building and maintaining the features you need yourself on Service Fabric?