Un’architettura guidata dagli eventi è conveniente per sviluppare sistemi che operano in tempo reale. Si tratta di un approccio che porta vantaggi certamente a chi già opera in tempo reale, ma che spesso risulta determinante anche in settori non ancora abituati a elaborazioni o decisioni in real time.
Le moderne architetture applicative cloud native vengono sviluppate attraverso i metodi agile e DevOps. I sottosistemi sono spesso loosely-coupled, associati in maniera non diretta, in modo da permetterne lo sviluppo in maniera separata dagli altri sottosistemi.
Ma partiamo dall’inizio.
Event-driven architecture: cos’è?
Con il termine evento si intende un qualsiasi cambiamento di stato o di identificazione nel flusso dei dati di un sistema software. Il tipico esempio è l’inserimento di un articolo nel carrello virtuale di un sito e-commerce, oppure la notifica dell’avvenuta spedizione.
Immagine da https://aws.amazon.com/it/event-driven-architecture/
Immagine derivata da Tiempo
Architetture a confronto: microservizi (a destra) contro monolitica e service oriented.
Una event-driven architecture usa gli eventi per attivazione e comunicazione tra servizi disaccoppiati.
Come funziona l'architettura basata sugli eventi
Le architetture basate sugli eventi hanno tre componenti chiave:
- produttori di eventi
- router di eventi
- consumatori di eventi.
Ogni produttore pubblica gli eventi sul router, che li filtra secondo regole e li invia ai consumatori.
Qui diventa fondamentale il concetto di disaccoppiamento: il router disaccoppia i servizi del produttore e i servizi del consumatore, che possono essere gestiti in maniera indipendente per funzionalità e gestione del carico.
Per la precisione, il disaccoppiamento è un pattern che promuove la realizzazione di componenti debolmente accoppiate e fortemente coese verso l’ottenimento di uno scopo.
Si tratta di una soluzione particolarmente utile nelle architetture a microservizi, che per funzionare richiede anche un altro elemento: il parallelismo. Per quanto non sia teoricamente necessario, nella pratica un sistema ad eventi generalmente permette scritture e letture concorrenti. In questo modo ciascun microservizio può scalare a piacere, permettendo di sfruttare al meglio il cloud computing.
I vantaggi: alto volume e bassa latenza
Le attuali richieste di applicazioni al mondo ICT richiedono la gestione veloce di enormi quantità di dati prelevati in moltissimi punti e da distribuire a un numero spesso enorme di destinatari. Le soluzioni software sono in gran parte standardizzate dall’impiego di fondamenta basate su sistemi aperti. Ovviamente standardizzare tutto significa eliminare il vantaggio competitivo: è per questo che ciascuna azienda deve sviluppare delle sue componenti specifiche, che mappandosi sulla specifica organizzazione e relativi processi aumentino la competitività sui punti forti dell’offerta.
È qui che la specializzazione trova il suo principale impiego. Le caratteristiche principali di questo punto sono parametrate su due valori, volume e latenza. Le soluzioni ideali sono in grado di gestire code ad alto volume e con una latenza molto bassa.
Il problema principale di questa definizione è che non è standardizzata su valori precisi: ciò che un fornitore chiama alto volume può essere basso per un altro fornitore, e lo stesso accade per la latenza. Solo un assessment preliminare può identificare volumi e latenza più adatti per una specifica esigenza, eventualmente valutandone anche l’evoluzione nel tempo. Queste informazioni permettono la miglior scelta tra le soluzioni sul mercato.
Event-driven: modelli
In genere, l’architettura event-driven può essere basata su due modelli, pub/sub o di flusso di eventi.
Nel Pub/Sub i consumatori si iscrivono a un flusso e ne diventano sottoscrittori. Ciascun evento di quel flusso si verifica e poi viene pubblicato. A questo punto, l’evento viene inviato ai sottoscrittori con bassa latenza.
Anziché essere strettamente pubblicati, gli eventi possono invece essere convogliati in un registro. I consumatori possono accedere al registro e svolgere in qualsiasi momento le azioni di partecipazione loro consentite. Questo è il flusso di eventi.
Event-driven architecture: quindi a chi conviene?
L’architettura ad eventi è essenziale per chiunque abbia bisogno di prendere decisioni in tempo reale. Si tratta di una necessità ormai presente in qualsiasi azienda, anche se a diverso livello. Ma poiché il numero di richieste di supporto alle decisioni in tempo reale cresce continuamente, è meglio avere quanto prima un ampio approccio orientato agli eventi.
I vantaggi più importanti, riassumendo, sono dunque i seguenti:
– Disaccoppiamento dei servizi
– Capacità di adattare efficacemente le risorse al carico (potendo scalare le sole componenti che devono gestire volumi significativi)
– Maggiore adattabilità alle evoluzioni (componenti funzionalmente isolate, possibilità di attivare nuovi stream di gestione indipendenti da quelli in essere).
