EventBridge per la gestione degli eventi

Al Santagostino la comunicazione tra i vari applicativi (interni, Saas, ecc..) è sempre stata molto complessa.

Si sono usati spesso cron per poter verificare la presenza di situazioni che potessero scatenare azioni prestabilite (es: l’emissione di una fattura scatenava un sms di notifica all’utente).

Questo approccio però rendeva tutto complesso, poco scalabile e monitorabile.

Con l’introduzione del Middleware abbiamo introdotto anche il concetto di “eventi” sfruttando ail pattern Observer.

Per l’implementazione di questo concetto abbiamo utilizzato, come ormai è nostra prassi, un servizio AWS denomitao EventBridge.

Perchè abbiamo scelto EventBridge al posto di SNS?

Nella fase di scelta, abbiamo fatto un pò di scouting tra le possibilità che AWS ci forniva per poter implementare il nostro sistema ad eventi.

Le scelte erano due AWS EventBridge e AWS SNS.

AWS SNS

Amazon Simple Notification Service (Amazon SNS) è un servizio gestito che offre la consegna dei messaggi dagli editori agli abbonati (noti anche come Produttori e Consumer).

Gli editori comunicano in modo asincrono con gli abbonati creando e inviando messaggi a un argomento, che rappresenta un punto di accesso logico e un canale di comunicazione.

I client possono iscriversi all’argomento SNS e ricevere messaggi pubblicati utilizzando un tipo di endpoint supportato, come Amazon Kinesis Data Firehose, Amazon SQS, AWS Lambda, HTTP, e-mail, notifiche push per dispositivi mobili e messaggi di testo (SMS).

AWS EventBridge

EventBridge è un servizio serverless che utilizza gli eventi per collegare tra loro i componenti delle applicazioni, semplificando la creazione di applicazioni scalabili basate sugli eventi.

Utilizzatelo per indirizzare gli eventi da fonti come applicazioni,AWS servizi e software di terze parti locali alle applicazioni consumer di tutta l’organizzazione.

EventBridge offre un modo semplice e coerente per inserire, filtrare, trasformare e distribuire eventi in modo da poter creare rapidamente nuove applicazioni.

La scelta è ricaduta su AWS EventBridge perchè ci permetteva di:

• collegare più consumer ad un’evento
• dirottare un determinato evento su un consumer specifico in base a regole di routing
• rielaborare per lungo tempo l’evento in caso di failover

Con queste prospettive che la soluzione AWS ci offriva abbiamo realizzato un servizio come smistatore e consumatore degli eventi prodotti, in modo tale che la logica di business, su cosa un’evento dovrebbe fare, venga demandata ad uno strumento interno e non ai singoli software (che in alcuni casi non sono direttamente mantenuti da noi).

Conclusioni

Sono molto positive!

L’introduzione di questo strato ci sta permettendo di:

• disaccoppiare i software sempre più
• gestire flussi asincroni, per migliorare l’esperienza utente
• avere maggior controllo sui flussi

Anche le numeriche sono positive: nei primi 30 giorni abbiamo gestito ~322K di chiamate a 4 tipologie di eventi.

continueremo ad usare questo approccio, gestendo sempre più eventi e portando l’infrastruttura ad un sistema event-driven.