Che cos'è il reporting dei microservizi?

Il reporting dei microservizi si ha quando i report sono creati da un'architettura di microservizi. Sebbene l'architettura di microservizi offra molti vantaggi all'organizzazione, crea delle sfide per il reporting a causa della sua natura frammentata.

Che cos'è un modello di microservizi?

Per comprendere il reporting dei microservizi, è necessario comprendere bene l'architettura che ne sta alla base. Un'architettura di microservizi è un sistema basato sul cloud in cui il sistema software di un'organizzazione è costituito da una serie di componenti più piccoli. Questi servizi o componenti sono distribuibili in modo indipendente, ma sono collegati tra loro in modo flessibile, in genere utilizzando le interfacce di programmazione delle applicazioni (API). In modo simile al funzionamento di un cervello, i servizi sono come cellule cerebrali, collegate tra loro da sinapsi (API) che permettono la comunicazione di informazioni da una cellula all'altra. Ognuno di questi microservizi è responsabile di un'azione o di un requisito specifico e si distribuisce automaticamente quando è necessario.

Questi servizi hanno tutti i propri database e non condividono le informazioni da un database centrale come fanno altri sistemi. Questo sistema è definito "delimitato", con tutto ciò che è necessario per il funzionamento del servizio legato all'app.

Questa natura delimitata è importante per garantire che non ci sia un accoppiamento involontario dei servizi. Se gli schemi di dati sono condivisi tra i servizi, una modifica in uno di essi deve essere replicata in tutti gli schemi di dati sottostanti. Mantenere tutto separato. Questo significa con modifiche limitate, servizi completamente autonomi e un'architettura che conserva tutta la sua agilità.

Le organizzazioni scelgono di utilizzare i microservizi per una serie di motivi. Le app indipendenti possono essere facilmente aggiornate e modificate, e possono essere aggiunte rapidamente nuove funzionalità. Diversi team possono gestire diversi stack di app o programmi che operano sotto un unico ombrello, aggiungendo un'enorme agilità al modello aziendale.

Può anche essere un'architettura molto conveniente. Le API sono gratuite o a basso costo; i singoli programmi possono essere software as a service (SaaS) e seguire l'approccio "user pays". È completamente scalabile e non richiede un'enorme infrastruttura.

Le aziende che utilizzano l'architettura di microservizi includono Amazon, Netflix, Uber e SoundCloud. Si tratta davvero di una struttura software che consente un'enorme flessibilità e scalabilità in un modello aziendale.

Tuttavia, gli svantaggi dei microservizi sono che le API creano maggiori rischi di attacchi informatici, diversità del linguaggio di programmazione e della comunicazione tra le app. Ma il problema più grande riguarda la reportistica. Ogni app o programma ha il proprio database. Quindi, come fa un utente a estrarre tutti i dati dai database per eseguire i report? Questo concetto di estrazione dei dati da ogni applicazione non preserva il valore fondamentale del contesto delimitato.

Reporting dei microservizi

Se un'organizzazione gestisce un'architettura di microservizi, un modello semplice potrebbe presupporre che abbia programmi diversi per:

• Finanze e fatturazione
• Strumento di flusso di lavoro
• Programma di vendita
• Sistema di buste paga

Ognuno di questi microservizi ha il proprio database. Le API lavorano per collegare questi programmi tra loro, in modo che possano operare sotto un'unica interfaccia. Tuttavia, i problemi iniziano quando sono richiesti report che attingono dati da più database.

Un esempio è quando le retribuzioni si basano sui lavori completati e fatturati. Lo strumento finanziario ha bisogno di accedere allo strumento di flusso di lavoro, e solo allora lo strumento buste paga dispone di informazioni precise per pagare i dipendenti. Se un'azienda vuole eseguire un report che mostri i lavori in corso rispetto alle vendite realizzate per il mese, deve accedere a tre programmi diversi.

Diventa ancora più complesso quando ci sono molti, molti microservizi. Netflix, ad esempio, ha più di due miliardi di richieste API Edge al giorno, distribuite sugli oltre 700 microservizi. Uber utilizza oltre 1300 microservizi. Con un vasto numero di servizi, la reportistica diventa più complessa.

Sfide con il reporting dei microservizi

Il reporting dei microservizi presenta tre sfide principali.

Problemi di prestazioni

Se un'azienda ha due miliardi di richieste API al giorno per le funzioni aziendali, immaginate il contributo del reporting al carico. Se uno strumento di reportistica preleva i dati da più fonti, spesso diverse centinaia di volte al giorno, come influirà sul sistema? Rallenterà notevolmente i processi o forse finirà per interromperli.

Antipattern

L'idea stessa dell'architettura di microservizi è che ogni servizio è delimitato. Cioè, ogni applicazione è un mini programma a sé stante. Contiene tutto ciò di cui ha bisogno e opera entro i propri confini. Non ha bisogno di accedere a nient'altro per completare le sue funzioni.

Quando il reporting richiede che i servizi condividano i loro database, diventa un antipattern.

Diversi modelli e tipi di dati

Se ogni servizio è scritto in un linguaggio di programmazione diverso, deve esserci un ulteriore livello di comunicazione tra i servizi per consentire la comprensione. E poi, se il modo in cui i dati sono presentati non è nella stessa forma di un altro, devono essere manipolati automaticamente in modo che possano essere digeriti e utilizzati dallo strumento di reporting.

Dati contrastanti

Poiché ogni servizio ha il proprio database, potrebbero esserci ridondanze, duplicazioni o conflitti di dati. Ad esempio, se un fornitore è anche un cliente e ha lo stesso indirizzo fisico, ma uno è errato nel sistema, questo potrebbe causare problemi nella compilazione dei dati.

Cosa richiede il reporting per i microservizi

Una buona reportistica è essenziale per la salute e la crescita di un'organizzazione. Un buon sistema di reporting deve avere i seguenti elementi:

Facilità d'uso

I report devono essere semplici da eseguire. Utilizzando una dashboard centrale, i report devono essere facili per selezionare i parametri e applicare i relativi dati. Poiché i microservizi ricadono tutti sotto l'ombrello di una dashboard, questo si ottiene facilmente.

Unica fonte di verità

Affinché i report siano precisi, i dati devono essere corretti. Deve esserci un'unica fonte di verità per i dati, senza doppioni, informazioni vecchie o errate, e tutto ciò di cui il rapporto ha bisogno deve essere presente. Questa è la sfida più grande per i microservizi, poiché le applicazioni sono separate e debolmente accoppiate.

tempestivi

In un mondo in cui tutto è istantaneo, i report devono essere aggiornati al minuto. Quando ci sono le vendite natalizie, un cambiamento nell'ambiente di lavoro o un diverso comportamento dei clienti, questi cambiamenti devono essere annotati e affrontati il prima possibile. Ciò pone delle sfide anche al modello dei microservizi, a seconda di come si accede ai dati.

Veloci

Se un report richiede ore per essere eseguito e mette a dura prova le risorse, si tratta di un ostacolo significativo alla riuscita dei sistemi di reporting. L'esecuzione di migliaia di API per accedere ai dati simultaneamente crea una barriera considerevole per un buon reporting nell'architettura di microservizi.

Automazione

Il sistema per ottenere i dati, estrarli, elaborarli ed eseguire i report deve essere altamente automatizzato. Gli utenti non devono accedere al back-end, eseguire operazioni manuali o manipolare manualmente i dati.

Facile da comprendere

Presentare i report in righe di dati granulari non è sempre ciò che serve, né è il modo migliore per far comprendere le informazioni. Invece, affinché i rapporti siano facilmente digeribili da una serie di utenti, dovrebbero essere presentati in grafici, tabelle e grafica che mostrino rapidamente tendenze, modelli e cifre.

Possibilità di effettuare il drill down

Se un utente o un presentatore ha un grafico semplice, ma ha bisogno di comprendere come e perché è successo qualcosa, è necessario che ci sia una funzionalità che consenta agli utenti di vedere i dati granulari. Le organizzazioni devono essere in grado di effettuare facilmente il drill down delle informazioni per identificare problemi, punti di forza e anomalie.

Funzionalità di intelligenza artificiale (IA)

Non ha senso avere dei dati se un'organizzazione non è in grado di creare miglioramenti operativi sulla base di essi. Per abilitare questa funzione, è necessario che ci sia una funzionalità di IA, in modo che i dati si trasformino in approfondimenti e previsioni. Una volta raccolti i dati, l'aggiunta di funzionalità di IA è facile, data la natura segmentata dei microservizi.

Potenziali soluzioni per il reporting dei microservizi

Ci sono diverse opzioni disponibili per consentire il reporting in un'architettura di microservizi. La soluzione corretta per un'organizzazione dipende da molti fattori diversi e la risposta non è unica.

Il primo passo è trovare i servizi corretti. Il modello di microservizi implica che ogni compito richieda un'applicazione o un programma diverso. Questi microservizi si affiancano a tutte le altre applicazioni e programmi. È probabile che un'azienda abbia bisogno di un servizio che estragga o riceva i dati, di un altro con funzioni di reportistica e di un altro ancora con funzionalità di IA.

Una volta installati questi servizi, si tratta di estrarre i dati dagli altri microservizi e di creare i report richiesti.

Connessioni dirette al database

Il servizio di reporting si connette direttamente con gli altri microservizi, recupera le relative informazioni dai loro database e le convoglia in un data warehouse. L'operazione è semplice, ma implica che qualsiasi modifica allo schema del database richieda un'ulteriore modifica anche al servizio di reporting. Inoltre, rompe il contesto delimitato che è così importante nell'architettura dei microservizi.

Modello HTTP pull del servizio di aggregazione

Questo servizio utilizza le API per connettersi con i relativi microservizi. Richiama le informazioni necessarie e le convoglia attraverso il data warehouse e lo strumento di reporting. Tuttavia, questo metodo è soggetto a prestazioni lente e a errori di timeout 504. Ogni servizio aggiuntivo con cui deve parlare aggiunge ulteriore carico al sistema, aggregando più fonti di dati che creano enormi problemi di prestazioni.

Ancora una volta, poiché si tratta di un modello pull, viola il contesto delimitato.

Estrazione in batch e database dedicato

Con questa strategia, un comando è eseguito secondo un programma e le informazioni sono estratte in batch da tutti i relativi database dei microservizi. Questi dati sono poi aggiornati in blocco nel database del reporting. Tuttavia, come nel caso della connessione diretta al database, qualsiasi modifica dello schema potrebbe interrompere l'intero lavoro batch. Ogni volta che lo schema cambia, anche le funzioni batch devono essere aggiornate.

L'altro problema è che, in quanto modello pull, è contrario al contesto delimitato e potrebbe non tradursi in un report tempestivo. Se la richiesta di estrazione è vincolata al momento in cui il carico è più leggero, alle 2:00 del mattino, si tratta di un solo aggiornamento al giorno.

Database dedicato con invio asincrono degli eventi

Questo è più complicato, ma produce risultati migliori e non viola il modello delimitato. Un microservizio con processore di eventi riceve aggiornamenti quando qualcosa in un altro servizio si aggiorna o si modifica. L'app, invece di ricevere informazioni, invia le notifiche degli eventi. Ciò significa che un servizio di acquisizione dei dati viene notificato di qualsiasi aggiornamento rilevante e il database è aggiornato. Da lì, un servizio di reporting può eseguire i report secondo le necessità.

I vantaggi di questo metodo di reportistica includono:

• Preservare i principi dell'architettura delimitata dei microservizi. Il servizio di reporting non sta ascoltando le app o estraendo informazioni.
• Garantire che i report risultanti siano aggiornati, perché il servizio di reporting è informato di eventi o di aggiornamenti delle informazioni.
• Filtrare le informazioni non necessarie nell'ambito del servizio di acquisizione dati.
• Aggregare i dati in una forma che il servizio di reporting può utilizzare attraverso il servizio di acquisizione dati.
• Fornire una reportistica asincrona per evitare carichi di elaborazione pesanti, time out o accoppiamento temporale.

Come risolvere i dati in conflitto

Poiché potrebbero esserci letteralmente migliaia di database, è quasi certo che ci saranno doppioni di dati oppure dati errati o difettosi. Risolvere questo problema è importante per creare report accurati. Ci sono un paio di soluzioni diverse per questa sfida.

Un servizio per aggiornare i database

Se c'è un servizio intermediario che riconosce quando un'informazione viene aggiornata, può inviare l'aggiornamento agli altri servizi. Per esempio, se l'indirizzo fisico di un cliente è stato aggiornato, questa informazione viene trasferita a tutte le istanze delle informazioni di quel cliente. Ciò può essere incredibilmente complesso e richiedere una maggiore larghezza di banda nel sistema, oltre ad essere antipattern.

Scegliere una singola fonte di verità per ogni tipo di dati

Poiché ogni servizio di questa architettura esegue un singolo compito, non è necessario che il database sia completo. L'ufficio amministrazione deve conoscere l'indirizzo postale, mentre il reparto vendite ha bisogno dell'indirizzo fisico per spedire il prodotto. Nominare un servizio che sia la singola fonte di verità per quel dato.

Il reporting dei microservizi richiede una pianificazione

Il reporting dei microservizi pone diverse sfide e non si tratta dell'architettura più semplice in termini di reportistica. Anche il mantenimento di dati coerenti richiede una maggiore pianificazione e riflessione rispetto ad altre architetture tradizionali. Tuttavia, è possibile eseguire i report pur rispettando i principi dei servizi delimitati.

Se un'organizzazione vuole adottare un framework di microservizi, il team IT deve effettuare una pianificazione e un lavoro di base considerevoli per garantire che la coerenza e l'accuratezza dei dati vengano prima di tutto, seguite da un'attenzione al percorso dei dati inviati dai servizi di origine ad altri servizi che creano data lake come fonte di dati, per poi elaborare tali dati per farli diventare i report richiesti.

Considerando gli enormi vantaggi che il modello dei microservizi è in grado di offrire a un'organizzazione, vale la pena affrontare la complessità aggiuntiva del reporting. Tutte le sfide possono essere superate con la riflessione e la pianificazione.

Risorse correlate