Nel corso degli anni, il legame tra le performance applicative e la competitività aziendale si è rafforzato, e questo ha reso sempre più centrale il concetto di observability dei sistemi software. Poter conoscere in tempo reale lo stato di salute delle applicazioni e identificare rapidamente eventuali anomalie è diventato essenziale per mantenere (e, possibilmente, rafforzare) il proprio vantaggio competitivo.
La complessità delle architetture IT moderne, caratterizzate da una forte eterogeneità di servizi e tecnologie, rende molto difficile tracciare l’intero percorso di singole operazioni, che oggi sono il frutto dell’interazione di decine di componenti distinti, dislocati in ambienti diversi e talvolta gestiti da team indipendenti. Ciò ha introdotto notevoli sfide in chiave di osservabilità ed è qui che tecnologie come OpenTelemetry scendono in campo.
OpenTelemetry e la differenza con le piattaforme di Observability
Nel contesto appena descritto, OpenTelemetry (OTel) nasce per fornire uno standard unico per la raccolta e la gestione dei dati di observability e in particolare di tracce, log e metriche. Secondo la definizione ufficiale, si tratta infatti di un “framework e toolkit di Observability progettato per creare e gestire dati di telemetria come tracce, metriche e log. OpenTelemetry è un framework vendor (e tool) agnostico, e può essere così utilizzato con un’ampia gamma di backend di observability, compresi strumenti open source come Jaeger e Prometheus, nonché offerte commerciali”.
Stante la definizione, l’obiettivo primario di OpenTelemetry è dunque creare uno standard unico per l’instrumentazione del codice sorgente e per la gestione del flusso di dati dall’applicazione fino all’observability backend. OTel permette agli sviluppatori di generare, processare e trasmettere i dati di telemetria in un formato uniforme, indipendentemente dalla piattaforma incaricata dello storage, dell’analisi e della visualizzazione delle informazioni. Questo approccio garantisce che l’acquisizione e la gestione dei dati rimangano costanti anche se l’azienda decide di cambiare la soluzione di backend, semplificando la gestione dell’infrastruttura di osservabilità e riducendone i costi.
Nato nel 2019 dalla fusione di OpenTracing e OpenCensus, OpenTelemetry è uno dei principali progetti della Cloud Native Computing Foundation (CNCF) ed è già diventato il principale standard di telemetria dell’universo Cloud Native grazie al contributo di oltre 1.100 aziende e di più di 9.000 sviluppatori. Tra i principali contributor, il primo posto è occupato da Splunk con il 27%, seguito da Microsoft con il 17%. Date le molteplici affinità, molti ritengono che OpenTelemetry ricopra nell’observability una posizione analoga a quella di Kubernetes nell’orchestrazione dei container.
Come funziona OpenTelemetry e i suoi principali componenti
OpenTelemetry è formalmente un framework, un insieme completo di API, SDK, librerie, componenti di auto-instrumentazione del codice per diversi linguaggi (una delle caratteristiche più interessanti per gli sviluppatori) ma anche di convenzioni semantiche in continua evoluzione e di tool verticali come OpenTelemetry Operator for Kubernetes e OpenTelemetry Helm Charts.
Il toolkit ha l’obiettivo di fornire agli sviluppatori tutto ciò di cui necessitano per definire ciò che va misurato, per acquisire e organizzare le informazioni e per esportarle in modo standardizzato a uno dei molti backend possibili. L’ecosistema OpenTelemetry, oltre a fornire API e SDK per l’implementazione dell’architettura in svariati linguaggi, include inoltre un componente molto interessante: OTel Collector. Si tratta di un proxy vendor-agnostic che funge da ponte tra i componenti funzionali dell’applicazione (tipicamente, i microservizi) e i backend di observability. Il suo ruolo non si limita alla ricezione dei dati telemetrici, ma esegue anche operazioni di elaborazione, trasformazione e filtraggio prima dell’inoltro al backend prescelto per l’analisi e la visualizzazione realtime.
Prevenire il lock-in non è l’unico beneficio
Non c’è dubbio che lavorare con uno standard aperto, che deriva inoltre dalla “fusione” di due tecnologie solide e apprezzate, determini dei vantaggi consistenti per le aziende.
La prevenzione del vendor lock-in è un plus significativo, sia pur non l’unico. In un panorama tecnologico in rapidissima evoluzione, la possibilità di scegliere e di cambiare liberamente la soluzione di backend senza dover apportare modifiche all’instrumentazione del codice e ai metodi di acquisizione e di gestione dei dati è infatti determinante. Questa flessibilità permette alle aziende di adattarsi rapidamente alle nuove esigenze del mercato e alle innovazioni tecnologiche, garantendo al contempo la protezione degli investimenti tecnologici.
Inoltre, standardizzare i processi di raccolta e di gestione dei dati consente ai team IT di lavorare in modo più efficiente, e soprattutto di non dover utilizzare soluzioni diverse per applicazioni diverse, problema piuttosto frequente e sentito in passato. Inoltre, la compatibilità con tutti i principali strumenti di monitoraggio e di analisi facilita l’integrazione con infrastrutture già in uso, riducendo i costi e i tempi di implementazione.
Nel panorama attuale, infatti, è impensabile per un vendor non supportare OpenTelemetry e sperare nel successo commerciale. Non sorprende, dunque, che tra i contributor del progetto ci sia Splunk in prima posizione, ma anche Dynatrace al quarto posto, New Relic al settimo, Hound Technology all’ottavo e Datadog al tredicesimo. In sostanza, tutti i Leader del Magic Quadrant di Gartner nell’ambito dell’Application Performance Monitoring and Observability supportano attivamente il progetto, ritenendolo essenziale per il presente e il futuro delle applicazioni su cui si fonda il business di milioni di aziende.
