Che cos'è l'architettura basata su eventi?

Consente ai team di identificare gli eventi di sistema (fondamentalmente qualsiasi modifica o azione che si verifica all'interno del sistema) e rispondere e reagire ad essi in tempo reale o quasi.

La profusione di EDA in ambienti cloud-native rappresenta un significativo passaggio dalle architetture computazionali tradizionali, che si concentrano sulla memorizzazione di dati statici in archivi come i data lake (come nelle architetture orientate ai servizi), verso un approccio dinamico che tiene traccia dei dati mentre attraversano un'architettura. I dati sono ancora preziosi in un sistema basato sugli eventi, ma gli EDA enfatizzano la reazione tempestiva agli eventi, riconoscendo che il valore di un evento potrebbe diminuire con il passare del tempo.

In un'architettura basata sugli eventi, i produttori di eventi (come microservizi, API e IoT) inviano notifiche di eventi in tempo reale ai consumatori di eventi che poi attivano routine di elaborazione specifiche. Ad esempio, quando Netflix lancia una nuova serie originale, più servizi EDA attendono in standby la notifica del lancio, che attiva una cascata di aggiornamenti per informare gli utenti.

Uno dei principali vantaggi di un'architettura basata sugli eventi è la relazione disaccoppiata tra componenti front-end e back-end, che consente ai sistemi di condividere informazioni senza conoscersi. I produttori possono inviare eventi senza sapere quale consumatore li riceverà e i consumatori possono ricevere eventi senza inviare richieste ai produttori. In altre parole, gli EDA consentono ai sistemi di lavorare in modo indipendente ed elaborare gli eventi in modo asincrono.

Le aziende moderne e lungimiranti hanno una vasta impronta digitale e la funzionalità in tempo reale di un sistema basato sugli eventi consente alle aziende di mantenere la prontezza operativa senza inattività e di rispondere rapidamente alle trasmissioni di eventi. Pertanto, gli EDA aiutano le aziende ad automatizzare una serie di processi organizzativi, dall'ottimizzazione delle supply chain all'identificazione proattiva dei problemi di qualità, e in ultima analisi a migliorare sia il fatturato che i ricavi.

L'event streaming si basa su un flusso illimitato, sequenziale e in tempo reale di record di dati, chiamati "eventi", ovvero di strutture di dati fondamentali che registrano qualsiasi evento o modifica nel sistema o nell'ambiente. Esempi di tali modifiche includono un utente che aggiunge un articolo al carrello su un sito di e-commerce o richiede di ripristinare una password o modificare lo stato dell'applicazione. È un termine che si riferisce essenzialmente a ogni punto dati del sistema. Pertanto, un "flusso" (chiamato anche flusso di dati o streaming di dati) è la consegna continua di tali eventi.

Ogni evento in genere include una chiave che lo identifica, o che identifica l'entità a cui appartiene, un valore che contiene i dati effettivi dell'evento, una marcatura temporale che riporta quando l'evento si è verificato o è stato registrato, e talvolta dei metadati sull'origine dell'evento, sulla versione dello schema o su un altro attributo. Possono contenere dati sullo stato (l'articolo acquistato, il prezzo e l'indirizzo di consegna, ad esempio) o fungere da identificatori (una notifica di spedizione).

Con l'aiuto di motori specializzati di elaborazione dei flussi, gli eventi possono essere sottoposti a diversi processi all'interno di un flusso. Le “aggregazioni” eseguono calcoli sui dati, come medie, somme e deviazioni standard. “Ingestione” aggiunge dati streaming ai database. L'elaborazione analitica utilizza gli schemi rilevati nei dati in streaming per prevedere eventi futuri, mentre l'elaborazione di arricchimento combina i punti dati con altre origini per fornire un contesto e creare significato.

Gli eventi sono spesso legati a operazioni aziendali o a processi di navigazione degli utenti e in genere innescano un'altra azione, un processo o un'altra serie di eventi. Prendiamo ad esempio l'online banking. Quando un utente clicca su "invia" per inviare denaro da un conto bancario a un altro, i fondi vengono prelevati dal conto del mittente e aggiunti al conto bancario del destinatario, le notifiche via e-mail o SMS vengono inviate a una delle due parti (o a entrambe) e, se necessario, vengono implementati protocolli di sicurezza e di prevenzione delle frodi.

Oltre agli eventi, gli EDA si basano su tre componenti principali per spostare i dati degli eventi attraverso l'architettura.

• Produttori di eventi (o editori): i produttori sono le fonti degli eventi; generano eventi e li inviano al resto del sistema. Un produttore potrebbe essere un'interfaccia utente, un sensore, un servizio o qualsiasi altro sistema in grado di rilevare o produrre un cambiamento di stato di interesse per altre parti del sistema. Sebbene i produttori siano responsabili della creazione degli eventi, non hanno alcuna funzionalità di elaborazione degli eventi.

• Consumatori di eventi (o abbonati): i consumatori gestiscono le attività di elaborazione degli eventi in un'EDA. Ascoltano i canali degli eventi e reagiscono quando viene pubblicato un evento di interesse. La reazione può assumere molte forme, tra cui l'aggiornamento di un database, l'attivazione di un processo a valle o la semplice registrazione delle informazioni.

• Router di eventi (o orchestratori di eventi): i router, o orchestratori, sono i broker che separano i produttori di eventi front-end dai consumatori di eventi backend; fungono da canali attraverso i quali vengono trasmessi gli eventi, garantendo la trasmissione senza richiedere una connessione diretta tra le entità. I router possono essere basati su componenti convenzionali (middleware orientato ai messaggi,come un SaaS, ad esempio) ed essere utili in una serie di sistemi di messaggistica (code di messaggi, modelli di pubblicazione/abbonamento, event streams e altro ancora).

In un'EDA, le applicazioni guidate dagli eventi agiscono come produttori o consumatori (e talvolta entrambi).

Quando un'app o un servizio esegue un'azione che un'altra app o servizio potrebbe voler conoscere, pubblica un nuovo evento, una registrazione di quell'azione o modifica, che un altro servizio può utilizzare ed elaborare per eseguire altre azioni.

Il produttore di eventi trasmette quindi l'evento, sotto forma di messaggio, a un broker o a un altro tipo di router di eventi, che mantiene l'ordine cronologico dell'evento rispetto ad altri eventi. Un consumatore di eventi inserisce il messaggio, in tempo reale (nel momento in cui si verifica) o in un secondo momento pertinente, ed elabora il messaggio per attivare un'altra azione, workflow o evento a sé stante.

In un semplice esempio, un servizio bancario potrebbe trasmettere un evento di "deposito", che un altro servizio bancario utilizzerebbe e a cui risponderebbe scrivendo un deposito sull'estratto conto del cliente.

Ma le integrazioni basate sugli eventi possono anche innescare risposte in tempo reale basate su analisi complesse di enormi volumi di dati, come quando un cliente fa clic su un prodotto su un sito di e-commerce e il sistema genera consigli istantanei sui prodotti basati sugli acquisti di altri clienti.

L'architettura basata sugli eventi massimizza il potenziale delle applicazioni cloud-native e abilita potenti tecnologie per app, come real-time analytics e il supporto decisionale. Nel complesso, sostituiscono la tradizionale architettura "richiesta/risposta", in cui un'app deve richiedere informazioni specifiche da un'altra app e attendere una risposta prima di passare all'attività successiva.

Tuttavia, "EDA" è un termine che include diversi modelli architettonici, ognuno dei quali può essere utile per scopi diversi:

Nel modello pubb/abb, definito da una dipendenza uno a molti tra oggetti e da una relazione disaccoppiata e asincrona tra editore (produttore di eventi) e consumatore, l'editore non ha bisogno di conoscere gli abbonati. Si limita a pubblicare l'evento su un canale di eventi condiviso in cui gli abbonati ascoltano e reagiscono all'evento in modo indipendente, in tempo reale.

In genere, un broker di messaggi (router) gestisce la trasmissione di messaggi di eventi tra editori e abbonati. Il broker riceve ogni messaggio di evento, lo trasforma (se necessario), mantiene l'ordine rispetto agli altri messaggi, lo rende disponibile agli abbonati per l'utilizzo e poi lo elimina una volta usufruito (in modo che non possa essere utilizzato nuovamente).

I modelli di messaggistica sono ideali per le aziende con basi di codice di grandi dimensioni e per la trasmissione di informazioni a più consumatori (ad esempio, per i sistemi di notifica e i feed di dati in tempo reale).

Analogamente a pubb/abb, l'event streaming separa editori e consumatori per consentire una comunicazione asincrona. Tuttavia, nel modello di event streaming, i consumatori di eventi non hanno bisogno di abbonamenti agli stream; piuttosto, i produttori pubblicano flussi di eventi in un registro dei broker e i consumatori possono accedere a ogni stream in qualsiasi momento e usufruire solo degli eventi che vogliono (invece di ricevere e utilizzare tutti gli eventi pubblicati).

A differenza di pubb/abb, tuttavia, i broker di event streaming conservano gli eventi anche dopo che i consumatori li hanno ricevuti.

Poiché i consumatori possono elaborare gli eventi in qualsiasi momento dopo la loro pubblicazione, i record di event streaming sono persistenti. Ciò significa che vengono mantenuti per un periodo di tempo configurabile (da frazioni di secondo a sempre). I consumatori possono accedere allo stream in qualsiasi momento per leggere i messaggi recenti, elaborare in batch una serie di messaggi dell'ultimo accesso allo stream o fare riferimento a messaggi pertinenti del passato recente.

Le tecnologie di event streaming (come Kafka, Amazon Web Services (AWS) Kinesis e IBM Event Automation includono anche due modelli: il modello pull (in cui i broker inviano i dati dei consumatori solo quando questi indicano di essere aperti agli eventi) e il modello push (in cui la logica aziendale del broker stabilisce quali consumatori ricevono gli eventi).

Gli schemi di event streaming sono molto utili per le app che necessitano sia di aggiornamenti degli eventi in tempo reale che dell'accesso agli eventi passati (sistemi di rilevamento delle frodi per le istituzioni finanziarie, ad esempio).

Oltre ai due modelli architettonici EDA principali, tre modelli di progettazione regolano il modo in cui gli eventi vengono elaborati una volta che raggiungono l'abbonato.

• Elaborazione semplice degli eventi: in cui i consumatori elaborano gli eventi esattamente come vengono ricevuti dagli editori, innescando un'azione immediata.

• Elaborazione di flussi di eventi (ESP): dove le piattaforme di data streaming inseriscono gli eventi e creano una pipeline per lo streaming dei processori, che poi elaborano e trasformano il flusso.
  
  
• Elaborazione di eventi complessi (CEP): dove i consumatori elaborano una serie di eventi per identificare tendenze e pattern nei dati.

Tutti e tre i pattern di elaborazione (tra gli altri) possono essere utilizzati sia all'interno dei pattern architetturali di pubblicazione/abbonamento che di event streaming, ma l'ESP è (naturalmente) più comune nel pattern architetturale di event streaming.

Le EDA possono essere utili per le aziende che operano in una miriade di settori, ma sono particolarmente utili per le aziende con ambienti IT ampi e complessi.

Le aziende che cercano di integrare i sistemi in esecuzione in diversi stack, ad esempio, possono utilizzare le caratteristiche di disaccoppiamento delle architetture basate sugli eventi per mantenere i dati degli eventi indipendenti dal sistema e migliorare l'interoperabilità. Le multinazionali possono utilizzare un'EDA per coordinare i sistemi tra account e regioni, facilitando la scalabilità indipendente di diverse parti dell'architettura. E per le aziende che gestiscono sistemi che elaborano ciascuno parti diverse di un evento, le caratteristiche degli EDA possono inviare gli eventi a ciascun consumatore, senza bisogno di nuovo codice, per l'elaborazione parallela in tutto il sistema.

Nell'e-commerce, un'architettura basata sugli eventi può filtrare e indirizzare gli eventi in tempo reale per assicurarsi che vadano solo agli abbonati interessati ai loro dati. I nuovi acquisti vengono inoltrati direttamente ai consumatori che elaborano gli ordini, i problemi relativi agli ordini vengono indirizzati direttamente ai canali del servizio clienti e così via.

Le architetture basate su eventi stanno diventando essenziali per mantenere le aziende di oggi al passo con il mercato e per farle progredire nel futuro. Infatti, il 26% delle organizzazioni sta pianificando di adottare le EDA per soddisfare le esigenze aziendali, oltre a quasi il 37% delle aziende che già lo hanno fatto. ¹ Si prevede che il settore del software EDA raddoppierà le sue dimensioni, raggiungendo un fatturato di oltre 16,5 miliardi di dollari entro il 2027.²

Migliaia di eventi aziendali attraversano ogni parte di un'organizzazione ogni giorno e questi eventi forniscono una grande quantità di informazioni su ciò che accade in un'azienda in qualsiasi momento. Tuttavia, senza la tecnologia adeguata, molte aziende non sono in grado di elaborare e utilizzare questi dati per prendere decisioni informate sui propri clienti, prodotti o attività.

È qui che le piattaforme EDA diventano inestimabili, consentendo l'automazione dei processi ad alto rendimento e bassa latenza e fornendo strumenti avanzati per una serie di casi d'uso, tra cui:

Le architetture basate su eventi mettono in pratica gli eventi aziendali consentendo agli utenti di rilevare situazioni emergenti, agire in tempo reale, automatizzare il processo decisionale e massimizzare il potenziale di fatturato. L'EDA può anche aiutare le imprese a sostenere e accelerare la crescita, offrendo:

Gli EDA consentono ai sistemi di scalare aggiungendo più istanze di servizi per gestire un aumento dei workload.

Gli EDA consentono ai componenti di comunicare in modo asincrono; i produttori pubblicano i messaggi degli eventi secondo i propri orari, senza aspettare che i consumatori li ricevano (o nemmeno sapere se i consumatori li hanno ricevuti), semplificando sia l'integrazione che l'esperienza utente.

I servizi possono essere aggiunti, rimossi o modificati indipendentemente, facilitando pratiche di sviluppo e implementazione Agile.

Gli EDA sono disaccoppiati nel tempo e nella sincronizzazione, quindi i produttori di eventi e i consumatori interagiscono tramite eventi (anziché chiamate API dirette), il che riduce le dipendenze e aumenta la resilienza complessiva del sistema.

L'EDA è intrinsecamente progettato per l'elaborazione e la risposta in tempo reale, consentendo ai team di rispondere in modo più proattivo e facilitando azioni e automazioni più intelligenti.