Recently, Microsoft announced the public preview release of the Last Will and Testament (LWT) support in Azure Event Grid's MQTT broker capability, which complies with the MQTTv3.1.1 and MQTTv5 specifications.
Azure Event Grid is a cloud event broker that enables developers to integrate their solutions using mechanisms like HTTP pull delivery, HTTP push delivery, and MQTT broker capability. The latter capability, introduced in June last year, leverages standard features from the MQTT protocol to enable clients to communicate in a reliable, secure, and scalable manner.
MQTT, previously known as "MQ Telemetry Transport," is a lightweight pub-sub protocol initially developed by IBM as a companion to its MQ product. IBM later proposed its standardization to OASIS, transforming the initial specification into version 3.1.1. Subsequently, version 5.0 evolved from this groundwork, with substantial contributions from Microsoft during the development process by the Oasis MOTT Technical Committee.
Developers can now leverage LWT in the MQTT broker functionality of Azure Event Grid, ensuring the predictable and dependable flow of communication among MQTT clients during unexpected disconnections. For example, in IoT systems where data flow is continuous, other devices must detect this situation and take the necessary precautions if a device unexpectedly loses its connection. LWT is an ideal solution for such scenarios. LWT allows a device to publish its last message on a specified topic through the broker, enabling other devices to detect this situation and take the necessary precautions quickly.
(Source: Tech community blog post)
LWT operates by including a "will message" and relevant properties in the CONNECT packet during client connection to the MQTT broker. The will message is disregarded if a client disconnects gracefully with reason code 0x00 using the MQTT DISCONNECT packet. However, the broker will publish the message to all subscribed clients if the disconnection is ungraceful. Subscribers can respond quickly by redistributing tasks, reallocating responsibilities, or adjusting behavior to maintain system performance and stability.
Other public cloud providers like AWS and Google offer a service similar to Azure Event Grid. For instance, AWS EventBridge, a serverless event bus service that makes it easy to connect applications using data from other applications, integrated Software-as-a-Service (SaaS) applications, and AWS services. Yet it does not have an MQTT broker feature like Azure EventGrid since it primarily focuses on HTTP/S and AWS services integration; however, developers can bridge MQTT clients with Amazon EventBridge using custom event buses and integrating with AWS services like AWS IoT Core or AWS Lambda. Similarly, Google’s Eventarc does not have an MQTT broker capability. On the Google Cloud, developers can run a standalone MQTT broker on Compute Engine or GKE.
Microsoft remains committed to MQTT enhancements within Event Grid as George Guirguis, a product manager of Azure Messaging at Microsoft, writes:
Event Grid is committed to ongoing investment in MQTT features to align with MQTT specifications and better support evolving IoT scenarios, ensuring continuous enhancement to meet industry demands.
Lastly, Azure Event Grid uses a pay-per-event pricing model; its pricing details are available on the pricing page.