Choosing between .NET Service Bus Queues vs Azure Queue Service

user_54990 0
Viewed 23251

Just a quick question regarding an Azure application. If I have a number of Web and Worker roles that need to communicate, documentation says to use the Azure Queue Service.

However, I've just read that the new .NET Service Bus now also offers queues. These look to be more powerful as they appear to offer a much more detailed API. Whilst the .NSB looks more interesting it has a couple of issues that make me wary of using it in distributed application. (for example, Queue Expiration... if I cannot guarantee that a queue will be renewed on time I may lose it all!).

Has anyone had any experience using either of these two technologies and could give any advice on when to choose one over the other.

I suspect that whilst the service bus looks more powerful, as my use case is really just enabling Web/Worker roles to communicate between each other, that the Azure Queue Service is what I'm after. But I'm just really looking for confirmation of that before progamming myself in to a corner :-)

Thanks in advance.

UPDATE

Have read up about the two systems over the break. It defo looks like .NET service bus is more specifically designed for integrating systems rather than providing a general purpose reliable messaging system. Azure Queues are distributed and so reliable and scalable in a way that .NSB queues are not and so more suitable for code hosted within Azure itself.

Thanks for the responses.

azure-storage-queues azure-servicebus-queues azure
6 Answers

I would recommend that you stick with Azure Queues for communicating between web and worker roles. Using queues is the official and sanctioned way of communicating between Azure processes and I sincerely doubt that you will program yourself into a corner. Service Bus (AppFabric) has a higher overhead and although really good for talking to external apps, may not be optimal for quick and simple messages within your Azure app.

Simon_Munro_38930

As I understand it, the Service Bus (as was) has had queues for a while, but these are not guaranteed to deliver the message - bon chance!

user_1880590

The queue related patterns a developer learns can be applied to both. Both can be used from a reliability and implementation-easiness point of view.

Things only Storage queue can do 1) The worker processing a message crashes. A subsequent worker wants to read the status of the message to continue from where the prior worker left off. 2) You require server side logs of all of the transactions executed against your queues.

But comparisons don't matter. If custom queue development is what we need then always use storage queue. It was the first to be developed by Microsoft. Service bus was brought-in copying BizTalk and the purpose is integration(hybrid), hence there are advanced features in this line: sessions, transactions, automatic dead-letters, etc.

This link provides a comparison , so does this link. It will be difficult to analyze everything and start in an agile development hence the above mentioned rule.

user_15011910

To make things very clear, this is a comparison between two Azure components, created at a different point in time, for different reasons.

Storage queues and Service Bus queues - compared and contrasted

Azure supports two types of queue mechanisms: Storage queues and Service Bus queues.

Storage queues, which are part of the Azure storage infrastructure, feature a simple REST-based GET/PUT/PEEK interface, providing reliable, persistent messaging within and between services.

Service Bus queues are part of a broader Azure messaging infrastructure that supports queuing as well as publish/subscribe, and more advanced integration patterns. For more information about Service Bus queues/topics/subscriptions, see the overview of Service Bus.

While both queuing technologies exist concurrently, Storage queues were introduced first, as a dedicated queue storage mechanism built on top of Azure Storage services. Service Bus queues are built on top of the broader messaging infrastructure designed to integrate applications or application components that may span multiple communication protocols, data contracts, trust domains, and/or network environments.

user_28748960
Related