Messaging Framework Comparisons - Azure Service Bus

Part 2 of 4

Messaging frameworks allow for the creation of loosely coupled, highly resilient, and highly scalable systems. The challenges faced by modern applications are complex, and our solutions are likewise sophisticated. Applying patterns help us to design modern applications while reducing complexity. Messaging is a reliable and proven pattern to address these needs.

This blog series exists to survey messaging frameworks and comparable technologies built on the .NET stack. While there are quite a few options in this space when working with .NET, this series narrows its scope to the following: NServiceBus (, Microsoft Azure Service Bus (, and Akka.NET (

  • The Intro to this series can be found here.
  • Part 3 of this series – Akka.NET – can be found here.
  • Part 4 of this series – NServiceBus – can be found here.



Microsoft Azure Service Bus is Microsoft’s proprietary implementation of the enterprise service bus as Platform as a Service (PaaS).  Azure Service Bus was first introduced in December 2009 in order to make development of Service Oriented Architecture easier. Microsoft Azure Service Bus (MASB) started its life as part of what was then known as Microsoft AppFabric. MASB is a feature-rich platform offering high capacity, availability, and partition tolerance. Like many cloud offerings, MASB has a pay-as-you-use pricing model; the more data and computational resources you use the more you pay.

Azure Service Bus offers two different platforms: Storage queues and Service Bus queues. Each offer a different set of features and best use cases. Storage queues was the first of the two to be made publicly available. Storage queues have a prerequisite of having an Azure Storage account, due to the fact messages will be persisted within a Binary Large Object (BLOB). Service Bus queues do not require a storage account and allow for more advanced ESB patterns to be implemented.


As Azure Service Bus is a Messaging as a Service offering, it is one the most highly available and resilient options for a messaging framework. Several factors contribute to Azure's high degree of resiliency:

        • It is hosted in Microsoft’s datacenters, which brings with it guaranteed SLAs.
        • The ability to geo-replicate queues and services across regions.
        • Active and passive replication can be configured.
        • Clients can be configured to automatically restart, or send alerts when something goes awry.


Since Azure Service Bus is more of a Platform as a Service model, other than the initial queue provisioning, there are no further intrinsic concerns with deployment. All further code pushes would follow whichever deployment process you would normally use with your applications.


Azure Service Bus offers a couple of solutions to increase scalability. For horizontal scaling, queues can be partitioned to allow for multiple brokers and messaging stores. Message batching and caching can also be implemented.


The learning curve for Azure Service Bus is slightly steeper than other messaging options. Understanding the multitude of options between Azure Queues and Service Bus queues, queues vs. topics, a new authentication scheme, and SOAP vs. the AMQP protocol can become daunting. A strong proficiency in PowerShell in order to provision queues and namespaces is also a must.


If your development environment is Visual Studio, you have access to a myriad of tools seamlessly integrated into the IDE, including direct access to the messages in your queues. The Azure portal offers limited insight into the internals of the queues, and many developers may find it easier to create their tooling using the available API over REST or creating PowerShell scripts.


When choosing Azure there are a few things to keep in mind. First, your application is locked into the Azure stack. To have a development and QA environment that mirror production, it becomes necessary to spin up new environments within Azure which can substantially increase Azure spend rate.  Also, as Azure Service Bus is a pay-as-you-go service, a poorly architected system can easily eat through an IT budget. Another factor here is that, as the number of connections grow, so too will costs as you’ll need to buy up into higher tiers.


Support is available, although pricey. For production and business-critical support, the costs are $300 and $1,000 per month respectively.

Up Next

In the next part of this series we’ll dive into Akka.NET, covering its strengths and weaknesses. Read it here

Lancelot Dunnehoo

Lancelot Dunnehoo

Lance Dunnehoo is AI‘s Chief Architect and Principal Cat Herder. His 17 years in software consulting has led to a broad depth of knowledge in many technical and business domains, but his primary passion lies in distributed architecture and systems integration. When he‘s not working he can typically be found..working.