Understanding what Distributed Systems means may require some effort and time as this is a very broad topic in Software Engineering. But once achieved that you will definitely change your perspective regarding the modern Software Architecture.
Depending on the business and technical needs, .Net developers also have a wide range of tools and technologies to choose from when building distributed systems.
Most probably, almost everyone heard about MSMQ (Microsoft Messaging Queue) technology, which is used for asynchronous communication through messages.
Distributed messaging is based on the concept of reliable message queuing. Therefore the queue is one of the basic concepts of MSMQ.
There are different types of queues, but the ones worth to mention for the purpose of this article, are:
- Private – usually are a good choice if all clients/machines accessing the queue are in close proximity and have a fast and reliable connection between them.
- Public – are a good fit if your applications are distributed or have to deal with unreliable communication mediums.
Of course, .NET provides the System.Messaging namespace which includes a few important classes like MessageQueue and Message used by the developers to work with MSMQ.
It seems that MSMQ is a dying technology, but it will still be supported for a few more years since it exists in Windows 10 and Windows Server 2019 and the System.Messaging namespace still lives in .NET Framework 4.8.
And because Microsoft try to keep up with the modern technologies and their competitors, MSMQ can be replaced with one the two types of queue mechanisms that Azure supports: Storage queues and Service Bus queues
A message queue is a form of asynchronous service-to-service communication used in serverless and microservices architectures.
The basic architecture of a message queue is simple – there are client applications called producers(senders) that create messages and deliver them to the broker. Other applications, called consumers(receivers), connect to the queue and subscribe to the messages to be processed.
Even if both of them ensure Durability, Reliability and Availability of messages, choosing between Azure Service Bus and Storage Queues may be tricky and may depend on the needs of your project.
- Azure Service Bus provides support for 256KB message size, while Storage Queues provide support for 64KB message size.
- If the queue will not grow larger than 80 GB, you need to choose Azure Service bus, otherwise use Storage Queues
- Azure Service Bus can store messages for an unlimited period, while Storage queues can store messages for 7 days.
- The cost and latency are higher in the case of Service bus queues.
Azure offers Service Bus Queues as PaaS, but it also offers Virtual Machines (as IaaS) which you can use to host other messaging brokers, like RabbitMQ.
RabbitMQ is an open-source message queue system which can be installed on different operating systems, not only on Windows like MSMQ.
Because they all offer almost the same features and capabilities, choosing between RabbitMQ and Azure Service Bus depends mostly on the project`s budget and the available human resources which are required to deploy and maintain your RabbitMQ cluster.
When to use it?
A messaging system is responsible for transferring data from one application to another , to be able to continue working without crashing or slowing down on data transmission and sharing.
That`s why you definitely need to consider using a messaging system whenever you need to:
- process more intensive tasks asynchronously
- manage complex communication between many different services or applications, distributing a message to multiple consumers
- reduce loads and delivery times of web application servers by delegating tasks that would normally take a lot of time or resources to complete them.
- to ensure: reliability, durability, scalability and high availability for very large systems
CG 
Published by