Messaging between application components and devices is why engineers invented computer networks. The ultimate computer network is the Internet, which has practically connected all the world’s devices to a single network where any one device can send a message to another device. For this reason, there are tons of solutions that provide messaging infrastructure to help broker messages between different kinds of clients and for different use cases. Azure alone has at least eight different services that systems can use to send messages. Some of these are general-purpose, while others are purpose-built. Here, we’ll briefly look at these and discuss when you may want to choose one over the other.
Service Bus is the most general-purpose messaging platform on Azure of all the offerings. It supports many standard features that messaging platforms perform around topics and queues. Service Bus provides multiple protocols, including AMQP, HTTPS, and Java Message Service API. Services bus offers other features, such as automatic forwarding and filtering for topic subscribers.
What it is for: a general-purpose message platform.
When to use it: as a default option for messaging in an application, for asynchronous communication patterns between microservices, CQRS patterns, worker queues, notifications, etc.
How to use it: Microsoft provides several SDK’s for both administering Service Bus and for sending and receiving messages. For other platforms, the resource offers management API’s. Standard libraries for AMQP work with Service Bus.
Storage Queues are a simple but effective way to establish messaging between publishers and subscribers. Storage Queues use the HTTP protocol and therefore do not “push” messages from the queue to the subscriber. Instead, the subscriber must poll the storage queue for the messages. However, Storage Queues offers a messaging platform that performs the same way queues on a message bus work for almost all intents and purposes. Azure offers numerous integrations that can be triggered by Storage Queues, like Azure Functions or Logic Apps.
What it is for: Lightweight messaging between systems that do not need the performance of a message queue.
When to use it: Anytime an application needs queue-based messaging but does not need the performance or scale offered by other cloud-based options like Service Bus.
How to use it: Microsoft provides several SDK’s for both administering Storage Queues. Storage Queues offer a REST API for managing queues, sending messages, and receiving messages.
Event Hubs are built atop Service Bus but are optimized for streaming data. Message publishers emit events that are enqueued to an Event Hub, and Event Hubs can persist the messages in cold storage. However, the primary mode is to funnel these event messages to a real-time processor, such as Kafka or Azure Stream Analytics, to perform real-time analysis, transformations, filtering, and aggregations against the message data. The output from Event Hubs can be cold storage or some other hot-path consumer, but the intent is that the output from this kind of message is that the results become immediately available. Event Hubs are built atop Service Bus, so it supports AMQP, HTTPS, and the Java Message Service API.
What it is for: an ingestion event for real-time event processing.
When to use it: to receive messages from clients, such as daemons, that send event messages; as an output from IoT Hub; as input for Stream Analytics and Kafka.
How to use it: Microsoft provides several SDK’s for both administering Event Hubs and for sending and receiving messages. The libraries can also access data that has been persisted in cold storage. For other platforms, the resource offers management API’s. Standard libraries for AMQP work with Service Bus.
IoT Hub is another specialized solution designed to handle messaging at scale for IoT deployments. Each IoT gets a queue for receiving messages and can publish messages to the IoT Hub either directly or through an IoT Edge proxy. IoT Hub integrates with the other IoT offerings on Azure, including IoT Central, Azure Precept, and other services like blob storage for sending files. The patterns implemented through IoT Hub support device management, security, and commanding through IoT Hub. IoT Hub supports many popular messaging formats, including AMQP, MQTT, and HTTPS.
What it is for: as a message broker and management gateway for large-scale IoT deployments.
When to use it: Whenever deploying IoT devices that need a centralized platform for managing and communicating with devices,
How to use it: Microsoft provides several SDK’s for administering IoT Hub and specialized SDK’s for devices that leverage either IoT Edge or IoT Hub. All administrative and IoT functionality can work through API and standard messaging libraries for supported protocols.
Event Grid Topics
Event Grid Topics work like topics on a message bus where multiple subscribers can access the same topic. A topic in Event Grid is invoked by some event on Azure, such as a new blob created in Blob Storage. The subscribers are notified of these events. Event Grid topics allow things like Logic Apps, Functions, Service Bus, Event Hubs, and other integration points to subscribe to event topics. Event Grid Topic integrations is accomplished through configuration. They are SDK’s for configuring the topics and the integrations with them.
What it is for: to respond to events that happen in the Azure context.
When to use it: when an application, workflow, or pipeline needs to start or respond to something within the Azure context.
How to use it: Event Grid Topics are more configuration than anything. These can be configured through code, such as ARM templates, the Azure Portal, CLI tools, or SDK’s
SignalR is a library within the context of the .NET framework that allows for push-style messages from a server to a client. Typically, clients are responsible for initiating the communication with a server in web apps or mobile apps over HTTP or HTTPS. WebSockets can broker server-initiated messages, but these usually require more complex code to set up on both the client and server. SignalR abstracts these complexities away, allowing a client to receive messaging from the server through a WebSocket connection or long polling. Either way, the application gets messages from the server. The developer does not have to write the code to implement this.
SignalR Service provides a purpose-built platform that allows clients with the SignalR library to receive messages and server-side applications to send messages. It acts as a broker between server-side code and client libraries, thereby simplifying deployments, especially for web apps deployed on platform as a service offerings like Azure App Services.
What it is for: Sending messages from a server to a client through HTTP.
When to use it: when a server needs to send data to a web app or a mobile app while the app is running
Notification Hub is a service that provides a unified experience for sending push notifications to mobile devices. A push notification is a message that a user receives from a service associated with an application. Rather than have every service install its daemon on the phone to receive messages on a device, platform providers created a centralized service that any application can use. Each device only needs one daemon to receive messages for every application that wants to send push notifications, saving battery life and other system resources on a mobile device. Notification Hub supports Windows, iOS through APN, and Android through Firebase.
What it is for: Sending push notifications to mobile devices
When to use it: to integrate messaging from the cloud to mobile devices, such as weather alerts, sales events, or other types of messages.
How to use it: Notification Hub offers a unified experience for applications across Android, iOS, and Windows, thereby simplifying push notifications for mobile devices. It still requires registrations with each of these different services to use, and the services will need to be configured with Notification Hub. Mobile apps and Windows apps will need to implement the appropriate client-side code to subscribe to push notifications.
Send Grid is a third-party email delivery service offered through the Azure Portal. SendGrid provides an API to send messages or SMTP integration for applications that do not support the SendGrid API. Send Grid is a trusted message provider; therefore, messages sent through SendGrid are less likely to be flagged as spam. The ubiquity of email makes SendGrid an essential service on Azure for application integrations.
What it is for: for sending email messages.
When to use it: Any time an application needs to send an email message in bulk (such as marketing campaigns) or individual (such as password resets).
How to use it: The preferred method for SendGrid is to use the SendGrid API’s for which there are also SDK’s. However, where it’s not possible, SendGrid still supports SMTP logins for sending messages.