Azure biedt een verscheidenheid aan messaging services aan om geavanceerde event-driven architecturen te maken. De rol van de Azure Event Grid is om de distributie van deze berichten op een betrouwbare manier naar alle individuele abonnees te coördineren. Dit maakt het een zeer geschikte dienst om te gebruiken in een publish-subscribe architectuurmodel. In dit blog kijken we naar kernfunctie, bruikbaarheid en mijn persoonlijke ervaring met het gebruik van Azure Event Grid.

Azure Messaging Services

De volgende drie messaging services diensten zijn beschikbaar in Azure om event-driven architecturen te maken:

• Azure Event Grid
• Azure Event Hub
• Azure Service Bus

Deze blog is een eerste in een serie om al deze services in meer detail te behandelen. Als eerste gaan we kijken naar Azure Event Grid.

Disclaimer

Aangezien het een technische blog is zullen sommige technische termen in het Engels zijn. Dit met name ook om de vertaling naar de Azure resources te behouden.

Azure Event Grid

Azure Event Grid is een lichtgewicht messaging service die bestaat uit een samenwerking van verschillende Azure resources. Applicaties kunnen via deze gecentraliseerde dienst berichten (event messages) met een bepaald onderwerp (topic) versturen naar een zogenaamde event topic. Andere applicaties, die geïnteresseerd zijn in dit topic, kunnen zich hier vervolgens op abonneren en ontvangen dit bericht zodra het door Event Grid verwerkt is.

De rol van het Event Grid is om de distributie van deze berichten op een betrouwbare manier naar alle individuele abonnees te coördineren. Dit maakt het een zeer geschikte dienst om te gebruiken in een publish-subscribe architectuurmodel.

Event Grid Resources

In de wereld van publish-subscribe kan je Event Grid zien als de dienst tussen de componenten publisher en subscriber. Het gebruik van Event Grid vereist echter een aantal componenten die samenwerken en de functionaliteit bieden. In de volgende afbeelding zie je een voorbeeld van deze componenten en hoe ze de gehele keten vormen.

Een resource dient als bron van het event en stuurt een bericht naar een event topic. Elk event topic kan een of meer event subscriptions hebben. Deze subscriptions zijn abstracte componenten die events doorsturen naar specifieke event handlers (of subscribers).

In de volgende paragrafen gaan we iets verder in op de verschillende componenten.

Event publisher

Een event publisher is meestal een bestaande Azure resource die Azure Event Grid standaard al ondersteund. Maar het is ook mogelijk om een applicatie events te laten genereren. Deze client applicatie dient dan wel de mogelijk te hebben om http(s) berichten naar het endpoint van de Event Grid te verzenden.

Microsoft biedt een groot aantal SDK’s voor verschillende programmeertalen om Event Grid berichten in een toepassing te implementeren.

Event Grid Development

Ik zal in de toekomst een post wijden aan het ontwikkelen van een applicatie met Azure Event Grid.

Event grid topics

Een topic kan worden beschouwd als een identificatie van de bron van een event en is de unieke, statische eigenschap van het bericht. Topics zijn strings en bevatten meestal de naam van de event bron of iets wat de bron omschrijft. Bij het configureren van een eigen topic kan dit in principe elke waarde hebben.

Goed om te weten

Het is belangrijk om te bedenken dat de waarde van een topic iets moet zijn dat de bron beschrijft, omdat het vaak wordt gebruikt bij het filteren van een event.

Azure kent momenteel twee typen topics:

• Event Grid Topics
• Event Grid System Topics

Event Grid Topics zijn door de gebruiker gedefinieerde topics en kunnen alle informatie bevatten, zolang deze voldoet aan de schema definitie.

Event Grid System Topics zijn onderwerpen die zijn gedefinieerd door Azure zelf en worden verzonden door specifieke Azure resources. Ze bevatten een door Azure vooraf gedefinieerd onderwerp en inhoud. In de Azure portal zijn dit dan ook afzonderlijke resource types.

Onderstaande afbeelding is een voorbeeld van een system topic verzonden vanuit een abonnement. Een voorbeeld event zou de creatie van een nieuwe bron kunnen zijn.

Voor informatie over beschikbare topics kun je op System topics in Azure Event Grid de pagina van Microsoft kijken.

Subscriptions

Achter de schermen zijn event grid subscriptions een soort routerings-componenten die een http(s)-verzoek naar een ander eindpunt sturen. Maar in werkelijkheid hebben ze meerdere functies en zijn het niet enkel componenten die gebeurtenissen doorsturen naar event handlers.

Abonnementen bieden veel meer functionaliteit die per subscription kan worden geconfigureerd. Omdat event-handlers hun eigen subscription beheren, geeft het fijnmazige controle over hoe en wanneer de berichten worden afgeleverd.

Hieronder staan ​​de meest voorkomende kenmerken van een abonnement.

• Filteren van binnenkomende events voordat ze verder verzonden worden:
  • Filteren op subject
  • Filteren op andere bericht eigenschappen zoals id, topic, subject of eventtype
  • Filteren op eigenschappen binnen het bericht
• Configureren van de identity die gebruikt wordt voor het afleveren van het bericht
• Configureren van Retry Policies
• Configureren van dead-lettering
• Configureren van subscription expiration time

Event handlers

Event handlers zijn de compenten die de berichten ontvangen en verwerken. Ze kunnen een van de bestaande Azure diensten zijn. Op dit moment worden de volgende Azure diensten aangeboden:

• Azure Function
• Storage Queue
• Event Hub
• Hybrid Connection
• Service Bus Queue
• Service Bus Topic

Naast de bovenstaande diensten kan een event ook naar een generieke event hook gestuurd worden. Hiermee kan in principe bijna elk scenario ondersteund worden.

Het distributiepatroon

One-to-many push pattern

Zoals eerder vermeld, gebruikt Azure Event Grid een push patroon waarin berichten van het Event Grid naar alle subscribers worden verzonden. Het maakt gebruik van een one-to-many distributiepatroon waarbij elk inkomend event dus wordt doorgezet naar alle subscribers die overeenkomen met het geconfigureerde filter.

Na ontvangst van het bericht stuurt de subscriber een bevestigingsbericht terug dat de event grid vertelt dat het bericht met succes is afgeleverd.

Event Message Flow

Dus hoe ziet zo’n berichtflow er dan uit? Onderstaande sequence diagram toont de berichten flow in details (Powered bij Mermaid).

Het eerste dat vereist is, is dat een event handler een subscription aanmaakt op een topic. Zonder subscription heeft de Event Grid niet veel te doen.

Vervolgens stuurt een publisher een event naar een topic. Voor elke subscription past Event Grid dan een filter toe. Als het filter overeenkomt met de configuratie van de subscription, wordt geprobeerd het bericht naar de event handler te verzenden. Dit doet de subsciption totdat het een bevestiging ontvangt van de event handler.

De inhoud van het event bericht

In vergelijking met de andere twee messaging services is de inhoud van het Event Grid bericht beperkt en bevat vaak de minimaal vereiste informatie over de gebeurtenis die heeft plaatsgevonden. De informatie dient voldoende te zijn voor de event handler om te bepalen wat er heeft plaatsgevonden en hoe te kunnen reageren. Het volgt ook een goed gedefinieerd schema dat standaardisatie bevordert.

Een voorbeeld

Azure Blob Storage kan een bericht verzenden wanneer een nieuw bestand is gemaakt. Het bericht bevat de informatie over het opslagaccount en het bestand dat is gemaakt. Het bevat niet de werkelijke gegevens van het bestand.
Voorbeeld

Andere belangrijke eigenschappen

Reliability en Failover

Dus wat betekent dit allemaal voor reliability en failover? Nou, event grid heeft hier wel een mechanisme voor. Het zal proberen het event bericht naar de event handler te verzenden en eventueel te herzenden. Dit gebeurt binnen de geconfigureerde vervaltijd van de subscription, die maximaal 24 uur is. Daarna wordt het bericht – afhankelijk van de configuratie – weggegooid of verplaatst naar de dead-letter.

Het is belangrijk om te weten dat Event Grid alleen levering binnen een bepaalde tijd garandeert. Daarnaast garandeert het geen succesvolle verwerking bij de ontvanger en biedt het ook geen mogelijkheden om een event opnieuw te versturen na een succesvolle levering (replay).

Dit betekent ook dat wanneer de event handler het bericht direct verwerkt (zoals een Azure function app of een Event Hook endpoint) en de verwerking van het bericht op de een of andere manier zou mislukken, het event bericht verdwenen is en niet meer kan worden opgehaald. Dit betekent dat requirements zoals reliability en failover deels ook moeten worden geïmplementeerd als onderdeel van de event handler oplossing.

Een mogelijke oplossing in dit geval is door een bestaande, persistente, service als event handler te laten optreden. Een veelvoorkomend patroon voor Event Grid subscriptions is het gebruik van een event handler die het bericht kan opslaan waarna een client applicatie later het bericht kan lezen van de persistente storage of dienst.

Onderstaande diagram toont twee opties waarbij een persistente service als handler is gebruikt om end-to-end “guaranteed delivery” te verzorgen.

Het voorbeeld toont een architectuur patroon waarbij een Queue Storage en Event Hub als event handler zijn geconfigureerd op een Event Grip topic. De event handler, in dit geval een function app, kan van beide services lezen.

Als de verwerking van het event zou mislukken dan kan dit op de volgende manier worden opgelost:

• Bij de Queue Storage wordt het bericht niet uit de queue verwijderd. Hierdoor wordt deze opgehaald bij een volgende uitvoering van de client.
• Voor de Event Hub zal de logica het checkpoint niet bijwerken of het bericht van de hub opnieuw afspelen.

Hoe beveilig je de Event Grid?

Er zijn verschillende manieren om de Event Grid en subscriptions te beveiligen. En dat zou zowaar in een hele eigen blog passen. Daarom hieronder de TL;DR samenvatting over dit onderwerp.

PUBLISEREN NAAR EVENT TOPICS

Om te voorkomen dat ongewenste publishers event berichten naar het Event Grid topic sturen, kun je een van de volgende maatregelen gebruiken:

• Event Grid beveiligen door gebruik te maken van Private Endpoint
• Event Grid beveiligen door gebruik te maken van IP firewall rules
• Event Grid beveiligen door gebruik te maken van Network Security Groups
• Toegang tot Event Grid reguleren via Access Control

SUBSCRIBEN OP EEN EVENT TOPIC

Het aanmaken van een subscription vereist de juiste toegangsrechten. Om een nieuwe subscription op het Event Grid Topic te kunnen aanmaken dien je de juiste rol te hebben. Je kunt “Build-in roles” gebruiken om gebruikers in staat te stellen een subscription op een topic aan te maken. Past een van de build-in rollen niet dan kan je ook een rol definiëren.

Voor meer informatie over beveiling verwijs ik je graag naar de Microsoft documentatie: Azure security baseline for Event Grid.

En… Hoe gebruiken we het nu?

Hopelijk heb je een algemeen beeld gekregen over wat Azure Event Grid is en hoe het werkt. Het laatste wat ik wil delen is wanneer ik persoonlijk Azure Event Grid zou gebruiken en waarom.

Jip en Janneke

“Jip en Janneke taal“, wie kent deze uitdrukking niet? Het betekent dat je iets in eenvoudige bewoordingen uitlegt die niet-technische mensen zouden moeten kunnen begrijpen. Dit is niet altijd gemakkelijk, maar in dit geval ga ik het toch proberen.

Als ik het Event Grid zou uitleggen, zou ik het vergelijken met meldingen op je telefoon. Stel dat je op een YouTube kanaal op de “hit the notification bell” klikt (subscription) en dat de maker dan een nieuwe video heeft geüpload (publisher). Je ontvangt dan een melding (event) op je telefoon (Event Handler) waarna jij het bericht bij de notificaties ziet. Daarnaast krijgen alle gebruikers die zich op dit kanaal abonneren deze melding (one-to-many).

Event Grid is in bovenstaande voorbeeld dan de notificatieservice van je telefoons OS (zoals Firebase Cloud Messaging voor Android).

Use Cases

Wat Event Grid anders maakt dan de andere messaging diensten, is dat je als ontvanger alleen de informatie krijgt over het wat en wanneer van het event. Dus in ons Jip en Janneke voorbeeld moet je nog steeds actief naar de Youtube video gaan om deze te bekijken en je kunt dit doen wanneer je maar wilt. Echter, als u de melding verwijdert, verliest u ook de informatie.

Het is soms best lastig om uit te leggen waarom je een van de drie messaging diensten in Azure zou moeten gebruiken. Soms kan een reden om één van deze diensten te gebruiken ook worden bereikt met een van de andere diensten. Hoe dan ook, ik zal proberen mijn gedachten in dit blog met jullie te delen.

Zoals bij elk ander architectuurontwerp zijn er requirements die deze beslissingen sturen. Voor mij is Event Grid handig in scenario’s waarin je andere services op de hoogte wilt stellen van een wijziging die heeft plaatsgevonden in een systeem – met behulp van een lichtgewicht, eenvoudig te implementeren messaging service, precies zoals bij notificaties op je telefoon. In feite een patroon waarbij de ontvanger volledige controle heeft over wat te doen met het bericht en wanneer. Hij kan het negeren of verwerken. Op basis van de informatie kan de ontvanger aanvullende acties uitvoeren.

Een ander voorbeeld. Bij één van onze klanten werken we aan een data platform waarbij data wordt ingelezen vanuit een bronsysteem via een Data Factory Pipeline. Dit dient als een soort caching-laag voor de verdere verwerking. Na inlezen wordt een event verzonden naar een specifiek topic met de informatie van de ingelezen data, tijdstip en waar het geplaatst is. Andere systemen, die geïnteresseerd zijn in de ingelezen data, zijn gesubscribed op dit topic en kunnen vervolgens de data raadplegen wanneer ze daar zelf tijd voor hebben. Op deze manier zijn de twee systemen van elkaar ontkoppeld en heeft de verzender geen weet van de ontvangers.

Als we naar de andere twee messaging diensten kijken draaien ze meer om het uitwisselen van datacentrische berichten met een rijkere payload. Deze diensten bevatten meestal bedrijfsgegevens die direct door de ontvanger moeten worden verwerkt en die mogelijk niet via de bron kunnen worden verkregen, behalve via het bericht.

Samenvatting

In dit blog heb ik geprobeerd uit te leggen hoe Azure Event Grid werkt en wat de mogelijkheden zijn. Hopelijk helpt dit iedereen die aan de slag wil gaan met Event Grid, of hun huidige, event-driven architectuur wil evalueren.

Mocht je het tot hier hebben volhouden, bedankt! 🙂 Ik hoop dat dit artikel nuttig was en tot ziens in het volgende deel in deze reeks. Hierin zal ik een soortgelijk artikel gaan schrijven over Azure Event Hub en Azure Service Bus. Deze diensten hebben veel gelijkenissen, maar zijn technisch toch anders. Azure Event Hub is een messaging dienst die veel meer geënt is op (near) real-time data streaming, en Azure Service Bus is een dienst waarmee je gemakkelijk een schaalbare oplossing kan maken.

Hopelijk tot de volgende blog!