La complessità delle architetture IT è cresciuta esponenzialmente negli ultimi anni, e mantenere la visibilità e il controllo è diventata una sfida in piena regola. Il concetto stesso di observability è nato in risposta a questa esigenza, ovvero come soluzione integrata per tracciare e analizzare in tempo reale il comportamento delle applicazioni e delle infrastrutture IT che supportano il business di ogni azienda.
L’observability e le sue sfide
Fin dagli esordi, l’observability si è posta come paradigma innovativo in grado di rivoluzionare la metodologia dominante: il monitoring. Come ben sintetizzato da Splunk, uno dei volti noti del settore, l’observability “non si limita al monitoraggio di ogni singolo componente del sistema, ma si concentra sui risultati del sistema nel suo complesso“. Fare observability non significa dunque dotarsi di strumenti più evoluti di quelli usati da anni, ma modernizzare l’approccio (mindset) alla visibilità dei sistemi IT.
L’adozione di architetture software moderne, volte a sfruttare i vantaggi di microservizi, cloud e container (scalabilità, agilità, resilienza), spinge le aziende a compiere questo salto culturale. Lo conferma la crescita costante del mercato, stimata dagli analisti in un CAGR dell’11,7%, con un valore che dovrebbe raggiungere i 4,1 miliardi di dollari entro il 2028.
Questo passaggio comporta però alcune sfide significative, tra cui:
- L’adozione di metodologie di sviluppo orientate all’observability (Observability-Driven Development, ODD), che integrano la capacità di fornire dati rilevanti fin dalle prime fasi del ciclo di sviluppo.
- La revisione – o meglio l’instrumentazione – del codice sorgente per consentire all’applicazione di raccogliere dati dettagliati sul suo funzionamento e sulle sue prestazioni; in questo contesto, OpenTelemetry può essere di aiuto.
- La scelta della piattaforma di observability più adatta alle proprie esigenze. Il termine piattaforma è appropriato, poiché il perimetro è molto ampio: strumenti di monitoring dell’infrastruttura, di Application Performance Monitoring (APM), di Real User Monitoring (RUM) e di Synthetic Monitoring rientrano tutti nel macrocosmo dell’observability e non coprono in ogni caso il 100% di questa area.
Come scegliere l’observability stack
Uno dei nodi nell’adozione di questo approccio è la proliferazione di tool disponibili. La vastità e l’eterogeneità di queste soluzioni rischiano infatti di creare frammentazione, dove team IT differenti possono usare strumenti diversi, generando silos di informazioni, complessità e ostacolando una visione unificata dei sistemi.
Quindi, come scegliere i tool giusti? Ovviamente, non è possibile fare una valutazione puntuale per i singoli prodotti, ma è più funzionale fornire una serie di strumenti a supporto delle attività di selection di ogni azienda.
Le prime considerazioni, piuttosto scontate, riguardano la semplicità di implementazione e gestione, il livello di automazione e la facilità di integrazione con i framework, le piattaforme, i tool e le tecnologie già in uso nell’ecosistema applicativo aziendale. Successivamente, è fondamentale valutare la capacità di personalizzazione delle dashboard, la scalabilità della piattaforma e la facilità di accesso ai dati di telemetria, ai report, ai KPI e ad altre informazioni.
Open Source o piattaforma commerciale?
Nel mondo dell’observability esistono molte soluzioni open source, ma anche numerosi prodotti commerciali. Tra le soluzioni open source più apprezzate spiccano Prometheus, OpsVerse, Grafana ed Elastic. Questi ultimi due sono anche presenti nel Magic Quadrant di Gartner, nel segmento dei visionari. L’accesso al codice sorgente di queste soluzioni offre flessibilità e capacità di personalizzazione, rispondendo a esigenze specifiche di visibilità, come il troubleshooting.
Per quanto concerne Elastic, Gartner ne elogia (appunto) la flessibilità, la capacità di ottenere insight da dataset estremamente complessi ed eterogenei e i diversi modelli di deployment (on prem e cloud), ma avverte anche che la versione cloud presenta una certa complessità nella previsione dei costi, poiché la tariffazione è basata sull’utilizzo delle risorse di elaborazione. Inoltre, l’uso di Elastic può comportare una curva di apprendimento piuttosto ripida. Nonostante ciò, l’adozione di strumenti open source rimane vantaggiosa per le organizzazioni che necessitano di soluzioni scalabili, solide e fortemente personalizzabili, grazie anche all’attività delle community di riferimento.
I prodotti commerciali, alcuni dei quali di assoluto riferimento nel settore, come Splunk e Dynatrace (entrambi leader nel Magic Quadrant Gartner) possono contare sulla massima completezza funzionale, un fattore chiave nel ridurre la complessità del mondo dell’observability, nonché un elemento di forza nel confronto con l’open source.
A tal proposito, gli analisti di Gartner affermano che “Splunk Observability Cloud copre molte aree di observability, tra cui infrastruttura, APM, DEM, AIOps e incident intelligence”. Le soluzioni commerciali supportano tecnologie innovative (AI), integrano l’automazione ovunque possibile, sono relativamente semplici da implementare, offrono un supporto tecnico avanzato, alti livelli di conformità e sicurezza nonché interfacce utente intuitive e accattivanti.
Attenzione al vendor lock in
Il vendor lock-in esiste anche nell’ambito dell’observability e riguarda (ovviamente) le soluzioni commerciali, che logicamente si possono basare su tecnologie o funzionalità proprietarie. Nel segmento dell’observability, un fattore chiave è il supporto per il progetto open source OpenTelemetry, che fornisce tool, API e SDK per la raccolta di dati di telemetria, con l’obiettivo di standardizzare il modo in cui le informazioni vengono raccolte e trasmesse dai sistemi di origine alle piattaforme di observability. Buona parte delle soluzioni commerciali supportano OpenTelemetry, riducendo il peso del vendor lock-in: tra queste, segnaliamo Splunk, ma anche New Relic e Datadog, altri due volti noti nel segmento dell’observability ed entrambi leader del Magic Quadrant Gartner.
Per quanto concerne il primo, gli analisti ne elogiano l’ampia copertura funzionale, il modello di pricing a consumo basato su due elementi (volume di dati e numero di utenti), la customer experience ottimale e la Telemetry Data Platform sviluppata su tecnologia database proprietaria (NRDB). Secondo gli analisti, l’architettura del database permette di ottimizzare la gestione e l’analisi dei dati di observability, garantendo tempi di risposta rapidi e buona scalabilità.
Per quanto riguarda Datadog, gli analisti apprezzano l’ampio portafoglio di prodotti, che raggiunge soluzioni molto verticali come il SIEM, e la sua capacità di monitorare efficacemente le architetture cloud-native. Emerge qualche preoccupazione circa la complessità del modello di business, dato che ogni prodotto ha una struttura di pricing indipendente; inoltre, pare piuttosto complesso tenere sotto controllo i costi, per quanto a onor del vero l’azienda abbia implementato tool dedicati.
L’importanza della data residency
Osservati dall’alto, i tool di observability acquisiscono dati da vari componenti di un sistema software, li analizzano, separano il segnale dal rumore, eliminano le anomalie, creano il contesto e forniscono insight all’utente finale. Dove i dati vengono memorizzati è di primaria importanza per la compliance con la normativa geografica e quella di settore.
Scegliere tool enterprise con capacità di definizione degli algoritmi di crittografia e delle aree di storage dei dati è ottimale in chiave di gestione del rischio. In ogni caso, questo è un tema che non si può sottovalutare nella scelta della soluzione, e del partner, per l’observability.
