Azure Service Bus is a cloud messaging platform that facilitates reliable communication between applications and services, both in the cloud and in hybrid environments, designed to support complex business integration scenarios. The service offers advanced functionality for managing and resolving transactions, making it an ideal solution for distributed architectures that require efficient asynchronous communication where applications can exchange messages in a secure and scalable manner, regardless of demand fluctuations or load peaks. In this article, we'll take a look at what Azure Service Bus is, how it works, what are the differences with other Azure messaging services, and what are the costs and pricing plans provided for the service.
An application may need a fast track to communicate and transfer data or files to other applications or services. When there are multiple applications and services that operate together depending on each other, properly managing this transfer can become a serious problem.
This type of communication operations between apps, services and users is very important and must be managed correctly and to our rescue comes Azure Service Bus of Microsoft Azure, a messenger that helps with this specific data transfer.
Service Bus is a message-broking service that facilitates the transfer of messages and has advanced features that can help developers and their applications deliver them efficiently. The service is fully managed by Microsoft with regard to the underlying infrastructure, which means that users don't have to intervene to configure it, saving precious time and money.
Message topics and queues allow the transfer of messages between apps and services to be treated with versatility, allowing applications to function properly and smoothly face data transfer challenges. Service Bus also allows applications and services to operate independently, giving them the advantages of using fewer resources and having fewer points of failure.
But how does it work specifically? When to use it? Let's see it together.
Azure Service Bus provides a secure and reliable way to send and receive messages between various applications, services and devices, using the Advanced Message Queuing Protocol (AMQP) - the same protocol used by other messaging systems such as RabbitMQ, Apache Qpid, IBM MQ, ActiveMQ. However, it is not the only one that can be used and the platform also supports SBMP (Simple Blockchain Messaging Protocol) and HTTP/HTTPS.
The definition of 'messaging service' could mislead those who are not familiar with computer terminology. In this case we are not talking about messages exchanged between users as in applications like WhatsApp or Teams but instead we are talking about data transfers between applications and services.
A message contains data that is sent from one application and will be consumed by another app and consists of two main parts:
This type of messaging has several advantages for software developers who need to make different applications communicate with each other, the most important of which are:
In general, there are two scenarios in which it is commonly decided to use a message-oriented system such as Azure Service Bus:
The exchange of messages between applications that use Service Bus can be carried out using two different structures: queues and arguments. Let's take a closer look at them along with other key Service Bus features.
Queues (queues) are a data structure that stores messages sent between two or more applications/services. A message is kept in a queue until it is retrieved by a receiver.
A queue is basically the implementation of the FIFO (First-In-First-Out) data structure, which means that the first message that arrives in the queue will be the first message to be processed. In other words, messages are delivered and processed in the order in which they are received, ensuring a linear time in their processing. In a queue-based messaging system, it's common to have one or more producers sending messages to the queue and a single consumer receiving and processing the messages.
Note that the maximum queue size is 80 GB (if you expect the queue size to grow beyond that limit, you can consider using the service's Premium plan to circumvent these types of limitations).
Topics are a data structure that allows you to publish messages that will be received (subscribed) by multiple receivers (each receiver has its own subscription, it's not 'Azure Subscription' as the name might suggest). It's similar to a queue, but it allows multiple subscribers to receive copies of the same message. When a message is published/sent to a topic, it is delivered to all the subscribers of that topic (each subscriber will receive a copy of the message and can process it independently).
Keep in mind that, even after all subscribers have received the message, it will not be automatically deleted from the topic. Subscribers must explicitly delete the message after it has been processed, otherwise it will remain in the topic and may be delivered back to the subscribers.
You can create rules on a subscription. You can have a filter to define a condition for the message to be copied into the subscription in case you don't want a subscription to receive all the messages sent to a topic. You can also have an optional action that can modify the metadata of the message, in case you want to enrich the messages with extra metadata when they go through a subscription.
You can create filters for subscribers to define which messages they want to receive from a topic. These messages are specified in the form of one or more named subscription rules. Each rule consists of a filter condition that selects particular messages and, optionally, contains an action that annotates the selected message. Service Bus supports three filter conditions:
A namespace is a logical container that provides a scope for organizing and managing messaging resources. It is the management and logical isolation unit within which Azure Service Bus queues, topics, subscriptions, and other objects are created and used.
It is therefore nothing more than an isolated work environment that allows you to efficiently organize and manage messaging resources within the Azure cloud environment.
When you create a namespace in Service Bus, you get a unique endpoint to access messaging services within Azure. This endpoint can be used by applications and services to send and receive messages through queues or topics managed within the namespace.
Sessions are a feature that can be enabled on queues and topics, allowing you to group a set of related messages and process them as a single unit. By enabling sessions on a queue or topic, each message is associated with a session identifier, which you can use to group messages together and process them.
If you want to use sessions with Azure Service Bus, you can create a queue or topic with sessions enabled, and then create a message consumer that can manage session-aware messages.
When sending a message to a queue or topic with sessions enabled, you can specify the session identifier for the message, which will determine which session it belongs to. When the consumer receives the message, they can use the session identifier to identify the session and process the session's messages as a unit.
This functionality may be useful in the following situations:
We have created the Infrastructure & Security team, focused on the Azure cloud, to better respond to the needs of our customers who involve us in technical and strategic decisions. In addition to configuring and managing the tenant, we also take care of:
With Dev4Side, you have a reliable partner that supports you across the entire Microsoft application ecosystem.
Microsoft Azure, among the many services offered, provides other options dedicated to messaging in addition to Azure Service Bus. Each of them is aimed at covering certain types of scenarios and situations but the difference may not be immediately apparent, especially if you are not familiar with the topic.
In this section, we will therefore dedicate some space to the comparison between Service Bus and two other of the most important Azure services dedicated to messaging, namely Azure Event Hub and Azure Queue Storage, and we will try to understand what are the key differences with Service Bus and which one to choose at the right time to meet your development needs.
Azure Service Bus and Azure Event Hub, although both messaging services, have distinct characteristics and purposes. To understand the difference between the two, we must first grasp the distinction between a message and an event.
A message, as we have already seen, is a raw data produced by a service to be consumed or stored elsewhere. The message contains the data that triggered the message pipeline, and the publisher of the message has an expectation of how the consumer will handle it on their side.
An event, on the other hand, is a light notification of a condition or a change in state. The publisher of the event has no expectations about how the event will be handled, and the consumer of the event decides what to do with the notification.
Azure Event Hub is designed to manage and process large volumes of telemetry data and event flows in real time and is optimized for the continuous collection and processing of data from a wide range of devices and applications, ensuring high ingestion speed and horizontal scalability.
The main objective of Event Hub is to efficiently manage large amounts of data rather than ensuring the exact and orderly processing of each event, and its functionalities include the ability to capture millions of events per second and send them to analysis or archiving platforms for further processing.
Service Bus, on the other hand, is designed for complex integration scenarios and communication between applications in business contexts and offers advanced messaging features such as support for queues, topics and subscriptions that make it ideal for applications that require a high degree of reliability, precise ordering of messages and accurate management of transactions.
The choice between Azure Service Bus and Azure Event Hub depends on the type of scenario and the specific needs of the application. Azure Service Bus is best suited for scenarios that require a high level of reliability and control over messages, such as inter-application communications in business environments. Azure Event Hub, on the other hand, is the preferred choice for scenarios that require the collection and processing of large volumes of data in real time.
Azure Storage Queue is a service for storing large amounts of messages. You can imagine it as a kind of post office: you send messages to the queue and whoever the recipient is able to pick them up when they are ready. This allows asynchronous message queuing that works by holding back messages that need to be recorded by an application.
Service Bus, compared to Azure Queue, is a much more complex service that acts as a broker between applications, allowing them to exchange messages in a decoupled manner to improve scalability and resilience.
Storage Queue, being the simpler of the two services, tends to excel in scenarios where high throughput is needed. It is designed to handle a large volume of messages, making it suitable for applications that need to process thousands of messages per second.
Azure Service Bus, on the other hand, is designed for more complex scenarios that require advanced functionality. While it may not offer the same raw performance as Azure Storage Queue in terms of number of messages, it compensates with its extensive capabilities, making it more suitable for enterprise-level messaging scenarios.
Both services are highly scalable, but in different ways. The scalability of Storage Queue is primarily horizontal, meaning that it can handle a high number of messages while Service Bus offers greater vertical scalability and is designed to handle a wide variety of message types, including more complex and larger messages.
If you need a simple, high-throughput messaging service, Azure Storage Queue might be the right choice. However, if you need more advanced functionality and need to manage a higher level of complexity, Azure Service Bus might be a better choice.
Azure Service Bus pricing is structured to offer flexibility based on usage needs and required characteristics. There are different pricing plans, each with specific features and costs.
The Basic plan is the first and offers a low basic cost and includes the essential functionality of code, but without support for topics and subscriptions, nor for advanced functionality such as sessions or transactions. This plan is ideal for simple, low-volume messaging scenarios, but it's a bare option that doesn't allow you to fully exploit the potential of Service Bus.
The slightly higher cost Standard plan supports queues, topics, subscriptions, transactions and sessions, with a limit of 1,000 concurrent connections per messaging unit. This plan is suitable for applications that need advanced functionality and manage moderate message volumes and is the real “basic plan” of the service, as it allows you to take advantage of its advanced features, albeit with limitations. Ideal for small and medium-sized businesses that want to get the most out of the service with an eye on their wallet.
The Premium plan, the most expensive of the three, includes all the features of the Standard plan with the addition of resource isolation to improve performance, lower latency, high throughput, and greater scalability. There are no quota limits on message and queue sizes, making it ideal for mission-critical applications and high-volume message scenarios that require high performance and low latency. It's the perfect plan for large businesses.
The Azure Service Bus costs are determined by several components. Messaging operations, which include sending, receiving, and deleting messages, are charged per million transactions, with different rates depending on the plan chosen. Inbound data transfer is free, while outbound data transfer may be charged based on the amount of data transferred beyond the free thresholds. In addition, there may be additional charges for the number of concurrent connections that exceed the limits included in the chosen plan.
The storage space used by messages in the queue or topics is also subject to costs, based on the amount of storage space used. Messages can be kept up to a certain time limit (Time-to-Live), and there may be additional costs if special configurations are used.
For more details on the prices and to calculate the estimates for the use of the service, please consult the Azure main page, where with the convenient calculation tool provided by Microsoft you can get a more precise idea of the costs based on the intended use.
Azure has established itself over the years as one of the most popular and used cloud computing solutions in the field of corporate digital infrastructures thanks to the size, variety and quality and reliability of the services it offers.
In particular, with regard to the last two, Azure Service Bus is not an exception within the landscape of services offered by Microsoft's cloud computing platform. With its scalable capabilities and its quick and simple deployment, the messaging service represents a solid choice for organizations looking to improve their communication architecture.
Developers from all over the world work every day with Microsoft Azure to simplify and accelerate the process of creating and implementing their software, and Azure Service Bus aims to solve all those complex problems that these developers regularly face in the development of quality and reliable cloud messaging solutions to be used within their applications.
Why not try it out and let the service speak for itself?
Azure Service Bus is a fully managed enterprise message broker that allows for reliable cloud messaging between applications and services, even when they are offline. It ensures seamless communication and data exchange between different components of a distributed system.
Azure Service Bus decouples applications by enabling them to communicate through messages instead of direct connections. This reduces dependencies between different parts of a system, making it easier to scale, update, and manage applications independently.
Azure Service Bus supports several messaging patterns, including point-to-point communication with queues, publish/subscribe messaging with topics and subscriptions, and message sessions for ordered processing.
Azure Service Bus ensures message delivery through features like message durability, retries, dead-lettering, and duplicate detection. These mechanisms guarantee that messages are reliably delivered even in the face of network issues or service interruptions.
In Azure Service Bus, queues are used for point-to-point communication where each message is received and processed by a single consumer. This pattern is ideal for load balancing and asynchronous processing.
Topics and subscriptions in Azure Service Bus enable publish/subscribe messaging. Topics allow multiple subscribers to receive a copy of each message, enabling communication with multiple receivers. Subscriptions can be filtered to receive only specific messages.
Azure Service Bus handles message ordering using message sessions. By grouping related messages into a session, the service ensures that they are processed in the order they were sent, maintaining consistency in processing.
Dead-lettering in Azure Service Bus is a mechanism to handle messages that cannot be delivered or processed. Messages are moved to a dead-letter queue when they exceed retry attempts, allowing for later inspection and resolution.
Azure Service Bus can be integrated with other Azure services like Azure Functions, Logic Apps, and Event Grid to build robust, scalable, and event-driven architectures. This integration enhances the capabilities of cloud-based applications.
Azure Service Bus provides security features such as Shared Access Signatures (SAS), Azure Active Directory (AAD) authentication, and role-based access control (RBAC) to ensure that only authorized users and services can access messaging resources.
Azure Service Bus ensures scalability by allowing automatic scaling of messaging resources based on demand. It supports a large number of queues, topics, and subscriptions, as well as high throughput to handle varying loads efficiently.
Azure Service Bus supports a maximum message size of 256 KB for standard tiers and up to 1 MB for premium tiers. Messages larger than these limits can be stored in Azure Blob Storage, with only references sent through Service Bus.
Azure Service Bus supports high availability through geo-redundancy and automatic failover capabilities. It ensures that messages are not lost and that the service remains available even in the event of data center failures.
The Modern Apps team specializes in development and integration across the entire Microsoft 365 ecosystem. We design native applications for Microsoft and Azure platforms, and implement business processes that integrate with and maximize the investment in Microsoft 365.
