Service Bus Vs Azure Event Hubs

What is Azure Service Bus Event Hubs

Azure Service Bus Event Hubs is a relatively new feature within the Azure Service Bus and is intended to help with the challenge of handling an event based messaging at huge scale.  The idea is that if you have apps or devices publishing telemetry events then Event Hubs can be the place you would send them to and behind the scenes the Event Hub will create a stream of all of these events which can be read at some point in different ways.

Event Hubs provides simple interfaces such as AMQP and HTTP to make it easy for apps to send messages to an Event Hub.  Internally Event Hubs implements a partitioning pattern to allow it to scale to deal with huge bursts of messages and to retain messages for a longer period of time.

In Event Hubs you can define consumer groups which allow you to read the stream of events.  If you only need one receiver to read the stream then you can use the default consumer group, but if you need multiple receivers to read the stream concurrently but at their own rate then each receiver would use its own consumer group.  A receiver will also manage an index (or off set) which is its own pointer to where in the stream of messages it is reading.  A receiver can start at the beginning of the stream and read to the end and then wait for new events or alternatively it can start reading part way through the stream.

The below diagram shows what Event Hubs might look like:

What is Azure Service Bus Messaging

Azure Service Bus messaging is an implementation of modern message queuing concepts implemented in the Microsoft Cloud as platform as a service.  Service Bus messaging has two key areas:

• Queues
• Topics

A queue implements a one way communication where the sender places a message on the queue and a receiver will collect the message soon or sometime in the future.  The queue is a durable entity meaning that a message placed on a queue is saved and can remain on the queue for a long period of time if the receiver is not ready to collect it yet.  A simple diagram showing a queue concept is below:

A topic is similar to a queue except that a message sent to a topic can have a copy of that message forwarded to multiple subscriptions.  A subscription is similar to a queue except that is includes some rules which determine which messages from a topic will go to each queue.  An example of the use of a topic could be to use a fan out pattern where all messages sent to a topic will have a copy sent to each subscription so many applications can get their own copy of all messages.  Another example would be the implementation of a publish and subscribe pattern where the message sent to a topic is only forwarded to a subset of queues based on the rules it matches.  An example would be if a message had a property called “Message Type” and a subscription could say only send messages where the message type is “CustomerUpdate” to the subscription used by the CRM application.

The below diagram is a simple representation of the topic pattern.

Similarities

To the external publisher of an event/message or the receiver or an event/message Service Bus Messaging and Service Bus Event Hubs can look very similar and this is what makes it difficult to understand the differences between the two and where to use what.

The main similarity is that both messaging and event hubs can be interacted with via AMQP so they look conceptually like you’re sending a message to a queue like entity.  Other similarities include:

• Both entities live within an Azure Service Bus Namespace and can be managed in that part of the Azure Portal.
• Both entities can also support an HTTP interface
• Both entities have durability features so that a message can be persisted and received later
• Both entities support a kind of time to live style feature but they are not necessarily the same
• Both options support the same SAS security model by default for sending, receiving and management
• Both options have the same 256kb message size limitation