.png)
Azure Service Bus – Everything you need to know about this cloud based solution.
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. Azure messaging services have evolved over
time with multiple options. It is important to understand all the options to
make the right decision when to use what service. At the face of it, the
technologies might look like they are doing pretty much the same thing, but
there might be significant differences and there is a reason for their
existence.
As Azure Service Bus is fully managed service, scaling and availability will
be taken care by Azure team. It is integrated with other Azure services like,
Event Grid, Logic Apps, Stream Analytics etc. Azure Service Bus provides
reliable and secure asynchronous message communication platform along with
facility of delayed processing of events or data. Shared Access Signatures
(SAS), Role Based Access Control (RBAC) and Managed Service Identity (MSI)
protocols are supported by it. Service Bus also supports client libraries for
.NET, Java, JMS.
Service Bus Tiers with Features
Features of Service Bus are available in two tiers; Premium and Standard.
Standard tier: It can
be used for initial development and QA environment deployments. Latency and
throughput in Standard tier are variable, hence performance is not predictable.
In built scaling is also not available and maximum message size is upto 256 kb.
Premium tier: It can be
used for Production deployments. It provides high throughput and auto scaling
for variable workloads. Maximum message size can be up to 1mb. Premium name
spaces provides CPU and memory level isolation for resources. Performance of
Premium tier resources at peak load is much faster than Standard ones.
Azure Service Bus offers three types of communication mechanisms; queues,
topics and, relays. Queues and Topics, facilitate one-directional
communication. Messages will be stored until they are consumed. Each message in
Queue is received by a single recipient. Topic can have multiple subscriptions
for multiple receivers. Subscriptions can choose to receive messages based on
parameters. Messages from Queues and Topics can be accessed using Service bus-defined
messaging APIs or REST APIs. SDKs are also available for other languages.
Unlike Queues and Topics; Relays provide bi-directional communication and does
not store messages. To use these messaging services, user must create namespace
under Azure subscription. A namespace can be visualized as a logical container
for messaging components. Multiple Service Bus components (queues, topics and
relays) can reside within a single namespace.
Azure Storage Queues: Azure Storage Queue is a service for storing large numbers of messages
that can be accessed from anywhere in the world via authenticated calls using
HTTP or HTTPS. A single queue message can be up to 64 KB in size, and a queue
can contain millions of messages, up to the total capacity limit of a storage
account. In systems that require intense processing, handling it all in a
single process is virtually impossible. Possible processing failures, outages,
hardware limitations, or cost constraints prescribe to divide work into chunks
and distribute to processes that can handle it. This also helps with the
responsibilities concern, where a process doesn’t have to assume all the
responsibilities and turn into a monolithic system. The approach is to divide
work among processes and distribute or delegate among other processes. While
this approach sounds straight-forward, several considerations need to be made
such as temporal coupling, outages, workloads, and more.
While Storage
Queues service provides the necessary means for queueing, there are domains
where you require real messaging. Usually, that means supporting features that
involve compute and processing behind the scenes on behalf of the service.
That’s where Azure Service Bus (ASB) service shines. The features it provides
are genuinely impressing. Some of those are:Scheduling, Dead-lettering, Transactional
processing, Message ordering, Expiration (TTL), Duplicate detection, Deferring, Pub/Sub and
much, much more
Event Hubs: So far, the
focus was on individual messages where each message is discrete and important.
With ASB there’s support for messages that represent events, but those are not
streams of events. Scenarios such as telemetry require a different approach to
handling messages. Ability to capture events that arrive at high volumes.
That’s where a third Azure message service comes in, Event Hubs. This is a
service that is specifically built to deal with event streams. With exceptional
ingress rates, it can take on many incoming messages storing those internally
offering no queue semantics. While it might sound like a significant drawback,
it is highly optimized for the one job it has – store events to allow later
processing by the consumers on their terms and conditions. Consumers are the
ones that manage events reading and decide wherever to move the reading cursor
forward or go back to already read messages. With this level of power comes the
responsibility to manage the cursor. Often, data read is streamed into other
services for analysis or persistence. Event Hub, Capture feature helps with
that by allowing periodically export events to Storage Blob service using Avro
format.The service has processing power and is expressed in Throughput Units,
where each TU is capable of up to 1MB/s or 1,000 msgs/s of ingress and 2MB/s or
2,000 msgs/s of egress. While TUs must be pre-allocated, EH service offers Auto
Inflation feature, preventing message ingestion from ever been throttled.
Dedicated tier of the service also offers an extended event retention period.
EH is making a conscious preference in favor of throughput over features.
Event Grid: Event
Grid (EG) is one of the relatively latest additions to the Azure
messaging services family.
This toddler service is making big splashes and at times feels like a threat to
its older siblings. After all, the questions it raises are valid.
What was missing
there that a fourth messaging service had to be introduced?
How is different
from Azure Storage Queue, Azure Service Bus Queue, and Event Hub?
Is Event Grid
going to replace some of the other messaging services?
To answer these,
let’s see what problems already exists that messaging services didn’t address
that Event Grid can.
The world we
live in is reactive. Events take place, and we respond to those events. The
reactive nature of Azure services is no exception to this paradigm. A newly
updated blob to Storage service needs to be processed to import data into
CosmosDB. A provisioned resource needs to be tagged. Ability to notify subscribers
scaled-out between multiple regions with non-ubiquitous receiving mechanisms
(webhooks, queues, streams, etc). Reacting to the events taking place on a
cloud-scale is not what the messaging services covered earlier were built for.
That’s what Event Grid was created for.
Event Grid’s
whole purpose is to allow publishing and handling events crossing datacentre
boundaries cheap and straightforward, helping with building reactive
architecture.
As of today,
Event Grid is already supporting several Azure services capable of publishing
events.
Those services
are:
Blob Storage
Storage (v2)
Event Hubs
Service
Bus (Premium)
IoT
Hub
Container
Registry
Resource Groups
Azure Subscriptions
Additionally,
Event Grid supports Custom Topics, expanding this paradigm outside of Azure.
When it comes to subscribing to Event Grid topics and handling events,
currently supported options include the following:
Custom WebHooks: Use
webhooks for customizable endpoints that respond to events.
Azure Functions: Use Azure Functions for serverless response to
events.
Logic Apps: Use Logic Apps to automate business processes for
responding to events.
Storage Queues: Use Queue storage to receive events that need to be
pulled. By sending events to Queue storage, the app can pull and process events
on its own schedule.|
Event Hubs: Use Event Hubs when your solution gets events faster
than it can process the events.
Azure Automation: Use Azure Automation to process events with
automated runbooks.
Hybrid Connections: Use Azure
Relay Hybrid Connections to send events to applications that are within
an enterprise network and don’t have a publicly accessible endpoint.
The list is
short, but it will expand to support all the Azure services. And eventually,
not just Azure services, but beyond that. With already supported CNCF (Cloud
Native Compute Foundation) CloudEvents v0.1, Event Grid can interchange
messages with any system supporting this open standard for events.
Event Grid’s
ability to process millions of messages and being platform or language
agnostic, it is the go-to messaging service to distribute notifications and
build reactive solutions on top of it. Despite its HTTP nature, the service is
engineered for reliability. Built-in retries and dead-lettering offer
uncompromisable guarantee that events are not lost. Reasonably priced to allow
massive scale event publishing and distribution.
Messaging
Services for application: Let us consider a Fly Wheel Cab booking System
described in the overview, where customers hire cabs and do payments to
drivers. This business scenario demands for transactions and those bring in the
need to use Azure Service Bus. It is also required to have instantaneous
consistency, temporal control like if this is not processed in x amount of
minutes then the message should be pushed into the dead letter or elsewhere for
an escalation. When the requirement is these kinds of orchestrated (workflow)
stuff to do state transitions then Azure Service Bus is an appropriate
solution. It’s really like IBM MQ or BizTalk Server, however at cloud scale. In
a nutshell, when you need robustness and cannot afford to lose any messages,
you’ll go for Azure Service Bus. The Vehicle Telematics Application requires to
collect real time telematics data from thousands of vehicles across the world.
The best messaging service that would fit into this requirement would be ‘Event
Hub’. Azure Event Hub is designed with focus on the data point event scenario.
This application requires to handle multiple data streams from different
publishers in parallel. Event Hubs support a partitioning model that allows
keeping related events together while enabling fast and highly parallelized
processing of the individual streams that are multiplexed through the Event
Hubs. The Event Hubs Capture feature automatically writes batches of captured
events into the Azure Storage blob containers and enables timely batch-oriented
processing of events. When reactions occur in the business like, the driver had
accepted the booking, the driver is moving towards the pick-up point, the
customer or driver cancelled the booking in this case instead of doing a
central control workflow you would do in an Event-based model running active
workflows. Here you are reacting to real changes in real-time. Azure Event Grid
is ideal for these kinds of reactive scenarios.
Conclusion: Service Bus
Messaging service has a lot to offer, we cannot cover its all capabilities in
single article. There are Paired Namespaces, AMQP support, Partitioned Queues
and many more. In short, Azure Service Bus helps us to build our loosely
coupled software components with less deployment efforts and with high
Scalability and Availability of communication. By providing three different types
of services, it enables architect/developer to implement different
communication scenarios.
0 Comments