by Carlos Carrero Saldarriaga, Staff Software Engineer at Growth Acceleration Partners
Introduction
This blog entry aims to provide a brief introduction to Azure Event Grid, which is one of the integration services Azure offers to build event driven architectures.
We will explore what “events” are in event driven architectures, and how we can use Event Grid to build those types of architectures.
Events
First, what are events in event driven architectures?
Events are:
- Immutable facts: things that have happened and cannot be changed
- Real life scenarios such as, for example, when a customer has placed an order
- Recurrent: happening every time, everywhere, anywhere
There are many types of events, including:
- Small
- Large
- Deltas
- Domains
Azure Event Grid
Azure Event Grid is a highly scalable, fully managed publisher/subscriber message distribution service that offers flexible message consumption patterns using the
MQTT (Message Queuing Telemetry Transport) and HTTP protocols.
With Event Grid, event-driven serverless architectures can be built with minimum effort.
It enables client applications to publish and subscribe to messages over the MQTT protocol.
Through HTTP, Event Grid enables building event-driven solutions where a publisher service announces its system state changes (events) to subscriber applications.
It can be configured to send events to subscribers (push delivery) or subscribers can connect to Event Grid to read events (pull delivery).
Event Grid Concepts
This section describes the main Event Grid concepts related to push delivery.
Event
It is the smallest amount of information that fully describes something that happened in a system, as explained before.
Cloud Events
Event Grid uses CNCF’s open standard CloudEvents 1.0 specification using the HTTP protocol binding with the JSON format. It is basically a Json representation of the event.
Event Source
An event source is where the event happens. Each event source is related to one or more event types.
For example:
- Azure Storage is the event source for blob created events or blob deleted events.
- A third-party application is the event source for custom events defined by the application.
Event sources are responsible for sending events to Event Grid.
Publishers
A publisher is the application that sends events to Event Grid. It may be the same application where the events originated, the event source.
Partners
A partner is a kind of publisher that sends events from its system to make them available to Azure customers.
A partner is typically a SaaS system that integrates with Azure Event Grid to help customers realize event-driven use cases across platforms.
Topics
A topic holds events that have been published to Event Grid. Typically, a topic resource is used to collect related events.
To respond to certain types of events, subscribers (an Azure service or other applications) decide which topics to subscribe to. There are custom, system, and partner topics.
Custom Topics
Custom topics are used with third-party applications.
They were the first kind of topic designed to build event-driven integrations for custom applications. As a self-standing resource, they expose their own endpoint to which events are published.
Partner Topics
Partner topics are used to subscribe to events published by a partner. The feature that enables this type of integration is called Partner Events.
Event Subscriptions
A subscription tells Event Grid which events on a topic are relevant or of interest to be received.
When creating a subscription, an endpoint needs to be provided for handling the event. Endpoints can be a webhook or an Azure service resource.
Events can be filtered by event type or subject.
Event Subscription Expiration
An expiration time can be set for event subscriptions associated with topics.
The event subscription automatically expires after that date.
Set an expiration for event subscriptions that are only needed for a limited time. For example, set an expiration when creating an event subscription to test a scenario.
Event Handlers
An event handler is the place where the event is sent when using push delivery.
The handler takes some further action to process the event.
When using push delivery, Event Grid supports several handler types. A supported Azure service or a custom webhook can be used as the handler.
Depending on the type of handler, Event Grid follows different mechanisms to guarantee the delivery of the event.
For HTTP webhook event handlers, the event is retried until the handler returns a status code of 200 — OK.
For Azure Storage Queue, the events are retried until the Queue service successfully processes the message pushed into the queue.
Pull Delivery vs. Push Delivery
It is important to understand these two methods of sending events. Using HTTP, Event Grid supports push and pull event delivery.
With push delivery, a destination needs to be defined in an event subscription (for example, an Azure service), to which Event Grid sends events.
With pull delivery, subscriber applications connect to Event Grid to consume events. Pull delivery is supported in topics within a namespace.
The big difference here is that with pull delivery, the subscriber application handles the events at their own rate, whereas the push mechanism does not take into account how fast or slow the subscriber application can handle events.
The pull delivery is still in preview at the time of writing, so keep that in mind.
Use Case Example
Let’s say we are building an application that processes images, and we want to be notified when an image has been uploaded to the application.
First, we are going to create a storage account to upload the images:
Go to the Azure portal and create a resource group or select one already created and give your storage account a name. It needs to be globally unique.
Leave other default settings and wait for the storage account to be created.
Now, let’s create a container to upload the photos. Go to the storage account and in the containers section, add a container named “photos.”
We are going to need a third-party application to test the event grid integration.
Azure event grid viewer will act as our event handler. It will show information about the events triggered by our storage account.
In order to deploy the Event Grid viewer in Azure, just deploy this custom template and make sure to change the following:
- The resource group where you want the event grid viewer app to be deployed
- Site name, which can be anything you want, but it must be globally unique
- The name of the hosting plan for the Event Grid viewer
- Repo URL: the application code url
https://github.com/Azure-Samples/azure-event-grid-viewer.git
If you navigate to the application url, it should look something like this.
We are going to create an event subscription for the storage account in order to be notified when an image has been uploaded.
One way to do this is in the Events section, inside the storage account.
There are several configuration options we can set for the event subscription.
In the basics tab, we can set the following:
- Event subscription name: A name to identify the event subscription.
- System topic’s name: The name of the system topic where the events emitted by the storage account will be stored.
- The event types we want to filter, which in this case, we are only interested in the blob created event type.
- The endpoint details, as the event grid viewer app needs to register an event subscription endpoint in order to handle events.
We should register the endpoint with the following format:
https://{{site-name}}.azurewebsites.net/api/updates
Change {{site-name}} with the name of your site.
In the Filters tab, we can add custom filters. Let’s say we want to filter just images with the jpg extension.
Once the subscription is created, we can see its details inside the events section in the storage account.
Once we upload a photo to the Azure storage account container,
We can see the Event Grid viewer app handling the event.
The application shows information about the event, including: type, subject, topic and other important information.
Demo Takeaways
- Azure Event Grid allowed us to successfully build an event driven application feature with minimum effort.
- No infrastructure deployment was needed to develop the feature. It is all serverless.
- No administration costs are associated when working with Azure Event Grid.
- Azure Event Grid works with Azure services out of the box. For example, the Azure storage account seamless integration we used in the demo.
- Azure Event Grid integrates with third party apps using event handlers endpoints. In our case, it was the webhook endpoint we configured when setting up the event subscription.
