Azure Event Hubs vs Service Bus

Introduction

Event Hubs and Service Bus – What’s the difference between the two messaging services? When should we use what? These are some of the common questions raised when the discussion is on Azure Messaging Services. So, this blog will help its readers not only find a solution to the above questions but also identify the strengths and unique capabilities of the two mentioned services. So, hang on tight as we are about to jump in!

Azure Event Hubs

Azure Event Hubs is a data streaming service that streamlines the data pipeline for the users allowing them to catch a better look at the insights received from various locations. It receives and processes millions of events per second with high throughput and low latency.  The basic definition for it is that it decouples multiple event-producers from event-receivers.

Event Hub is one of the messaging systems in Azure that provides a key capability of multiple sender/receiver concept. So, what it basically does which differentiates from other messaging systems is that it allows the “Senders” to pass a message with high throughput and streamlines it in the partitions which are available in the Event Hubs. It may have single or multiple consumer groups to receive those messages.

 Event Hubs also has the unique ability to ingest massive volume of data (1 million messages per second) in an unmatchable speed. It easily incorporates with other Azure Services like;

• Stream Analytics
• Power BI
• Azure storage

Some common scenarios where Event Hubs can play a crucial role includes;

• Logging and telemetry
• Data archiving
• Capturing and storing the data in Azure storage
• Transaction processing

Azure Service Bus

Azure Service Bus acts as a messaging backbone for any application available in the cloud. So, what Service Bus basically does is that it connects any devices, application or services running in the cloud to any other applications or services and transfers data between them. The data being transferred can be in XML, JSON, or text format.

Service Bus Namespace – Can be referred to as the heart of the Service Bus. It serves as the application container and has the ability to hold multiples queues and topics. A namespace can be created using platforms like Azure portal and Service Bus Explorer.

Some of the common messaging scenarios where Service Bus is the need to implement are;

Messaging – Allows users to transfer business data

Decouple applications – Helps users improve reliability and scalability

Topics and subscriptions – Helps to build an end-to-end relationship between message senders (publishers) and message receivers (subscribers)

Azure Service Bus provides three forms of pricing tier which is the basic, standard and premium plan. Some of the differences between the cost models are;

Azure Service Bus Fundamentals

Azure Service Bus Relies on the following two concepts;

• Queues
• Topics

Queues

Queues work based on one-to-one communication model. It enables you to store messages until the receiver is available to receive and process them i.e. the message passed to the queue by the sender will be stored in it until the receiver comes online to collect and process it. So, each queue acts as a broker that stores the sent message until they are collected by the receiver (client).

Messages in queues are delivered in “pull” mode which means that the receiver must ask for the particular message they need. It also works based on the FIFO (First-In-First-Out) model enabling the receiver to pick the messages in the front of the queue.

Topics

Topics in Service Bus work as a one-to-many communication model. There will be multiple subscribers on the receiving side who can access the same message passed by the sender. One unique capability of Service Bus Topics is that it enables the subscribers at the receiving end to apply filters. The filter option enables the subscribers to subscription-based on a certain criterion enabling them to only receive the message they care about.

Topics vary from Queues in a way where the subscribers will be notified when a message of their interest arrives whereas the receiver from the queue will not be notified.

Azure Event Hubs vs Service Bus

Both the messaging systems have a unique architectural advantage and are built for certain purposes, let’s take a look at the significant difference in the internal working of the services and their real-time use cases.

Use Case

Azure Event Hubs focuses more on event streaming whereas Azure Service Bus is more focused on high-value enterprise messaging, which means the later is focused on messages rather than events.

If you are implementing a pattern which uses a Request/Reply message, then probably you should use Azure Service Bus.

Azure Event Hubs is more likely to be used if you’re implementing patterns with Event Messages. If you want a reliable event ingestor which can deal massive scale of event messages, then preferably you should go for Event Hubs.

Internal Working

Receiver Side

Let’s now consider, the aspect of how a receiver will receive the messages in both the messaging platforms.

In Event Hubs, the messages received from various event producers will be stored in a single stream from where the receivers can look but cannot remove it. Whereas, in Service Bus, the receivers can get their own copy of the message which means that it works based on the receive/delete model for collecting message.  

Messaging Concepts

In the messaging scenario, Service Bus provides many useful capabilities like Dead-lettered queues, property-based routing and more, but Event Hubs lacks all these features because it serves the sole purpose of allowing the event platform to handle the large volume of messages.

Time to Live and Retention

Service Bus messaging supports a message property ‘Time to Live’ which supports defining when a message can be moved to the dead letter queue by enabling dead lettering on expiry.

Event Hubs provides a slightly different capability, there is no specific time to live for an event but there is a retention policy on the hub. The default retention period is 7 days and can be extended if required.

Message session

Azure Service Bus has the concept of message session. It allows relating messages based on their session-id property. It supports achieving rich integration patterns.

Event Hubs do not have message session property, but events can be related by consolidating them in the same partition.

Message Replay

This is one of the unique capabilities of Event Hubs. Since the messages are not removed from the stream by the receiver. The messages in the stream can be processed by simply adjusting the index that the receiver points to.

This capability is not available in Azure Service Bus. Since the messages are pulled out by the receiver, the message cannot be processed again.

Poison Message

There is a chance for the generation of messages that cannot be processed. In Azure Service Bus, these messages can either be sent to dead lettered queue or abandoned.

In Event Hubs, you may handle these scenarios at the receiver side. But you can’t remove a corrupted message from the stream. It must be processed like every other message in the stream.

Scaling

In Azure Service Bus messaging you can scale up the receivers of a message by using Competing consumer pattern.

In Event Hubs, you will need to increase the partitions and assign a single processor for each partition.

Integration

Event Hubs and Service Bus integrates with several Microsoft feature to do exciting things with the events/messages received. So, Event Hubs works along  with the following list of Azure services;

• Azure SQL DB
• Azure Storage
• Stream analytics
• Power BI
• Machine learning

Whereas, Service Bus can integrate  with;

• Azure Functions
• Azure Logic Apps
• Azure Event Grid
• Stream Analytics
• Dynamic 365

Cost

The Cost Model between both the Azure Services varies according to the pricing tier which the user chooses. There are three pricing tiers in both the Azure service. They are the Basic tier, Standard tier, and Premium/Dedicated tier. All the Pricing Models follows three basic rules;

• No upfront cost
• No termination fees
• Pay only for what you use

So, the cost model for Event Hubs (in dollars) is as follows;

The cost model for Azure Service Bus can be classified for Messaging operations, Brokered connection, and Hybrid connections;

Messaging Operations

Brokered Connections

Hybrid Connections

Monitoring options for Azure Service Bus and Event Hubs

There are several monitoring options available on Azure Service Bus and Event Hubs in the Azure portal. To monitor an application composed of these services requires significant knowledge on the available monitoring options in the Azure. Or as an alternative, you buy an off the shelve product, Turbo360, to fulfill the monitoring requirements of the operations team.

Azure Monitor

• Metrics
• Alerts
• Service Health

Metrics

Metrics in Azure Monitor are stored in a time-series database which is optimized for analyzing time-stamped data. This makes metrics particularly suited for alerting and fast detection of issues. They can tell you how your system is performing but typically need to be combined with logs to identify the root cause of issues.

Alerts

Metric alerts in Azure Monitor provide a way to get notified when one of your metrics cross a threshold. Metric alerts work on a range of multi-dimensional platform metrics, custom metrics, Application Insights standard, and custom metrics. 

Service Health

Azure Service Health is a suite of experiences that provide personalized guidance and support when issues in Azure services affect you. Azure Service Health can notify you, help you understand the effect of an issue, and keep you updated as the issue resolves. Azure Service Health also can help you prepare for planned maintenance and changes that could affect the availability of your resources.

Turbo360 offers extensive monitoring capabilities for Event Hub and Service Bus.

Turbo360 (Extensive off the shelf product)

In Turbo360, it is possible to monitor the performance, status, metrics and more for Azure Service Bus and Event Hubs with various types of monitors. For Event Hubs and Service Bus, Turbo360 offers three types of monitors;

• Data Monitor
• Threshold monitor
• Status Monitor

Data Monitor

When there is a need to monitor the availability, performance, Incoming and outgoing requests, and connection state, the better solution would be data monitor. With the extensive set of metrics, it is possible to monitor the above needs and even more. This data monitor provides a historical record of alerts in a calendric view.

Threshold monitor

When there is a need to monitor the entities when the message count gets increased certain limit or when the state of an Event Hubs will not be in an expected state, Threshold monitor would be a right solution. In this we can configure the violation persists time and number of alerts per violation. It can even be scheduled. It is also possible to monitor the Topic subscription for Service Bus as well as Partitions for Event Hubs.

Status monitor

This status monitor can be used when there is a need to get a consolidated report in alert at defined intervals say every hour. This status monitor can monitor Service Bus and Event Hubs based on some basic properties and their state. Similar to the Threshold monitor it is also possible to monitor the Topic subscription for Service Bus as well as Partitions for Event Hubs.

Wrap Up

Hope this blog provides a better understanding to the readers on the difference in capabilities of Azure Service Bus and Azure Event Hub. Both the messaging platforms of Azure discussed in this blog, Service Bus and Event Hub have specific business use cases in real-time business scenarios.