Difference between Azure Queue and Queue Bus Service

Question

I noticed that Microsoft Azure has two types of queue: Azure Queue which is part of Azure Storage and Service Bus Queue. In this tutorial the Azure website uses the Azure Queue service to exchange messages between Web Role and Worker Role of a Cloud Service, now in that other the Queue Bus Service that is used.

What are the differences between queue types and under which scenarios each should be used?

Answer 1

This page of MSDN shows in detail the differences between the two types of queue (and there are many - in relation to performance, capacity, security, quotas, among others).

Basically, you should use Azure Queue if:

• Your app needs to store the equivalent of more than 80 GB of messages in a queue, where messages have a lifespan of less than 7 days.
• Your application wants to track progress to process a message within the queue. This will be useful if the work that is processing a message fails. A subsequent job can then use this information to pick up where the previous one left off.
• You need server logs of all transactions executed in your queues.

And you would use the Queue Bus Service if:

• Your solution should be able to receive messages without having to probe the queue. With the Service Bus, this can be achieved with the use of the long probe reception operation via TCP-based protocols or protocol that the Service Bus supports.
• Your solution requires queuing to provide a FIFO ordering delivery (first in, first out) guaranteed.
• You want a symmetric experience on Azure and Windows Server (private cloud). For more information, see Service Bus for Windows Server.
• Your solution should be able to support automatic detection of duplicities.
• You want your application to process messages in the form of long running parallel streams (messages are associated with a stream using the Sessionid property in the message). In this template, every node in the consumer app competes for flows, not for messages. When a stream is given to a consumption node, the node can examine the flow state of the application using transactions.
• Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.
• The TTL (Service Life) feature of the application-specific workload may exceed the 7-day period.
• Your application handles messages that may exceed 64 KB, but will probably not approach the 256 KB limit.
• You deal with a requirement to provide a queue-based access model, and different rights/permissions for senders and recipients.
• Queue size will not exceed 80 GB.
• You want to use the AMQP 1.0 standards-based messaging agent. For more information about AMQP, see Service Bus AMQP Overview.
• You can anticipate an eventual migration from queued-based point-to-point communication to a messaging pattern that allows seamless integration of additional recipients (subscribers)each of which receives independent copies of some or all of the messages sent to the queue. The latter refers to the publication/subscription feature provided by the Bus Service natively.
• Your messaging solution should be able to support delivery assurance "at most once" without the need for you to create additional infrastructure components.
• You would like to be able to publish and consume lots of messages.
• Needs full integration with the Windows Communication Foundation (WCF) communication stack in the . NET Framework.

Answer 2

The differences can be seen in the reply sent by Carlos Figueira. Speaking on the Queue Bus Service, it allows one-way communication. It provides a load balancing, where messages are received and processed by competing receivers in the order they were added to the same queue. By moving this service to Azure, developers can work on distributed applications using the system with a focus on message queuing. Thus, through the middle layer, an application creates and places a message in the queue, while another application processes and returns the first one in the same way (when necessary).

More information about the Azure Service Bus can be seen at http://talkitbr.com/2015/06/19/azure-service-bus/