Joyce: una piattaforma cloud data hub per semplificare la gestione dei dati

Autore: Raffaele Camanzo

Perché implementare un data hub? 

Da alcuni anni la sfida principale per le aziende digitali di qualunque dimensione si è spostata dalla produzione e salvataggio dei dati alla capacità di gestirli ed estrarne valore. Le tecnologie coinvolte sono moltissime e in continua espansione con nuove soluzioni e nuovi paradigmi a supporto di una strategia di data management sempre più articolata e complessa. 

L’Hype Cycle 2021 sul data management pubblicato da Gartner a luglio censisce decine di nuovi paradigmi tecnologici emergenti (non tiene infatti conto di quelli che hanno raggiunto il livello di completa maturità) restituendo un’istantanea degli strumenti a supporto dell’evoluzione in questo campo. 

Nel documento è censita anche la “Data Hub Strategy”, la cui adozione è considerata ad alto beneficio e con una previsione di adozione di massa nei prossimi 2-5 anni; una strategia che per dirlo con le parole degli analisti “guida l’implementazione di uno o più data hub, architetture logiche che abilitano la condivisione di dati tra produttori e consumatori di dati”. La ragione per cui la strategia è importante è che “i business digitali richiedono un’enfasi nelle connessioni tra sistemi, persone e cose come fonte di vantaggio competitivo. Le aziende di solito ottengono questo obiettivo con due approcci: 

• Connettendo applicazioni e fonti dati con interfacce punto-punto 
• Centralizzando più dati possibile all’interno di un singolo sistema 

Entrambi gli approcci diventano sempre costosi e poco flessibili. Applicare una data hub strategy abilita una migliore condivisione dei dati attraverso un flusso dati più consistente, scalabile e ben governato”. 

In aziende strutturate i sistemi coinvolti nello scenario descritto possono essere diverse decine, tipicamente gestiti ed evoluti da team distinti con i propri obiettivi e roadmap; proviamo ad approfondire quali sono le principali limitazioni dei due approcci tradizionali descritti. 

Centralizzazione verso un singolo sistema 

L’utilizzo di soluzioni che mirano a centralizzare dati o servizi porta benefici in termini di razionalizzazione e organizzazione dei flussi di lavoro, che tuttavia è limitato al breve periodo. Le cause principali di deriva di questo modello non sono di carattere tecnologico ma riguardano aspetti organizzativi ed evolutivi dei sistemi aziendali.  

I temi organizzativi sono di due categorie: la prima dipende dalla disponibilità del team che manutiene ed evolve la struttura centralizzata, per quanto competenti possano essere i suoi componenti, non è un modello scalabile e diventa inevitabilmente un collo di bottiglia, causando ritardi e disappunto sul tipo di scelta operata; la seconda è dovuta alla composizione del team stesso, che non potendo racchiudere in sé tutte le conoscenze sui domini del business è tipicamente di composizione tecnica e quindi distante dalle necessità tanto dei produttori che dei consumatori dei dati/servizi che gestisce/crea. L’aspetto evolutivo è anche più complesso e difficile da misurare, perché non procede secondo un modello lineare, le necessità possono mutare in maniera contraddittoria rispetto al passato, si può procedere per raffinamenti successivi dell’idea originale, tipicamente creando un debito tecnico che nel tempo riduce l’efficacia e la manutenibilità delle soluzioni. 

Non mancano comunque gli aspetti tecnici: centralizzare tutte le necessità su un singolo sistema lo rende un single point of failure particolarmente critico perché la sua indisponibilità ha impatto su tutti i servizi, far convergere tutte le esigenze crea complessità e interdipendenze difficili da tracciare ed evolvere nel tempo; infine i sistemi che centralizzano servizi mantengono una dipendenza diretta con i sistemi produttori, le cui prestazioni possono limitare l’esperienza d’uso dei sistemi a valle, scenario particolarmente critico se questi ultimi sono servizi B2C. 

Connessioni punto-punto 

La figura sotto descrive cosa accade a livello logico quando si adotta una strategia punto-punto, il diagramma mostra a colpo d’occhio un rischio concreto di confusione, entropia e inefficienza dovuti al proliferare di soluzioni ad hoc via via realizzate per rispondere ad ogni necessità di integrazione, ma non mostra gli ulteriori grandi limiti di questo approccio, ovvero le dipendenze dal punto di vista delle risorse, funzionali e dei tempi di realizzazione. 

Le dipendenze su risorse utilizzate e funzionali sono evidenti, esponendo servizi direttamente dai sistemi sorgente, questi sosterranno il traffico diretto proveniente dai sistemi consumatori e qualunque evoluzione coinvolgerà inevitabilmente sistemi a monte e a valle della catena. Questo tipo di integrazione incide sui tempi di realizzazione ben oltre quanto necessario per realizzare le interfacce, essendo queste necessità slegate dal processo evolutivo dei sistemi produttori si sommano alle attività già in carico ai team che se ne occupano, richiedono negoziazione, inserimento all’interno dei backlog di attività e ovviamente manutenzione. 

I vantaggi di un data hub 

Il data hub è un pattern architetturale che realizza un livello di disaccoppiamento tra i sistemi produttori e consumatori, acquisendo i dati dalle sorgenti per renderli disponibili attraverso un layer di servizi; le caratteristiche fondamentali sono condivisione dei dati e governance. Come evidenziato nel documento di Gartner, a seconda delle necessità e dimensioni dell’azienda, la strategia di adozione di queste tecnologie può richiedere la realizzazione di uno o più hub, così da non incorrere nei problemi affrontati sopra sulla centralizzazione di tutti i flussi verso una singola componente dell’architettura aziendale. 

Rispetto alle soluzioni precedenti, introdurre uno strumento di questo tipo presenta diversi vantaggi: 

• Disaccoppiamento funzionale. Potendo agire sia sui dati caricati in piattaforma che sulle interfacce esposte i sistemi a monte e a valle possono evolvere autonomamente ed eventualmente essere sostituiti senza creare un impatto diretto sugli altri sistemi in architettura 
• Disaccoppiamento delle risorse. I servizi di cui fruiscono i consumatori sono erogati direttamente dall’hub, evitando così che i carichi di lavoro richiedano un coinvolgimento diretto dei sistemi sorgente 
• Governance. Un hub mette a disposizione strumenti per censire e organizzare le interfacce esposte in modo da rendere semplice catalogazione e ricerca 

Con un data hub avviene una copia fisica dei dati, questo aspetto potrebbe indurre qualche perplessità su quanto sia applicabile e sostenibile operare una scelta in questa direzione, di seguito alcune considerazioni sul tema: 

• Il caricamento dei dati su una nuova piattaforma permette di effettuare attività di normalizzazione, arricchimento e composizione che non sono possibili su sistemi operazionali in cui i dati sono tipicamente normalizzati e organizzati secondo il formato funzionale allo scopo del singolo sistema 
• La denormalizzazione dei dati è una scelta che si compie da diversi anni, in particolare in ambiti analitici, grazie alla costante riduzione dei costi dei supporti di memorizzazione, è una pratica che ha portato enormi benefici in termini di leggibilità e performance 
• Un data hub dovrebbe permettere di impostare la retention dei dati, mantenendo i dati in piattaforma per il tempo necessario alla propria funzione 

Il diagramma della figura sotto mostra in che modo cambia l’interazione tra sistemi con l’introduzione di un data hub. 

Le caratteristiche di Joyce 

Joyce è un data hub cloud native con architettura event-driven, utilizza Kafka e MongoDB per garantire scalabilità, affidabilità e performance. La piattaforma ha un modello dichiarativo basato su JSON Schema che permette di realizzare velocemente integrazioni dati; ogni schema viene indicizzato e salvato in un catalogo suddiviso in categorie personalizzabili per poter ricercare e organizzare i contenuti con semplicità ed efficacia.  

Il concetto su cui si fonda Joyce è lo schema, che permette di definire il formato dei dati caricati e come questi verranno resi disponibili ai sistemi consumatori, gli schemi sono di tre categorie: 

• Input. Stabiliscono in che modo acquisire e formattare i dati sorgente, per rendere l’acquisizione semplice e priva di dipendenze dai team dei sistemi produttori, la piattaforma utilizza il framework Kafka Connect, un sistema estendibile di connettori pronti all’uso per interagire con un’ampia gamma di sistemi 
• Model. Questi schemi permettono di realizzare nuove viste sui dati acquisiti, è possibile generare aggregazioni libere di più fonti per strutturare i dati nel formato richiesto dai sistemi consumatori 
• Export. Gli schemi di export hanno lo scopo di realizzare esportazioni massive in formato CSV per i sistemi consumatori alimentati solamente con caricamenti di file, le esportazioni possono essere eseguite sia periodicamente che su richiesta 

API auto generate 

I dati caricati e generati dalla piattaforma vengono resi disponibili immediatamente attraverso API auto generate in formato standard REST e GraphQL, le API REST sono documentate secondo lo standard OpenAPI 3 e interrogabili attraverso un client Swagger, gli schemi GraphQL sono documentati e interrogabili attraverso un client GraphiQL. 

Per i servizi consumatori che hanno un’architettura event-driven è possibile accedere ai dati nel momento in cui sono disponibili in piattaforma consumando gli eventi pubblicati su un topic Kafka dedicato a questo scopo. 

Sicurezza 

La piattaforma utilizza diversi meccanismi per garantire sicurezza e controllo di accesso ai dati e alle interfacce: 

• Encryption. È possibile abilitare l’encryption dei dati at rest e in transit 
• Controllo di accesso delle API amministrative. L’amministrazione della piattaforma è soggetta a controllo di accesso, è possibile infatti associare specifici permessi di Joyce a utenti e gruppi presenti nei sistemi di identity management aziendale 
• Sicurezza delle API auto generate. La piattaforma supporta sistemi token-based e api key per garantire l’accesso alle API solo a specifici utenti/ruoli o applicazioni 
• Segregazione dei dati. È possibile impostare livelli di visibilità sui dati basati su ruoli (RBAC) e stabilire filtri a livello di documento (document-level security) 

Scalabilità 

L’ambiente runtime di Joyce è Kubernetes, ogni componente del sistema è stata realizzata per garantire il parallelismo e sfruttare il potenziale messo a disposizione dall’orchestratore e dal cloud computing per gestire efficacemente enormi moli di dati e traffico, l’architettura disaccoppia completamente le componenti di acquisizione da quelle di interfaccia per adattare il comportamento alle specifiche necessità del contesto in cui opera. 

Una soluzione ai problemi di data integration 

L’integrazione dei dati aziendali è un tema ricorrente e che si affronta da decenni, tuttavia come evidenziato da Gartner, diversi fattori hanno reso questa necessità più urgente e più complessa da gestire, soprattutto applicando logiche ed approcci del passato. Il bisogno di agire velocemente e l’aumento esponenziale della quantità e varietà dei dati a disposizione sono fattori determinanti da tenere in considerazione quando si opera una scelta su quale soluzione adottare. Joyce è uno strumento flessibile e potente che utilizza il cloud computing, tecnologie scalabili e un’architettura distribuita per supportare un’ampia gamma di casi d’uso; la capacità di collegarsi immediatamente a diverse decine di fonti e il suo modello dichiarativo permettono di realizzare integrazioni dati complesse in pochi giorni ed evolvere il suo comportamento al mutare dei bisogni nel tempo con un notevole risparmio economico e di risorse.