We have been incredibly excited to be a part of the rise of event-driven programming as a core building block for cloud application architecture. By making the following features generally available, we want to enable you to build more sophisticated, performant, and stable event-driven applications in Azure. We are proud to announce the general availability of the following set of features, previously in preview:
- Dead lettering
- Retry policies
- Storage Queues as a destination
- Hybrid Connections as a destination
- Manual Validation Handshake
To take advantage of the GA status of the features, make sure you are using our 2019-01-01 API and SDKs. If you are using the Azure portal or CloudShell, you’re already good to go. If you are using CLI or PowerShell, make sure you have versions 2.0.56 or later for CLI and 1.1.0 for PowerShell.
Dead lettering
Dead lettering gives you an at-least-once guarantee that you will receive your events in mission critical systems. With a dead letter destination set, you will never lose a message even if your event handler is down, your authorization fails, or a bug in your endpoint is overwhelmed with volume.
Dead lettering allows you to connect each event subscription to a storage account, so that if your primary event pipeline fails, Azure Event Grid can deliver those events to a storage account for consumption at any time.
Retry policies
Retry policies make your primary eventing pipeline more robust in the event of ephemeral failures. While dead lettering provides you with a backstop in case there are long lasting failures in your system, it is more common to see only temporary outages in distributed systems.
Configuring retry policies allows you to set how many times, or for how long you would like an event to be retried before it is dead lettered or dropped. Sometimes, you may want to keep retrying an event as long as possible regardless of how late it is. Other times, once an event is stale, it has no value, so you want it dropped immediately. Retry policies let you choose the delivery schedule that works best for you.
Storage Queues as a destination
Event Grid can directly push your events to an Azure Storage Queue. Queues can be a powerful event handler when you need to buffer your ingress of events to your event handler to allow it to properly scale up. Similarly, if your event handler can’t guarantee uptime, putting a storage queue in between allows you to hold those events and process them when your event handler is ready.
Storage queues also have virtual network (VNet) integration which allows for VNet injection of Event Grid events. If you need to connect an event source to an event handler that is within a VNet, you can tell Event Grid to publish to a storage queue and then consume events in your VNet via your queue.
Hybrid connections as a destination
If you want to build and debug locally while connected to cloud resources for an event, have an on-premises service that can’t expose an HTTP endpoint, or need to work from behind a locked down firewall, Hybrid connections allows you to connect those resources to Event Grid.
Hybrid connections as an event handler gives you an HTTP endpoint to connect Event Grid to. It also gives you option to make an outbound WebSocket connection from your local resource to the same hybrid connection instance. The hybrid connection will then relay your incoming events from event grid to your on-premises resource.
Manual validation handshake
Not all event handlers can customize their HTTP response in order to provide endpoint proof of ownership. The manual validation handshake makes it as easy as copy paste to prove you are an authorized owner of an endpoint.
When you register an Event Grid subscription, a validation event will be sent to the endpoint with a validation code. You are still able to respond to the validation event by echoing back the validation code, however, if that is not convenient, you can now copy and paste the validation URL included from the event to any browser to validate the endpoint. Doing a GET on the endpoint validates proof of ownership.
We hope you react well to this news.
The Azure Event Grid team