Cos'è la Event-driven Architecture?

L'Event-driven Architecture (EDA) è un modello di progettazione del software che permette a un'azienda di rilevare "eventi" o situazioni di business importanti (come una transazione, una visita al sito, l'abbandono del carrello, etc) e agire su di essi in tempo reale o quasi. Questo modello sostituisce la tradizionale architettura "richiesta/risposta" in cui i servizi dovrebbero aspettare una risposta prima di poter passare al compito successivo. Il flusso dell'Event-driven Architecture è gestito da eventi ed è concepito per rispondere ad essi o eseguire qualche azione in risposta ad un evento.

L'Event-driven Architecture è spesso chiamata comunicazione "asincrona". Questo significa che il mittente e il destinatario non devono attendere l'altro per passare al loro compito successivo. I sistemi non dipendono da quell'unico messaggio. Per esempio, una telefonata è considerata sincrona o più sulla linea della tradizionale architettura "richiesta/risposta". Qualcuno ti chiama e ti chiede di fare qualcosa, il richiedente aspetta mentre il rispondente completa il compito, e poi entrambe le parti riattaccano. Un esempio asincrono sarebbe la messaggistica di testo. Si invia un messaggio e, in alcuni casi, non si sa nemmeno a chi lo si sta inviando o se qualcuno sta ascoltando, ma non si è in attesa di una risposta.

L'evoluzione dell'Event-driven Architecture

Negli ultimi anni, si è registrato un movimento che ha portato a concentrarsi sui dati a riposo (architettura orientata ai servizi) e sugli eventi (event-driven architecture). Stiamo passando dall'accumulo di dati e dai data lake a concentrarci sui dati in movimento e a tenerne traccia mentre si spostano da un posto all'altro. Tradizionalmente, la maggior parte dei sistemi funziona in quello che si può pensare come il modello incentrato sui dati, in cui questi ultimi sono la fonte della verità. Il passaggio all'event-driven architecture comporta lo spostarsi da un modello incentrato sui dati a un modello incentrato sugli eventi. Nel modello orientato agli eventi, i dati sono ancora importanti, ma gli eventi divengono la componente più importante. Invece nel modello orientato ai servizi, la priorità più alta era quella di assicurarsi di non perdere nessun dato. Con l'event-driven architecture, la priorità è quella di garantire che si risponda agli eventi mentre accadono. Poiché c'è una legge di rendimenti decrescenti per quanto riguarda gli eventi, più diventano datati, meno sono preziosi. Tuttavia, oggi, l'architettura orientata ai servizi e l'event-driven architecture sono spesso utilizzate congiuntamente.

L'event-driven architecture spesso usa un'analogia di registro per tenere traccia delle cose. Gli analisti parlano di eventi come cose immutabili che sono accadute. E se si vuole capire cosa è successo in passato, è possibile tornare indietro e riprodurre il registro. Invece, nel modello incentrato sui dati, ci si concentra principalmente sullo stato dei dati come è ora. E poi l'ultima analogia che gli analisti utilizzano quando descrivono la differenza tra le architetture centrate sui dati e quelle incentrate sugli eventi è che spesso le paragonano a un deposito di informazioni e a un sistema nervoso che porta i messaggi all'interno dell'azienda.

Quando si usa un'event-driven Architecture, i generatori di eventi creano e inviano notifiche di eventi e si possono avere uno o più consumatori di un evento, in cui la ricezione dello stesso innesca la logica di elaborazione. Per esempio, diciamo che Netflix ha appena caricato un nuovo film. Ci potrebbero essere diverse applicazioni in ascolto o in attesa di quella notifica che poi innescano i loro sistemi interni per pubblicare le proprie informazioni su quell'evento ai loro utenti. Questo differisce dalla tradizionale messaggistica di richiesta-risposta in quanto le applicazioni sono ancora in esecuzione e anche se possono essere in ascolto per questo evento, esse non sono paralizzate nell'attesa. E sono in grado di rispondere quando il messaggio viene pubblicato. Così, molti servizi possono essere eseguiti in parallelo.

Cos'è un evento?

Un evento è definito come un cambiamento di stato di sistemi aziendali chiave. Per esempio, qualcuno acquista un prodotto, qualcun altro fa il check-in per un volo o un autobus arriva in ritardo da qualche parte. E se ci si pensa, gli eventi esistono ovunque e si verificano costantemente, a prescindere dal settore. Essi sono onnipresenti in qualsiasi azienda. Tutto ciò che crea un messaggio venendo prodotto, pubblicato, rilevato o consumato è considerato un evento. L'evento è separato dal messaggio, perché mentre l'evento costituisce l'avvenimento, il messaggio rappresenta la notifica di viaggio che trasmette l'avvenimento. Nell'event-driven architecture, un evento probabilmente innescherà una o più azioni o processi in risposta alla sua occorrenza. Un esempio di un evento potrebbe includere:

• Richiesta di reimpostare una password
• Un pacco è stato consegnato a destinazione
• Un magazzino di alimentari aggiorna il suo inventario
• Un tentativo di accesso non autorizzato è stato negato

Ognuno di questi eventi può innescare una o più azioni o processi in risposta. Una risposta potrebbe essere semplicemente quella di registrare l'evento per scopi di monitoraggio. Altri potrebbero essere:

• Un'e-mail per resettare la password viene inviata al cliente
• La biglietteria è chiusa
• Viene effettuato un ordine per una maggiore quantità di lattuga (o qualsiasi altro materiale che si sta esaurendo)
• Un account viene bloccato e il personale di sicurezza viene avvisato

Con l'event-driven architecture, quando viene inviata una notifica di evento, il sistema rileva che è successo qualcosa come un cambiamento di stato e aspetta di inviare la risposta a chi la richiede, ogni volta che lo richiede. L'applicazione che ha ricevuto quel messaggio può rispondere o aspettare di rispondere fino a quando non si è verificato il cambiamento di stato che sta aspettando.

Le applicazioni costruite intorno a un'event-driven architecture consentono applicazioni di business digitali più agili, scalabili, contestuali e reattive.

Come funziona l'event-driven architecture?

I componenti di un'event-driven architecture possono includere tre parti: produttore, consumatore, broker. Il broker può essere opzionale, in particolare quando si ha un singolo produttore e un singolo consumatore che sono in comunicazione diretta tra essi e il produttore invia solo gli eventi al consumatore. Un esempio potrebbe essere un produttore che effettua l'invio solo a un database o a un data warehouse in modo che gli eventi siano raccolti e memorizzati per l'analisi. Più comunemente nelle imprese, si hanno più fonti che inviano tutti i tipi di eventi con uno o più consumatori interessati ad alcuni o tutti questi eventi.

Vediamo un esempio. Se sei un rivenditore, potresti raccogliere tutti gli acquisti che avvengono in tutti i tuoi negozi in tutto il mondo. Li stai inserendo nella tua event-driven architecture che sta controllando le frodi, inviandoli a un elaboratore di carte di credito o qualsiasi altra azione debba accadere dopo. Per un produttore, si dispone di tutti i tipi di dati provenienti dalle attrezzature che indicano fattori come la temperatura e la pressione in modo da poter monitorare questi eventi in tempo reale e intraprendere azioni come prevedere i guasti o programmare la manutenzione, a seconda di ciò che i dati dicono.