Migrating Applications that Use Messaging Technologies
Message queues are commonly used for applications to communicate with each other, or communicate within components of an application itself. In architecting for modern applications, architects and developers can use message queues to establish an asynchronous communication channel. A message queue allows senders to send messages and proceed with other tasks without waiting for a response from receivers. Receivers receive and process messages independently without blocking senders. The mechanism helps decouple otherwise tightly integrated components of an application and makes possible a more flexible and scalable solution.
When migrating an application from on-premise to Azure, we recommend that architects and developers examine the current architecture and identify possibilities of using Windows Azure Queues or Service Bus to take advantage of a loosely coupled architecture and the ability to scale especially on the Windows Azure Platform.
Windows Azure Queues are based on Windows Azure storage and provide a basic queueing mechanism to support point-to-point communication. It supports access via REST-based HTTP or HTTPS. Each message queue supports capacity of up to 100 TB (limit of current storage account). Each message can be up to 64 KB in size. See this article for more details.
The most common use of Windows Azure queues is for web role as sender to enqueue work items and worker role as receiver to dequeue and process the work items asynchronously.
Windows Azure platform also offers queue-based messaging via Windows Azure Service Bus. In addition to queuing, Windows Azure Service Bus also provides secure messaging as well as relay capabilities to support distributed applications on Azure or hybrid deployments of applications across on-premises and Azure. For messaging mechanisms, Service Bus supports both point-to-point communication via Service Bus queues and publish-subscribe (pub-sub) model via Service Bus topics and subscriptions. Services Bus Topics and Subscriptions allow multiple subscribers to listen to a single publisher at the same time. Relay capabilities enable hybrid solution scenario where enterprise assets on-premise or in private cloud can be extended and communicate with cloud resources. Service Bus supports access via REST-based HTTP/HTTPS or the TCP protocol. Each Service Bus queue can be up to 5 GB in capacity. Each message can be up to 256 KB.
There are many differences between Windows Azure Queue and Service Bus Queue including authentication, transaction support, and WCF integration. See Windows Azure Queues and Windows Azure Service Queues – Compared and Contrasted article for detailed comparison between the two.
Authors: Kun Cheng
Contributors: Sreedhar Pelluru, Valery Mizonov, Christian Martinez, Rama Ramani
Reviewers: Steve Howard
Windows applications commonly use Microsoft Message Queuing (MSMQ) as a queueing mechanism. It allows applications that run on separate servers in separate processes communicate with each other in a durable, loosely coupled fashion. It also enables applications that reside in heterogeneous network environments to exchange information even when they are not online at the same time. It provides guaranteed message delivery, distributed transaction support, efficient routing, security, and priority-based messaging.
When migrating applications that rely on MSMQ technology to Windows Azure Platform, keep in mind Windows Azure doesn’t support the technology today. The migration requires you to change the code to use Windows Azure queues. Rest of the topic provides different options for migrating your applications that rely on MSMQ technology to the Windows Azure Platform.
Windows Azure Service Bus
In many ways, Service Bus is the closest queuing feature Windows Azure has to MSMQ. They share many similar functions like basic queueing operations, transaction support, and dead lettering. However, using Service Bus requires different APIs than MSMQ does and semantics differ in many ways. The following list provides a few key differences in terms of sizing and performance.
Service Bus messages size is capped at 256 KB (both header and body) while MSMQ messages can be up to 4 MB in size.
Service Bus queues are limited in size to a maximum of 5 GB. MSMQ queue size is limited by computer hardware or configurable quotas.
Service Bus queue throughput could reach up to 2,000 messages/sec whereas MSMQ can reach above 6,000 messages/sec (based on 1k benchmark). See Optimizing Performance in a Microsoft Message Queue Server Environment whitepaper for more details. .
To facilitate the migration, it is possible, however, to establish a link between MSMQ on-premise and Service Bus on Azure via a bridge. The sample code is shared here.
Windows Azure Queue
Windows Azure queue provides a basic point-to-point communication channel. It does not support heterogeneous environments like MSMQ does. In addition, it does not natively support features that a typical MSMQ environment does like automatic dead lettering, transactions, and ordering guarantee. But application developers can implement the necessary features on top of Windows Azure queue to achieve MSMQ like functions. It does however require application customization.
Windows Azure Worker Role
With Windows Server built-in support of MSMQ, running MSMQ on the same node as Worker role has full functionality of MSMQ on-premise version. However worker role is subject to failover and service maintenance. When it happens, all the state information such as messages stored in the local MSMQ storage are lost and becomes unrecoverable. Unless MSMQ was used in a stateless fashion and the application is designed to be able to handle the role failover situation, it is not recommended to run MSMQ in a worker role instance.