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:
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
]
