A cura di Diego Daniele, Country Leader Confluent Italia
Una domanda che ricorre spesso nelle conversazioni è: “Batch o tempo reale?”. Eppure, le risposte sembrano sempre più disconnesse dalla realtà che le organizzazioni si trovano ad affrontare oggi. Viviamo in un contesto economico incerto, con il rischio di recessione globale, mercati finanziari dominati da pochi titoli e una volatilità che è ormai la norma. Eppure, troppi team progettano ancora in base al minimo comune denominatore, ovvero in batch, semplicemente perché non tutti i casi d’uso richiedono immediatezza. Questo approccio, però, limita le possibilità, oltre al fatto che si dovrebbe progettare per ottenere sempre il massimo risultato.
L’ideale è costruire architetture basate sugli eventi che supportino di default funzionalità in tempo reale e siano in grado di servire qualsiasi caso d’uso, attraverso un accesso e un’interpretazione flessibili dei dati. Un approccio di questo tipo rappresenta un cambiamento di mentalità, ed è atteso da tempo. La domanda giusta, quindi, non è se tutti i casi d’uso richiedano dati in tempo reale, ma se la piattaforma dati della propria organizzazione sia costruita per adattarsi in modo rapido, affidabile e su larga scala, a prescindere dalla velocità con cui cambiano le condizioni esterne.
Perché si dovrebbe progettare in base ai risultati e non alla velocità
Concentrarsi sull’elaborazione dei dati in batch o in streaming distrae da una verità più importante: l’architettura dovrebbe supportare i risultati aziendali che si devono ottenere e non essere vincolata alla velocità di acquisizione dei dati. Alcuni dati arrivano rapidamente in streaming, mentre una parte viene acquisita in batch periodici. Questa è una realtà. Tuttavia, creare sistemi separati attorno a queste diverse velocità di flusso dati porta a un’infrastruttura frammentata, a una complessità non necessaria e a una ridotta agilità.
Ciò che serve è una piattaforma unificata, in grado di gestire tutte le velocità dei dati e supportare tutti i casi d’uso da un unico punto. Non bisogna progettare i sistemi in base al caso d’uso più lento, ma in base a criteri di flessibilità, scalabilità e reattività. In questo modo è possibile interpretare e agire sui dati al ritmo che la situazione richiede.
Il real-time riduce i costi
Contrariamente a un pensiero comune, il real-time non è più costoso, ma più efficiente. L’elaborazione in batch, per sua natura, consuma più risorse. È come avviare più e più volte il motore di una vecchia automobile: ogni riavvio richiede un aumento di energia, soprattutto se il sistema deve gestire picchi imprevedibili. Questo determina un over-provisioning dell’infrastruttura e costringe a mantenere una grande capacità sempre attiva per carichi di punta occasionali, sacrificando l’efficienza a favore della semplicità.
Al contrario, l’elaborazione continua in base agli eventi funziona come un motore ben messo a punto, che viaggia a una velocità costante. I dati fluiscono continuamente e le risorse scalano automaticamente per soddisfare la richiesta. Le previsioni diventano più accurate perché il flusso di dati e il costo per elaborarli sono pronosticabili.
L’efficienza diventa ancora più vantaggiosa man mano che le organizzazioni ampliano l’utilizzo dell’intelligenza artificiale. Nei sistemi batch, i workload AI devono essere eseguiti per periodi brevi e con un utilizzo significativo delle risorse e questo determina un aumento dei costi di elaborazione e delle emissioni di carbonio.Con l’aumento dell’attenzione sull’impatto ambientale dell’IA, questo approccio si sta rivelando insostenibile.
Ancora più resilienza nei diversi casi d’uso
Le piattaforme dati più efficaci non sono progettate per scegliere tra real-time o batch, ma per entrambe le situazioni. È necessario avere dei sistemi in grado di elaborare e reagire continuamente alle nuove informazioni non appena arrivano, così come di poter congelare un momento nel tempo.
Prendiamo ad esempio i servizi finanziari. Una banca potrebbe scattare un’istantanea della sua esposizione al rischio globale alle ore 9:00 e fissare dei limiti per i trader. Ma se un nuovo annuncio tariffario dovesse arrivare alle 9:05 – alterando improvvisamente la struttura dei costi o il rischio nel paese – l’azienda avrebbe bisogno di un avviso in tempo reale. È lo stesso flusso di dati che può alimentare entrambi gli output: un’istantanea puntuale per la pianificazione e un avviso in tempo reale per un’azione di intervento.
Questa doppia capacità, statica e dinamica a partire da un’unica fonte, non riguarda solo il settore finanziario. Nel campo delle assicurazioni sanitarie, ad esempio, fornitori come Vitality offrono dispositivi indossabili che monitorano l’attività e premiano il comportamento sano. In questo caso, i dati in tempo reale migliorano l’esperienza utente riducendo i sinistri e controllando i costi per l’azienda.
Più che un cambiamento tecnologico, è un cambiamento di mentalità
Perché, nonostante i vantaggi, molte organizzazioni esitano ancora ad adottare architetture per lo streaming dei dati?
Spesso non è la tecnologia a frenare, ma la mentalità organizzativa. Molti dirigenti ammettono che la vera sfida risiede nel modo in cui sono strutturati i budget. I costi relativi a software, infrastruttura e personale vengono spesso trattati come voci separate, gestite da team diversi con obiettivi diversi.
Il risultato? Le decisioni a breve termine che sembrano convenienti sulla carta, come l’adozione di strumenti open source “gratuiti”, possono portare a complessità a lungo termine e richiedere grandi team tecnici solo per far funzionare le cose.
In generale, molti dipartimenti continuano a progettare sulla base di limitazioni che non hanno più, nate in un’era di infrastrutture fisse e cicli di cambiamento lenti. Ma le piattaforme per lo streaming dei dati in tempo reale consentono di progettare in modo diverso, con meno sprechi operativi, maggiore visibilità in real-time e flessibilità di gran lunga maggiore per una risposta proattiva ai cambiamenti.
Progettare per il mondo di oggi
La maggior parte dei responsabili IT non è cresciuta in un ambiente caratterizzato da una volatilità costante. Abbiamo costruito sistemi per un’epoca in cui il cambiamento era graduale, l’infrastruttura era fissa e i report puntuali erano “sufficienti.”
Quel mondo non esiste più e le architetture dati devono evolvere di conseguenza. Ciò significa abbandonare i costrutti legacy e progettare piattaforme che riflettano il modo in cui le aziende operano realmente oggi: a velocità diverse, con molteplici casi d’uso e sotto costante pressione di adattamento.
Non si deve costruire per il mondo da cui si proviene, ma per il mondo che si vuole guidare.
