This series of blog posts is intended for those who already have some MSMQ experience and would like to know more about Azure Service Bus. It’s based on my own experiences when I learned about Azure, what was familiar and what not, and what looked familiar but surprised me in one way or the other. Since I assume you worked with MSMQ before, I won’t explain common queuing concepts. Idea is to get you up to speed quickly without wasting time on things you already know.
Also, this series deals with Azure Service Bus as it is at the end of 2017. It’s possible that some things will change in the future. Ok, let’s begin.
There’s no machine, it’s now a namespace in the cloud
The first obvious difference is that Service Bus is managed for us in one of Microsoft’s data centers*. Equivalent concept to a machine in MSMQ world is a namespace in ASB. At least from a user point of view. Behind the scene it’s hosted on multiple computers but it’s all transparent to us. Maybe it would be more appropriate to compare it to MSMQ cluster since Azure Service Bus is built from start with the goal of high availability and scalability. Good thing is, a namespace is much, much easier to set up than a Windows Server cluster.
* There’s also the Azure Stack which you can run on-premise, but it’s not that easy to get. Besides, most things should apply for that one as well.
When we try to create a namespace from Azure’s portal, we’ll encounter first problematic question – which tier to use? At the time of writing there are 3 different tiers – Basic, Standard, and Premium. Tiers define which features you’ll be able to use, with what kind of performance and for what price. For learning purposes, I’d recommend to create a Standard Tier – Basic is too limited and doesn’t support all new interesting messaging concepts, and Premium is too expensive. After you get familiar with ASB you’ll know which one will be the best match for your production-level needs. For start, Standard will allow you to learn.
Btw. once namespace is created and you take “Shared access key” from portal, you can continue your journey with QueueExplorer since it supports Azure Service Bus as well.
Azure Service Bus has queues as well
These queues are not that different from MSMQ queues on first look. They’re standard FIFO queues, you Send messages on one end and Receive them on another. There are no public/private queues like in MSMQ.
I did say that queues are first in first out structures, but the order of delivery is not guaranteed in Service Bus! For start, there are so-called partitioned queues which are stored on multiple machines for performance and storage reasons. When you receive from that kind of queue messages come out in more or less random order! Also, if multiple receivers take messages, you can’t guarantee their order. If message order is important for your scenario, you can use session queues to assure that.
We’ll discuss these and other queue differences later.
Messages look familiar
On first glance, Service Bus messages are not that different from MSMQ’s. They have ID, Label, Body, and some other stuff as well.
First surprise – messages are limited to 256KB! They can be 1MB in the premium tier, but even that is not so generous. If you’re sending bigger documents you’ll have to either store them in some separate Azure based storage and only transfer some kind of “pointer” to that storage or split them into pieces smaller than message limit.
Second surprise – message ID is not a unique identifier! And you can write anything you like in that ID field, Service Bus will auto-generate something only if it’s empty. You can create a queue with “Duplicate detection” turned on, but that’s optional. There’s another field called “Sequence #” which is much more like MSMQ’s ID. It’s an auto-increasing number, although not necessarily +1, but at least message which was sent later will always have that number higher than message which was sent earlier.
Additional message storage
Service Bus doesn’t have Extension or “App specific” field for storing additional properties, but it has something better – custom properties. It’s a key/value store where you can put whatever you want and it will be part of a message.
Cool thing if you’re using QueueExplorer Professional is – you can display these properties as columns in a message list. So if your messages have a property called InvoiceAmount, you can see that immediately for all your messages without opening them.
Another cool thing is you can use values from these fields to filter subscriptions.
We’ll talk about topics and subscriptions in Part 2.
Links to all 5 parts of this series.