Azure Service Bus: Introduction to How and When to Use

Attention: The following article was published over 4 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.

Azure Service Bus is a message-queueing technology. In this introductory blog, you will learn what Azure Service Bus is and when to use it, see examples of how to set up and use it, and find the resources you need to learn more or to try it out yourself.

What is Azure Service Bus?

Azure Service Bus is Microsoft’s cloud-based solution for messaging as a service. In its simplest form, it is an inbox where a textual message can be placed for later processing in an asynchronous way. That means that the application that places the message in the inbox doesn’t have to wait for the application that processes the message to complete the message processing, thus freeing up the placer to continue its work.

In more complex scenarios, there could be one publisher and multiple subscribers to each message. Or, the order the messages received might be important to the order they are processed even when distributed across multiple subscribers (e.g., first in, first out).

The subscriber might occasionally poll the service bus for new messages, or it might leave a connection open and receive any messages as they are posted. The messages might be transactional in nature, or need to be scheduled to be processed at a later date.

RabbitMQ and NServiceBus are other popular options for enterprise messaging services. Both can be run on-premise if needed. RabbitMQ is an open-source system that has many of the same features as Azure Service Bus, and NServiceBus is a commercial product that is tailored specifically for the Microsoft .Net ecosystem.

Azure Service Bus has three tiers: Basic, Standard, and Premium. All three include encryption at rest.
Basic is great for hobby projects or very small loads because it is very cheap ($0.05 per million operations). Standard includes the ability to do publish/subscribe scenarios, transactions, and sessions and starts at just $0.0135 per hour. Premium allows for some resource isolation and redundancy and starts out at a little under $1 per hour.

When Would I Use Service Bus?

Service Bus is great when you need a cloud-based solution to broker messages between different applications to reduce coupling in your systems. You can use Service Bus to:

Create a queue to receive messages to be processed later (even if it’s only seconds later).
Handle peak loads where a spike in messages might slow down your processing application.
Decouple applications so that their technologies and APIs can change as long as they agree on the message format they use to communicate with each other.
Distribute one message to multiple applications.
Scale-out message processing while maintaining message order.

Where I’ve Used Service Bus Recently

I’ve been using Service Bus for a few years now both on hobby projects and for enterprise solutions.

Both of my hobby projects that use Service Bus are Slack Apps. The one with the most messaging requirements has only cost me $0.05 in the last 12 months for Service Bus usage!

I started using Service Bus for these projects because Slack expects a response within a second or two to any message it sends to a service. When my service receives the message, it puts it onto the Service Bus, then sends Slack a 200 OK. After that, another process picks it up off the Service Bus, does any database lookups necessary, and then posts a message back to Slack that is then presented to the user.

Recently, I helped one of Keyhole’s clients implement a Service Bus solution. The client required processing of over 100,000 messages per day, with peak times of many messages per second. We were able to successfully handle the load required by placing the incoming messages on the Service Bus and returning an OK response to the client so that it could send the next message in its queue to us.

Our message processing solution consists of multiple containers of a Node.js application that each poll the Service Bus queue every few seconds for new messages to process. This allows the solution to automatically scale the processing container count to meet the demand throughout the day.

How do I Setup Service Bus?

To get a free start, sign up here. If you have an MSDN subscription through your work, you are also able to get up to $150 per month in free credits; see your subscription dashboard for more information.

Once you have an account and are logged into Azure, you can create a new Service Bus.

Getting started with Azure Service Bus

As you step through the setup process, make sure to select the Basic pricing tier.

Azure Service Bus pricing tiers

Next, create a new queue by giving it a name. For this example, leave the rest of the parameters with their default values.

Now, you need to create a set of connection strings. Do this by navigating to the shared access policies within the new queue, adding a new policy, and checking both the Send and Listen boxes.

Azure Service Bus connection strings

Finally, you can copy your primary connection string out to be used in your code to connect to the queue.

How Do I Use Service Bus?

There are some Service Bus examples that Microsoft has provided that will be very helpful to get your feet wet.

Adding and receiving messages is easy, and it takes very few lines of code. Here’s an example in C# from my hobby project:

using System.Threading.Tasks;
using Func.Models;
using Func.Models.Config;
using Microsoft.Azure.ServiceBus;
using Newtonsoft.Json;

namespace Func.Helpers
{
    public class MessageQueueHelper
    {
        public static async Task SendToQueue(SlackRequest slackRequest, MessageQueueConfig config)
        {
            var client = new QueueClient(config.MessageQueueConnection, config.MessageQueueName);
            var json = JsonConvert.SerializeObject(slackRequest);
            var body = Encoder.StringEncode(json);
            var message = new Message(body);
            await client.SendAsync(message);
            await client.CloseAsync();
        }
    }
}

Here is how easy it is to setup an Azure Function that automatically reads message from a queue as soon as they are placed on:

using Func.Models;
using Microsoft.Azure.WebJobs;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;

namespace Func
{
    public static class ReadQueue
    {
        [FunctionName("ReadQueue")]
        public static async Task Run(
            [ServiceBusTrigger("myqueue", Connection = "MessageQueueConnection")]
            string myQueueItem, 
            ILogger log)
        {
            log.LogInformation($"Read Item: '{myQueueItem}'");
            var request = JsonConvert.DeserializeObject<SlackRequest>(myQueueItem);
            // code to handle request...
        }
    }
}

For JavaScript, using this npm package, queueing looks like:

const queueClient = serviceBusClient.createQueueClient("my-queue");
const sender = queueClient.createSender();
await sender.send({
  body: "my-message-body"
});

And receiving is as easy as:

const queueClient = serviceBusClient.createQueueClient("my-queue");
const receiver = queueClient.createReceiver(ReceiveMode.peekLock);
const myMessages = await receiver.receiveMessages(10);

In Conclusion …

Azure Service Bus is a great solution for decoupling your applications and protecting against peak loads. You can keep it simple, and cheap, with the basic and standard tiers for most applications, and the libraries available for several languages make it very easy to implement.

If this article made you curious about Azure Service Bus, I encourage you to set up an account in Azure and give it a try. You will have some working code within an afternoon and gain a better perspective on just how easy it is to work with Service Bus.