Microsoft released the technical preview of Azure Event Grid last Wednesday, and it has become one of the most hotly talked about subjects in the Integration space. With most of the Dev-World’s focus shifting towards reactive programming and building large scale, event-driven applications, the attention, I must say, is justified.
What is Azure Event Grid
So, what is an Event Grid? The simplest explanation is – it’s an event routing service. An event is something that happens at a given place and time. It can be the simple click of a mouse button, a new email in the inbox, a new virtual machine or database deployed in Azure, a drop in the heart rate of a person while exercising, or even a change in the room temperature at your home. A major chunk of the applications developed today is created to react to events like these. The events contain data about the happenings which are generated by web/mobile apps, sensors, embedded systems and other IoT devices. With a high volume of streaming data, it becomes extremely difficult and complex for businesses to process these data and trigger responses to the events. That’s where Azure Event Grid steps in. It’s a service that acts as a connector to tightly integrate all the applications/services together and routes the event messages from any source to any destination. Don’t fault it for its simple routing mechanism though. It’s highly capable in managing and handling events. Since it is built on the publish/subscribe model, you can subscribe to specific events on a topic, if need be, through the smart filtering capabilities that Event Grid offers. Events can be published to multiple services within Azure or even third-party services outside of Azure.
Microsoft has positioned Azure Event Grid as a serverless computing service that integrates all the event publishing and event handling services within Azure. While Event Grid can push and react to events from third-party services, it’s built to deeply integrate with Azure services. The integration is so intense that it takes only a couple of clicks to aim events from your Azure resource to any event handler or endpoint. Microsoft has made Event Grid to work with custom third-party services and applications as well. If you have your own application pumping out events, then Custom Topics service can be used to publish those events. Also, if you want your own application or service to react to those events, then you can use WebHook to subscribe to those events. Despite the close integration with Azure services, Event Grid is a true public cloud offering.
Why not using Azure Service Bus
Now, many of you might be wondering, “why not use Azure Service Bus to route these messages from one place to another”? While it is possible theoretically, Azure Service Bus is built as a platform for applications requiring enterprise messaging capabilities like transactions, duplicate detection and dead-lettering. Even if you used Service Bus for routing the messages, your application must poll continuously to see if the messages have arrived and then react. What Event Grid does, is eliminate the need to poll and see if an event has occurred. Instead, when an event occurs, the Event Grid invokes an Event Handler like Azure Function or Logic App to react to the event automatically. Event Grid and Service Bus are different offerings from Microsoft for different purposes and they do not replace each other. If you are a Service Bus user, what you can do instead is use Event Grid to trigger an Event Handler to clean up queues when they are full, resubmit dead-lettered messages to the same queue or different queue, notify you when the number of messages in a queue has gone beyond a certain number, etc. But why bother when you have Serverless360?
