Azure Event Grid: a message to rule them all

Azure Event Grid non è l’unico servizio disponibile su Azure che ha a che fare con la messaggistica. Ma prima di capire come usare Azure Event Grid, è meglio approfondire quando Event Grid fa al caso nostro.

Nel mondo dei messaggi, possiamo identificare due macro-categorie che ne definiscono l’ambito: i comandi e gli eventi.

I comandi, come da definizione sono assertivi: qualcuno chiede a qualcun altro di fare qualcosa. La comunicazione è “point-to-point”, tra due attori del sistema e, solitamente, il produttore del comando è interessato al risultato dell’operazione richiesta.

Gli eventi, invece, vengono utilizzati per notificare che qualcosa è avvenuto nel sistema, che il sistema ha subito un cambio di stato. La comunicazione non è più tra due attori specifici, ma tra un componente e N eventuali altri componenti interessati a quel tipo di informazione. È una comunicazion di tipo broadcast, in cui il numero di componenti N puo’ essere uno, nessuno o centomila.

Eventi: le caratteristiche

Focalizzando l’attenzione sulla categoria degli eventi, possiamo affinare la distinzione individuando due peculiarità che possono caratterizzare e distinguere gli eventi:

• eventi “atomici”, ovvero eventi che hanno la loro ragione di essere completamente scorrelata dalla produzione di altri eventi dello stesso tipo. Per esempio “un ordine è stato registrato” in un sistema di e-commerce potrebbe essere un evento di questo tipo;
• eventi correlati (nel tempo), ovvero eventi il cui contenuto informativo non è rappresentato solo dall’i-esimo evento in particolare, ma dallo stream di tutti gli eventi. Basti pensare ad un sensore di temperatura: è molto più importante sapere se la “tendenza” della temperatura e’ in discesa, per attivare la caldaia, piuttosto che sapere che, in un particolare istante temporale, la temperatura rilevata era di 20.3 gradi.

Azure: i servizi e i componenti principali

In queste tre macro categorie si configurano i tre servizi principali che Azure mette a disposizione per la gestione dei messaggi:

• Azure Event Hubs per la gestione degli stream di eventi
• Azure Event Grid per la gestione degli eventi di qualsiasi forma e origine
• Azure Service Bus per la gestione di scenari di business “critici” in cui si rivelano indispensabili le feature di un enterprise message broker completo

Ora che abbiamo capito in che scenario ha senso pensare ad Event Grid, cerchiamo di approfondire che cos’è.

Prima del suo avvento, tutti i servizi di Azure erano una serie di “puntini”, che potevano cooperare tra di loro, ma con modalità completamente differenti.
Event Grid è la lingua franca con cui mettere in comunicazione tutti questi servizi. La linea che permette di unire tutti i puntini.

I componenti principali che caratterizzano Event Grid sono:

• un evento, ovvero l’informazione che si vuol far “viaggiare” nel sistema
• una sorgente, ovvero il componente che genera l’evento
• un topic, ovvero l’endpoint a cui viene “inviato” l’evento
• un handler, ovvero un componente interessato ad un particolare evento
• una subscription, ovvero il collegamento tra un topic ed un componente interessato all’evento generato

Ok, Ok, ma come si usa?

La prima cosa da fare per poter sfruttare Azure Event Grid è abilitare il relativo provider sulla piattaforma.

Utilizzando per esempio la CLI, tramite il semplice comando az provider register --namespace Microsoft.EventGrid è possibile attivare il servizio all’interno della propria subscription.

Un semplice use-case, potrebbe essere quello per cui, ogni volta che viene caricato un nuovo blob su uno Storage Account deve essere invocata una nostra API che si occuperà di gestire la notifica.

Per poter abilitare questa integrazione è necessario creare una subscription tra un topic (di sistema), quello appunto in cui la piattaforma veicola gli eventi relativi allo Storage Account, e la nostra API. Per poterlo fare basta eseguire il seguente comando:

az eventgrid event-subscription create \
  --source-resource-id $STORAGE_ACCOUNT_ID \
  --name $SUBSCRIPTION_NAME \
  --endpoint $ENDPOINT_URI

Dove:

• $STORAGE_ACCOUNT_ID è appunto l’ID dello storage account che genera l’evento;
• $SUBSCRIPTION_NAME è il nome della subscription che stiamo creando;
• $ENDPOINT_URI è l’endpoint verso cui verranno veicolati gli eventi;

Nell’ecosistema di Azure, una source può essere uno dei servizi esposti dalla piattaforma, come per esempio Azure Container Registry o Azure App Configuration. Un handler può essere per esempio una Azure Function o un WebHook.

Gli eventi che vengono prodotti, da qualunque servizio, hanno una struttura ben precisa, a cui tutte le sorgenti si devono adeguare:

{
    "topic": string,
    "subject": string,
    "id": string,
    "eventType": string,
    "eventTime": string,
    "data":{
      object-unique-to-each-publisher
    },
    "dataVersion": string,
    "metadataVersion": string
}

dove il solo attributo data è tipico del contesto in cui l’evento viene generato. In fin dei conti, il contenuto informativo di un messaggio generato, per esempio, quando una nuova immagine viene caricata su Azure Container Registry, è sensibilmente differente da quello prodotto da un cambio di configurazione su Azure App Configuration.

Visto che spesso un’immagine vale più di mille parole, ecco tutti i servizi che è possibile “collegare” sfruttando Event Grid:

WebHook e applicazioni esterne

Il fatto che uno dei possibili handler supportati da Event Grid sia il meccanismo dei webhook apre alla possibilità di integrazione non solo da/verso servizi di Azure, ma anche da servizi della piattaforma a sistemi terzi, come per esempio una nostra applicazione.

Ma non solo… Azure Event Grid supporta la “produzione” di eventi custom, quindi non generati da servizi della piattaforma, ma da servizi/applicazioni esterne alla piattaforma stessa (anche in questo caso, una nostra applicazione).

A differenza di quanto avviene con i servizi di Azure che utilizzano topic “pre-configurati”, chiamati appunto topic di sistema, per potrer integrare sorgenti esterne alla piattaforma sarà necessario creare un topic custom.
Il tutto è a distanza di un comando sulla CLI:

az eventgrid topic create \
  --name $TOPIC_NAME 
  -l $REGION 
  -g $RESOURCE_GROUP

Il topic appena creato è esposto tramite un uri, che e’ “recuperabile” tramite il seguente comando:

endpoint=$(az eventgrid topic show --name $topicname -g gridResourceGroup --query "endpoint" --output tsv)

A questo punto, l’integrazione è presto fatta: basta un qualsiasi linguaggio e/o tool che supporti la possibilità di eseguire una POST HTTP verso questo endpoint, a cui possiamo inviare i nostri eventi, che verranno veicolati, attraverso le subscription registrate, verso i vari handler.

Con Azure Event Grid termina l’era del dispendioso “polling” per valutare eventuali cambi di stato del nostro sistema.
Ora, qualsiasi scenario message driven è, veramente, a distanza di un messaggio.