Azure Event Grid — Digested

Like any beast in Azure, learning about Event Grid quickly turns into a game of buzzword bingo. Lots of new words that actually represent something rather simple that, especially if you know something about messaging, you might even already understand.

After going through the headache of digesting these new terms and concepts I always like to reflect on what the overall concept actually is in simpler terms.

What is Event Grid?

Event Grid is a message router, and not much more. It knows how to consume events and distribute them to interested parties.

It’s actually like newsletter distribution. Imagine you want your newsletters published. You give over a copy of each to the distributor, they know who the subscribers are and how to send copies to each one. It doesn’t matter if a subscriber lives locally or overseas, that is the distributor’s concern.

In Event Grid this distributor is called a topic. The topic knows who to send events to via subscriptions. The subscriptions define who’s interested in receiving events and where they are.

From a publisher’s perspective, they simply send the events to the topic, without caring who the subscribers are.

Why use it?

Microsoft has great documentation helping you choose between messaging services that Azure provides.

Personally, I think the biggest benefit of Event Grid is its simplicity and cross-platform support.

Keeping it simple

A lot of messaging services provide heaps of functionality you may not need. Heck, look at just some of the Advanced Features that Service Bus offers:

Message sessions, Autoforwarding, Dead-letter queue, Scheduled delivery, Message deferral, Batching, Transactions, Filtering and action, Autodelete on idle, Duplicate detection, Geo-disaster recovery

Bored yet? That took me long enough to write, let alone understand.

The point is that Event Grid makes no promise to be a Swiss-Army knife - it is a butter knife. You cannot do much with a butter knife. So what? It wasn’t designed to do anything else, but it does a great job of spreading butter.

Other than being simple, Event Grid is also reliable and scales well.

Event publishers

As you might expect, Events can come from a number of Azure services. You can also post a custom event that from any application, since you just need to post to a HTTP endpoint exposed by the topic.

A notable requirement here is that Event Grid supports two well-defined schemas your event should adhere to: Cloud Event or Event Grid Event Schema. I like the encouragement to use common way of describing events - they are not tied to a particular technology and provide common ground between services.

Event handlers

For handling events, Azure provides great integration with other Azure services like Functions, Service Bus etc. BUT you can also use any WebHook for handling events. The WebHook doesn’t need to be hosted in Azure.

Event Grid only supports HTTPS Webhook endpoints.

This is a big advantage of Event Grid over something like Service Bus. A Service Bus is a pull model where the subscriber needs to know how to poll a message queue. Event Grid is a push model — i.e. events can be pushed to a WebHook. This is great as WebHooks are a web standard, and does not make any assumptions of the event handler.

Why not use it?

You need more features

It would be pretty annoying if you bought a butter knife home from the shops but when using it later realised you needed to chop an onion with it.

Event Grid doesn’t support many advanced functions like duplicate detection or replay of failed messages. If your messages cannot be lost and have high value, you will likely want some of these functions. Many might be provided by other, more feature-rich, services.

Pull over push

The push model that Event Grid offers means that subscribers have no control over when and how they receive messages. Perhaps many of your subscribers want to utilise the Queue-Based Load Leveling pattern. If, for example, you only want to process messages once a week, you are out of luck. Event Grid decides when to send these events.

The pull model that something like a message bus provides can solve this problem, leaving this the responsibility of the subscriber. Note though, that you can route Azure Event Grid Events to a Service Bus Queue to also get around this problem.

Long running tasks

When a subscriber handles an event, failure to respond quickly might result in Event Grid attempting to re-deliver or even send the event to a dead-letter channel. Your subscribers need to be aware that this response needs to be timely.

What next?

This was more of an overview of Event Grid and my take on it. I’ll soon post about more specific and low-level features. Stay tuned!

Buzzword bingo score

2 — Event Grid topic and Event Grid subscription

Built with GatsbyJS, styled using Terminal CSS