Messaging with Azure Service Bus - Part 9

In this series:

In this edition of my series on Azure Service Bus, I want to highlight a few of the "premium" features that Service Bus offers. Many of these aren't necessary if you are just learning and experimenting with Service Bus, but if you are using it for mission critical production systems, then its well worth taking advantage of some of these capabilities.

Pricing Tiers

Like many Azure services, Service Bus offers a choice of pricing tiers.

The cheapest, Basic, has a very limited feature set - you can only use Queues, not Topics and Subscriptions. But there is no monthly charge, and you only pay for your messaging operations, so it's a kind of "serverless" pricing option.

However, the Standard pricing tier has a lot more features and has a base charge of about $10 a month. It's ideal for using in developer, testing and QA environments, and is also perfectly fine to use in production assuming you don't have very high performance needs or any of the other premium features we'll discuss shortly.

But there is also a Premium tier, which unlocks several additional features in the areas of performance, security, and resilience. Let's look in a bit more detail at these.

Performance

With the standard tier, your messages are handled by shared infrastructure in Azure. This results in limitations on the throughput of messages and its possible that you will get throttled. With Premium messaging, the pricing model is based on "messaging units" which are dedicated resources in Azure, giving you predictable throughput and latency. It's possible to scale up and down the number of messaging units depending on load.

Premium messaging also increases the maximum message size from 256KB up to 1MB per message. This can be very useful, but I would also suggest that if your messages are getting that large, it may be worth considering whether there is any inefficiency in your architecture that could be addressed. If huge messages really are necessary, it might appropriate to use the claim check pattern instead.

Security

Whichever pricing tier you use to access Service Bus, your messages are sent and stored securely. You can authenticate with a connection string, or use Azure Active Directory service principals which is particularly valuable if you are making use of Managed Identities as it eliminates the need for your applications to store any connection details at all.

In many industries it is really important that all data is "encrypted at rest", and ideally using "customer managed encryption keys". It is possible to achieve this by encrypting your own message payloads before sending them and decrypting them on receipt but that is tricky to implement well yourself. With Service Bus Premium it's possible to configure encryption at rest with a customer managed key.

You may also want to restrict access to your Service Bus at the network level, and the Premium tier offers additional capabilities for doing so such as VNet integration and private endpoints. This is important because it's not uncommon for messages to contain sensitive customer data, and so exactly the same stringent protection mechanisms should apply to service busses as you would for databases in a production system.

Resilience

The final capability I want to highlight is to do with resilience. In mission-critical production systems it's vital that there is no single point of failure, and it's all too easy to write code that simply assumes that the Service Bus is going to have 100 percent availability.

But of course in the real world things can and do go wrong, so it's important to have mitigations in place for if there is a problem with your Service Bus. Premium Service Bus allows you make use of availability zones meaning that even if there is a failure in one physical location, you will still have access to your Service Bus.

On top of that, it's possible to configure "geo disaster recovery" with Service Bus premium tier. This protects you against some of the more catastrophic failure scenarios by allowing you to pair a secondary Service Bus namespace in another region. All the messages get mirrored there, so if your primary is lost you can failover to the secondary.

Summary

While the standard tier of Service Bus is just fine for development and testing and simple production applications, for large business critical systems you should strongly consider taking advantage of the improved performance, security and resilience of Premium tier Service Bus.