Blog Post

Messaging on Azure Blog
3 MIN READ

Announcing public preview of MQTT protocol and pull message delivery in Azure Event Grid

arast2019's avatar
arast2019
Icon for Microsoft rankMicrosoft
May 23, 2023

Azure Event Grid is built to handle high scale message routing from any source to any destination for any application by decoupling publishers from subscriber services. Today, we are announcing that Event Grid now supports bi-directional communication via MQTT version 5 and MQTT version 3.1.1 protocols in Public Preview.  We are also announcing the Public Preview of pull delivery of messages on custom topics, which gives applications more flexibility to handle events and enables the use of private links when receiving events.  

 

 

Azure's MQTT broker

MQTT support is driven by the evolution of Internet of Things (IoT) solutions like connected homes, connected cars, healthcare monitoring, transportation, and asset tracking, which is generating dramatic growth in devices and connections. Using Event Grid, enterprises can now harness the power of data from devices, applications, users, and processes, to scale their business and deliver compelling digital experiences for their customers.

 

This makes Azure Event Grid the first of its kind, MQTT broker in Azure, enabling users to send billions of messages from millions of simultaneously connected devices. Customers can now leverage the lightweight MQTT protocol to for telemetry ingestion, client command and control, and broadcast scenarios to build the next generation of applications faster through this fully managed service.

 

 

With this public preview release, customers can securely connect MQTT clients to Azure Event Grid, get fine-grained access control to permit pub-sub on hierarchical topics and route MQTT messages to other Azure services or 3rd party applications via Event Grid subscriptions. Key features supported in this release include MQTT over Websockets, persistent sessions, user properties, message expiry interval, topic aliases, and request-response. MQTT messages can be processed further with powerful analytics services in Azure, for example, Azure Stream Analytics or Azure Data Explorer to derive insights from large volume of data quickly. 

 

The new functionality makes Event Grid an ideal service for the implementation of automotive and mobility scenarios. Please see the reference architecture on how to build secure and scalable solutions for connecting millions of vehicles to the cloud, using Azure’s messaging and data analytics services.

 

Supporting “pull” delivery

In modern applications, event-driven architectures are foundational to drive automation. Customers want to react to events across a wide range of scenarios, including API management events, IoT device lifecycle, policy compliance notifications, storage blob events, or other custom events.

 

Event Grid has always offered push delivery of these events, through which events are pushed to the destination through an event subscription, and sent to Azure services like Azure Functions, Azure Logic Apps, Azure Automation, Service Bus, Event Hubs and others, or to 3rd party services via webhooks.

 

Our new support for “pull” capabilities meets customer demand for processing events from highly secure environments without configuring a public end point, control over the rate and volume of messages consumed, much larger throughput and more out-of-the-box functionality from a single service. Event Grid continues to conform with CloudEvents 1.0 specification.

 

 

 

New Event Grid Namespace Resource

The new features, MQTT support and pull-delivery, are available today through a new resource called Event Grid Namespace. Namespace makes it easy to manage resources and exposes an HTTP endpoint and an MQTT endpoint. In this release, pull delivery is supported for the resource Namespace topics. MQTT related resources on the Namespace include clients, certificates, client groups, and permission bindings.

 

Azure Event Grid now supports messaging at a much higher scale without compromising on performance. Today, each Namespace enables connecting to 200,000 MQTT clients, 20,000 MQTT messages per second ingress and egress, and 20MB per second or 20,000 events per second ingress, 40,000 events per second egress. In the next few months, our goal is to support 1 million MQTT clients, 100,000 MQTT messages per second, and 100MB per second or 100,000 events per second ingress, 200,000 events per second egress.

 

 

To learn more and try these new capabilities, get started through the Event Grid documentation.

 

Updated May 23, 2023
Version 2.0

27 Comments

  • Roman_Kiss's avatar
    Roman_Kiss
    Copper Contributor

    Hi jonmikeli ,

     

    This AEG MQTT Broker is a great feature, and I am expecting soon its integration with Azure IoT Hub and IoT Central Apps in the Pub/Sub manner, for instance. built-in a destination handler for that resources, etc.

  • WilfriedSibla's avatar
    WilfriedSibla
    Copper Contributor

    jonmikeli: that's the point imho.

    There's a tooling/framework domain in IoTHub I'd call Device Management

    And there's the basic messaging, mostly for telemetry data.

    After my opinion, this should be somehow decoupled. The Device Management could use a common, underlying messaging component, e.g. the MQTT-Broker.

    But I see this as two different stories. Even though they are quite close together and could be highly integrated

    But I also thought about using a different infra for the telemetry and other communication beside the Device Management functionality

  • jonmikeli's avatar
    jonmikeli
    Iron Contributor

    Hi jose_simoes ,

    I'm not sure they're "equivalent" right now. Azure IoT Hub has a lot of added features and value besides the MQTT messaging aspect. I would not like to recode the DPS, Device Update, Device Twin mecanisms, etc (without mentioning the other protocols besides MQTT).

    This said, it is true that we were missing a "standard" MQTT broker in Azure and here it is. But I get your point; the question is interesting, even intriguing. I would even ask how the whole Azure IoT ecosystem will evolve around this while preserving (and ideally improving) the already created value.

  • Roman_Kiss's avatar
    Roman_Kiss
    Copper Contributor

    Which region has a full support for Event Grid Namespace?

    I got the following warning: "This resource does not yet support events in this region."  (West Europe, West US 2, Central US) when I try to add an Event Subscription.

  • mcupito's avatar
    mcupito
    Copper Contributor

    This is great but creates slight confusion regarding IoT Hub. I suppose this can replace RabbitMQ in some scenarios? 

  • jose_simoes's avatar
    jose_simoes
    Copper Contributor

    Guess this will be the "future" for the existing Azure IoT Hub, correct?

  • WilfriedSibla's avatar
    WilfriedSibla
    Copper Contributor

    Just a short question: what about message ordering in such a scenario?

    Event Grid does not guarantee the order of messages (not sure, if not at all, or only in case of delayed delivery acknowledgement).

    MQTT normally keeps the order of messages. How would it be if messages are produced and consumed via MQTT?