Deliver the right events to the right places with Event Domains
As we continue to see our community grow around Event Grid, many of you have started to explore the boundaries of complexity and scale that can be achieved. We’ve been blown away with some of the system architectures we have seen built on top of the platform.
In order to make your life easier with some of these scenarios, we decided to dedicate much of the last few months to building two features we are very excited to announce today: advanced filters, and Event Domains – a managed platform for publishing events to all of your customers. In addition, we’ve been working to improve the developer experience and make Event Grid available in Azure Government regions.
Event Domains
Become your own event source for Event Grid with Event Domains, managing the flow of custom events to your different business organizations, customers, or applications. An Event Domain is essentially a management tool for large numbers of Event Grid Topics related to the same application, a top-level artifact that can contain thousands of topics. With a Domain, you get fine grain authorization and authentication control over each topic via Azure Active Directory, which lets you easily decide which of your tenants or customers has access to subscribe to which topics. The Event Domain also handles partitioning for you which means instead of needing to publish your events to each topic individually, you can publish all of your events to the Domain’s endpoint and Event Grid takes care of ensuring each event is sent to the correct topic.
This is a unique feature to Event Grid that enables new scenarios for you and your partners to offer your own events to your end customers.
With Event Domains, we are taking the underlying architecture that Azure services, such as Blob Storage or IoT Hub, to publish events and make them available for you to use. What this means is that you can now use a single Event Domain to handle publishing events to all your end customers, or across a complex organization with independent services.
Event Domains are perhaps most easily explained using an example. Let’s say you run Contoso Construction Machinery, where you manufacture tractors, digging equipment, and other heavy machinery. As a part of running the business, you push real-time information to customers regarding equipment maintenance, systems health, and contract updates. All of this goes to various endpoints including your app, customer endpoints, and other infrastructure customers had setup.
Event Domains allows you to model Contoso Construction Machinery as a single eventing entity. Each of your customers is represented as a Topic within the Domain, handling authentication and authorization using Azure Active Directory, so you don’t have to worry about it. Each of your customers can subscribe to their Topic and get the events delivered to them, but AAD and the Event Domain block them from accessing another tenant’s Topic.
It also gives you a single endpoint which you can publish all of your customer events to, and Event Grid will take care of making sure each Topic is only aware of events scoped to its tenant.
In a world where application architectures are increasingly shifting towards event-based programming models, support for push to HTTP endpoints, applications, and cloud services is becoming more and more important. Event Domains handles the eventing for you, so you only have to worry about what events are you making available to your customers.
Use Event Domains to:
- Manage multitenant eventing architectures at scale.
- Manage your authorization and authentication.
- Partition your topics without managing each individually.
- Avoid individually publishing to each of your topic endpoints.
Learn more about Event Domains in our docs, and get started with this sample.
Advanced filters on Event Grid
To compliment the added capabilities of Event Domains, we are also excited to announce that Event Grid supports several new types of advanced filters starting today! These new filters will allow a host of new types of filtering to occur on the wire including numerical, string, and Boolean filters.
With this update, we are providing a number of operators on each datatype and greatly increasing the number of fields you’ll be able to run them on, increasing control over what events are routed where, and making sure only the required ones are getting to the compute services handling them. Advanced filters supports filtering on envelope properties (such as DataVersion, Id, and Topic) as well as the data payload up to two layers deep (e.g. data.key1 or data.key1.key2). The following operators are being added per data type:
Numbers
NumberLessThanNumberLessThanOrEqualsNumberGreaterThanNumberGreaterThanOrEqualsNumberIn – the value for data.key equals a value in the set [0, 2.08, 3.14]NumberNotIn – the value for data.key is not in the set [1, 11, 112, 1124]
Strings
StringContains – the value for data.key contains “the”StringIn – the value for data.key equals a value in the set [“small”, “brown”, “fox”]StringNotIn – the value for data.key equals a value in the set [“jumped”, “over”, “the”]StringBeginsWith – the value for data.key begins with “lazy”StringEndsWith – the value for data.key ends with “dog”
Boolean
BoolEquals
No more adding additional clunk scripts to further filter your events before running your business logic. By combining the various new filters, powerful combinations of on-the-wire filters become possible, allowing your event handlers to deal only with the data they truly care about.
Learn more about the advanced filtering capabilities of Event Grid in our docs.
Azure Government regions availability
As of November 1, 2018, Event Grid is available in US Gov Arizona, Texas, and Virginia regions. All Event Grid features (including Custom Topics, Domains, filtering, and Dead Lettering) will be available from the beginning. However, the built-in events coming from first party Azure services, such as Azure Storage, will not immediately be available. These built in event sources are already in the works for these regions, and will be added on a rolling basis over the course of the next few months, so stay tuned. This means that Event Grid will initially be public preview in the US Gov regions until we finish adding the rest of capabilities on the service. If you have questions or requirements regarding specific event publishers, don’t hesitate to contact the team.
Development experience improvements
Finally, we are constantly working to make little tweaks and updates that make testing and development easier for you. In that spirit, we have updated some of our SDKs, added a time to live feature for Event Subscriptions, and added Portal UI support for configuring dead-lettering and retry policies.
Dead lettering and retry policies in the Azure portal
You can now click on the “Additional Features” tab at the top of the page anytime you are creating an Event Subscription. From this page you’ll be able to access retry policy & dead-letter configuration, filters, and any new functionality we add. There is also now an Advanced Editor mode where you can see the ARM representation of your subscription for use in an ARM Template, as well as configure any new features not yet available in the portal.
Event Subscription Time to Live (TTL)
Ephemeral resources can be useful for a number of reasons. They enforce hygiene when testing by cleaning up old resources, they drive security by not allowing a resource to publish ad infinitum, and they keep configurations fresh by ensuring only resources proactively subscribing to events are still receiving them. With Event Subscription TTL, you can now configure a live time, at creation, for an Event Subscription after which it automatically gets cleaned up.
SDKs updates
We have updated the .Net, Java, and Go SDKs to make consuming Azure Native Events even easier. Using the latest release of each, the SDK is now aware of all available event types being published by Azure. This means you can use Event Grid’s eventGridSubscriber to deserialize events directly for all known event types and start writing code against the content of the event rather than first having to deal with manually deserializing JSON into various different event type classes. Check the different SDKs for an easier experience managing your Event Grid resources and events.
Source: Azure Blog Feed