Oggi aumentano le aspettative nei confronti degli operatori IT in termini di integrazione nei servizi di funzioni di monitoraggio di rete funzionali, efficaci e trasparenti.
Finché l’innovazione nell’ambito dei servizi IT continuerà ad avanzare al ritmo attuale, il settore dovrà dimostrare di essere più flessibile e aperto al cambiamento.
Negli ultimi anni i cambiamenti che si sono verificati nel mondo delle operation sono stati particolarmente significativi. Secondo Chiara Ornigotti, Senior Sales Manager South Europe di Paessler sono tre.
Virtualizzazione, container e serverless
Il primo è stato la virtualizzazione, che ha significato il passaggio da un singolo server sul quale girava un certo numero di applicazioni a un singolo server su cui girano molti “server” virtualizzati. Questi server venivano “astratti” virtualizzando l’hardware sottostante del server stesso. Il vantaggio si traduceva in un workload più bilanciato nell’infrastruttura e la capacità di consolidare diverse macchine virtuali su un numero minore di server fisici, con conseguenti minori investimenti iniziali per l’operatore IT.
Il secondo cambiamento si è avuto con l’avvento e l’adozione su larga scala dei container. Questi sono simili alla virtualizzazione, tranne per il fatto che portano l’astrazione a un nuovo livello.
Non si limitano a virtualizzare l’hardware e a ospitare sistemi operativi completi su ogni macchina virtuale, ma girano al di sopra del sistema operativo di un host o di un nodo. Ciò significa che su un singolo sistema operativo possono girare molteplici workload.
Inoltre, non è necessario che questi nodi siano su un server fisico. Possono anche essere macchine virtuali. L’idea è che ci sia un “server” capace di gestire molti contenitori con la capacità di bilanciare il carico tra i suddetti server. Il risultato? Una maggiore efficienza.
L’ultima trasformazione è rappresentata dal FaaS (Function as a Service). Viene anche definito serverless in quanto elimina la necessità di delegare qualcuno all’interno dell’organizzazione alla manutenzione del server.
Ciò non significa che non vi sia da qualche parte un server che gestisce questa funzione: semplicemente c’è qualcun altro che controlla che tutto funzioni a dovere.
Questo sistema permette agli sviluppatori di software di scrivere solamente la loro logica di business e caricarla, quindi, su un servizio FaaS con un fornitore di cloud pubblico come AWS. Il funzionamento dei server che gestiscono i contenitori, che a loro volta controllano la logica di business, è completamente separato, il che lascia alle aziende il compito di concentrarsi esclusivamente sullo sviluppo dell’applicazione.
In conseguenza della separazione dall’hardware e della natura effimera delle moderne applicazioni, nel giro di pochi anni non dovremmo più preoccuparci dell’infrastruttura. Più allontaniamo noi stessi e le nostre applicazioni dal puro metallo, meno dovremo curarcene.
Senza controllo?
Ma se un operatore gestisce un’applicazione totalmente serverless su un cloud pubblico, osserva Ornigotti, non solo tale operatore non deve occuparsi dell’infrastruttura, ma non gli è nemmeno possibile monitorarla.
Non c’è modo cioè, di accedere alle metriche della rete o dei server che stanno dietro i contenitori su cui gira il codice.
Nel caso dei contenitori, i team DevOps, che gestiscono applicazioni in contenitori all’interno di cluster Kubernetes ben costruiti o di un cluster gestito che gira nel cloud, non hanno motivo di preoccuparsi dell’hardware che ospita il tutto.
Sempre di più la gestione di cluster K8 o simili sarà esternalizzata nel cloud e né l’hardware sotto questi cluster gestiti né i cluster stessi rappresenteranno un vero problema per l’azienda che usa l’applicazione.
La ragione per cui l’outsourcing di queste attività ha senso, per Ornigotti, è che con l’astrazione del computing l’hardware e la sua gestione diventano una commodity.
Il futuro del monitoraggio
A questo punto la domanda da porsi è quale sarà il futuro del monitoraggio? Per rispondere a questo quesito è necessario concentrarsi sull’applicazione stessa più che sui workload che girano sull’infrastruttura.
L’osservabilità per Ornigotti è un buon modo di considerare la questione. Comprende metriche, log e tracce estratte direttamente dal workload o dall’applicazione.
Con questi dati è possibile, dunque, dedurre lo stato attuale di un sistema dai suoi output e costruire un contesto per comprenderne lo stato.
L’elevata cardinalità nei dati di monitoraggio corrispondeva di solito a dei non-pattern, qualcosa che tutti cercavano di evitare, ma per rendere un’applicazione osservabile, la memorizzazione di dati altamente cardinali è necessaria per capire a fondo un problema quando si verifica.
Una volta che l’operatore ha identificato il problema nell’applicazione potrà osservare i log del data flow per stabilire se la rete sta, ad esempio, tentando di scrivere su un particolare nodo, causando un timeout di scrittura.
In definitiva, per Ornigotti, il modo in cui gli operatori monitoreranno le reti sarà sempre più lontano dal bare metal Meno faremo affidamento sull’infrastruttura, più il settore IT sarà aperto al cambiamento.
