L'Event-Driven Architecture (EDA) è reattiva agli eventi o ai messaggi e attiva azioni specifiche piuttosto che affidarsi a una comunicazione diretta e sincrona. L'EDA è asincrona e consente ai componenti di operare in modo indipendente, migliorando la reattività e le prestazioni del sistema in presenza di carichi di lavoro variabili.
Consideriamo due semplici esempi: il caricamento di file e la registrazione di un nuovo utente. Entrambe le operazioni possono avvenire tramite un flusso sincrono di richiesta-risposta (cioè REST). API), ma è necessario effettuare una nuova richiesta per aggiornare lo stato del caricamento dei file o per attivare l'azione successiva da intraprendere dopo l'inserimento dei dati del nuovo utente nel database. Immaginate di avere un gruppo di task runner che eseguono continuamente il polling dei messaggi; lavorano instancabilmente in periodi di silenzio radio o di chiacchiere non correlate per ottenere occasionalmente un messaggio su cui agire. Si può capire come questo non sia l'uso più efficiente dell'elasticità delle risorse di cloud computing on-demand. EDA risolve questo problema con un approccio basato sul push.
I sistemi event-driven possono scalare rapidamente aggiungendo o rimuovendo componenti in base alle necessità e possono essere altamente resilienti ai guasti, in quanto il sistema può continuare a funzionare anche se un componente non è disponibile. EDA è inoltre adatto all'elaborazione in tempo reale e alla gestione di grandi volumi di dati, in quanto i componenti possono reagire agli eventi ed elaborare i dati man mano che arrivano, senza attendere un set di dati completo.
Perché prendere in considerazione l'EDA?
- Maggiore flessibilità del sistema: La natura loosely coupled di un'architettura event-driven consente di modificare, aggiungere o rimuovere facilmente i componenti senza influenzare l'intero sistema, rendendolo adattabile a requisiti mutevoli.
- Scalabilità migliorata: EDA supporta una facile scalabilità orizzontale, consentendo alle aziende di gestire carichi di lavoro o traffico crescenti aggiungendo più istanze di componenti o servizi secondo le necessità.
- Maggiore resilienza del sistema: La comunicazione asincrona e i componenti disaccoppiati di EDA contribuiscono a migliorare la tolleranza ai guasti, poiché il guasto di un componente non causa necessariamente un'interruzione dell'intero sistema.
- Capacità di elaborazione in tempo reale: L'EDA consente l'elaborazione in tempo reale di grandi volumi di dati e di modelli di eventi complessi, rendendolo adatto alle aziende che richiedono approfondimenti immediati o risposte a condizioni in rapida evoluzione.
- Ottimizzazione dell'utilizzo delle risorse: Reagendo agli eventi solo quando si verificano, l'EDA contribuisce a ottimizzare l'utilizzo delle risorse e a ridurre la necessità di processi in continua esecuzione, con potenziali risparmi sui costi e una maggiore efficienza.
Elaborazione nativa in cloud senza server
L'EDA consente modelli di sviluppo di applicazioni come il serverless computing, permettendo al codice di essere portabile e agnostico rispetto ai provider, in modo da poter scegliere il proprio cloud provider in base alle caratteristiche, al linguaggio supportato, ai costi, ecc. Functions-as-a-Service (FaaS) è un prodotto popolare offerto da molti fornitori di cloud, che consente agli utenti di gestire funzioni e infrastrutture applicative in un'unica soluzione. Il cloud provider funge da livello di responsabilità gestendo l'infrastruttura sottostante, compresi il provisioning dei server, lo scaling e la manutenzione, consentendo agli sviluppatori di concentrarsi sulla scrittura del codice.
I servizi FaaS più noti, come AWS Lambda, Azure Functions e Google Cloud Functions, sono quelli che noi definiamo "platform-native". Spesso vi vincolano all'uso di uno specifico fornitore di cloud, senza che sia possibile migrare facilmente. Ci sentirete parlare molto di Knative, una piattaforma open source basata su Kubernetes per l'esecuzione di serverless, in grado cioè di scalare l'applicazione da 0 a N numeri di repliche in pochi secondi. Scalare a 0 è fantastico perché permette a Kubernetes e Knative di riallocare le risorse secondo le necessità.
Il vostro frammento di codice può scalare le risorse automaticamente perché può essere invocato più volte in parallelo. Le offerte platform-native FaaS che abbiamo menzionato in precedenza non sono vantaggiose a causa dei prezzi imprevedibili. Eseguendo Knative sulle nostre istanze di calcolo tramite il nostro servizio Kubernetes gestito, pagherete un prezzo fisso e prevedibile e non dovrete preoccuparvi dei prezzi per esecuzione che entrano in vigore dopo alcuni livelli gratuiti.
Perché considerare Serverless?
- Efficienza dei costi: Il modello di pricing pay-as-you-go del serverless computing può portare a risparmi sui costi, in quanto le aziende pagano solo per il tempo di calcolo utilizzato senza allocare le risorse in anticipo.
- Scalabilità migliorata: L'elaborazione serverless è in grado di scalare automaticamente le risorse in base alla domanda, assicurando che le applicazioni possano gestire carichi di lavoro maggiori senza interventi manuali o tempi di inattività.
- Riduzione dei costi operativi: Con il serverless computing, il cloud provider gestisce l'infrastruttura sottostante, liberando i team IT per concentrarsi sullo sviluppo delle applicazioni, sull'innovazione e su altre iniziative strategiche.
- Time-to-market più rapido: I processi di sviluppo e distribuzione semplificati offerti dal serverless computing possono aiutare le aziende ad accelerare il rilascio di nuove funzionalità, aggiornamenti e correzioni di bug, migliorando il loro vantaggio competitivo.
- Flessibilità e adattabilità: Il serverless computing consente alle aziende di costruire e distribuire applicazioni utilizzando una varietà di linguaggi di programmazione e tecnologie, rendendo più facile l'adattamento a requisiti mutevoli o l'incorporazione di nuove tecnologie in base alle necessità.
Come ho già detto, il serverless computing si basa su un'architettura event-driven, ovvero le funzioni vengono attivate da eventi come richieste HTTP, upload di file, aggiornamenti di database e così via. Ciò può contribuire a semplificare l'architettura dell'applicazione e a migliorare la scalabilità.
Anche le funzioni serverless dovrebbero essere stateless. Non memorizzano alcun dato o stato tra un'invocazione e l'altra, assicurando che le funzioni siano facilmente scalabili e che sia possibile sostituirle se falliscono. Inoltre, dovrebbero avere una durata breve, per evitare che le risorse vengano sprecate e che la funzione possa scalare rapidamente. Se il compito di una funzione è di lunga durata, è opportuno valutare se un servizio in continua esecuzione sia più adatto.
Non dimenticate di monitorare e registrare le funzioni serverless per assicurarvi che funzionino come previsto e per identificare eventuali problemi o errori. Utilizzate strumenti come aggregatori di log e strumenti di monitoraggio delle prestazioni delle applicazioni (APM) come Prometheus e Grafana. Non dimenticate di proteggere le funzioni utilizzando le migliori pratiche come l'autenticazione, l'autorizzazione e la crittografia. Questo garantisce la sicurezza dell'applicazione e la protezione dei dati sensibili. Testatele a fondo prima di distribuirle in produzione per assicurarvi che funzionino come previsto e siano prive di vulnerabilità.
Il computing serverless può essere conveniente, ma è importante utilizzare tecniche di ottimizzazione dei costi come l'ottimizzazione delle funzioni, la condivisione delle risorse e l'autoscaling per ridurre i costi e migliorare l'efficienza. Valutate il vostro carico di lavoro, i modelli di utilizzo e i requisiti per determinare se il serverless computing è conveniente per il vostro caso d'uso specifico. Considerate i modelli di utilizzo previsti, i requisiti di prestazione e la struttura dei prezzi della piattaforma serverless che scegliete di utilizzare.
Commenti