DevOps, DataOps, GitOps, FinOps, NoOps… facciamo chiarezza!

Fondandosi su metodologie quali Agile e Lean, indirizzate a rompere la rigidità dei modelli di sviluppo software classici, primo fra tutti quello a cascata (waterfall), il paradigma di sviluppo DevOps emerge nel 2009, con l’obiettivo di migliorare ulteriormente la velocità e l’efficienza dei processi alla base del ciclo di creazione dei prodotti e servizi software di un’organizzazione.

Nato dalla contrazione di “development” e “operations”, DevOps punta a instaurare interazione e collaborazione cross-funzionale tra due mondi che sono complementari, ma le cui esigenze, tradizionalmente, sono spesso conflittuali: i team di sviluppo (Dev) che progettano applicazioni e servizi, e i team di gestione dell’IT (Ops) che indicano i requisiti per gli stessi e li devono amministrare in produzione.

Cicli di rilascio accelerati con DevOps

Come nuovo approccio culturale allo sviluppo software, DevOps ha l’obiettivo di consentire cicli di rilascio più rapidi e frequenti, grazie alla collaborazione tra team di sviluppatori e team delle operation. Inoltre, con DevOps si raggiunge una miglior comunicazione e collaborazione tra le persone, e un livello di automazione nella pipeline di sviluppo e test del codice che permettono di realizzare il paradigma di “continuous delivery” (CD) e gestione completa del ciclo di vita del software.

Perché adottare il DevOps

DevOps, anche nella definizione fornita dalla società di ricerche Gartner, enfatizza il valore delle persone e rappresenta un cambiamento nella cultura IT, che si focalizza sulla rapida fornitura dei servizi IT, adottando le pratiche Agile e Lean nel contesto di un approccio orientato al sistema. Le implementazioni DevOps utilizzano tecnologia e soprattutto strumenti di automazione capaci di sfruttare un’infrastruttura sempre più programmabile e dinamica dal punto di vista del ciclo di vita del software.

Fattori che portano all’uso di DevOps

Fino agli inizi degli anni Duemila, le applicazioni vengono progettate in maniera monolitica e, di conseguenza, i rilasci del software si eseguono per grandi blocchi di codice, distribuiti con ridotta frequenza. Così, per rispondere alle aspettative degli utenti e alla crescente pressione competitiva, si comincia ad adottare i metodi Agile e Lean, che accorciano i cicli di rilascio.

Ma ciò che davvero cambia le regole del gioco è l’avvento di cloud computing, modello SaaS (Software as a Service) e microservizi: questi fattori permettono, infatti, di fornire le applicazioni come servizi web e, più tardi, come insiemi di microservizi, che accelerano ulteriormente i cicli di rilascio, spezzando la complessità di gestione delle applicazioni monolitiche.

Tuttavia, un prodotto sviluppato velocemente non può restare a lungo in attesa che le IT operation ne convalidino il funzionamento anche in ambiente di produzione: è proprio per indirizzare queste sfide, e allineare i ritmi di lavoro dei due reparti, che nasce DevOps.

Non solo DevOps: DataOps, l’approccio che velocizza l’analisi dei dati

Nel mondo il volume di dati, in continua crescita, è ormai nell’ordine degli zettabyte (ZB). Tale trend, nel 2014, porta a introdurre l’approccio DataOps, che applica la filosofia di DevOps in questo ambito, per incrementare la velocità, l’affidabilità e la qualità di analisi dei dati. Come DevOps, anche DataOps pone l’accento sulla collaborazione, in questo caso tra i team di analisi dei dati (data scientist, analisti, ingegneri) e le IT operation.

Altro aspetto chiave di DataOps è l’utilizzo di tool di automazione per monitorare e controllare la pipeline analitica lungo tutto il suo ciclo di vita. Gli strumenti per applicare il metodo DataOps non appartengono necessariamente a una specifica categoria: come indica Gartner, molti di quelli già esistenti nell’organizzazione possono essere adeguati per ottenere i livelli di automazione richiesti da DataOps.

In ogni caso, può trattarsi di tutti quei tool che servono a identificare, raccogliere, formattare, purificare, elaborare, aggregare, visualizzare ed analizzare i dati.

GitOps: una “single source of truth” per le applicazioni cloud native

Quando si tratta di sviluppare e implementare applicazioni complesse e multicomponente, come le moderne app, basate su microservizi e distribuite in molteplici ambienti IT, il modello GitOps aiuta a non perdere il filo grazie all’applicazione del controllo versione per tutti i parametri e le impostazioni di configurazione.

GitOps è infatti la contrazione di Git, nome della nota e diffusa tecnologia open source di controllo versione, e Ops (IT Operations), e, in sostanza, è un modello che consente ai team di stabilire una SSoT (Single Source of Truth), ossia un’unica fonte di verità, quindi di codice sorgente e istruzioni di implementazione, per le operazioni di gestione e revisione delle risorse e dei requisiti di configurazione di ciascuna applicazione.

Come già accennato, i team nei reparti IT si affidano a parametri e file di configurazione per impostare il funzionamento delle diverse applicazioni; e un errore di configurazione può compromettere il deployment e l’operatività in produzione delle stesse, perché ogni nuova versione dei componenti software richiede solitamente nuovi parametri e file di configurazione.

Negli ambienti IT in cui si applicano modelli di continuo sviluppo e fornitura del software occorre mantenere tutte queste operazioni sincronizzate con il rilascio in produzione; il modello GitOps consente di farlo, tracciando tutti i cambiamenti e le modifiche, e mantenendo, appunto, un repository, e un controllo versione centralizzato, per il codice sorgente applicativo, le istruzioni di configurazione, i parametri operativi.

FinOps: come governare i costi del cloud

Sempre più aziende stanno migrando sul cloud le loro infrastrutture IT per modernizzare i sistemi legacy. Il cloud offre grandi vantaggi in termini di performance, disponibilità, scalabilità e osservabilità, ma richiede una notevole quantità di strumenti e servizi per garantire questi benefici. Questo si traduce in una maggiore complessità, che può portare al rischio di perdere di vista i costi generati da tutte le tecnologie cloud utilizzate all’interno dell’azienda.

Per evitare che i costi del cloud vadano fuori controllo e ne vanifichino i benefici, è nata la pratica del FinOps. FinOps, dalla contrazione di Financial (Fin) e Operations (Ops), prevede la creazione di un team centralizzato cross‑funzionale incaricato di raccogliere informazioni sugli strumenti cloud utilizzati in tutta l’azienda, individuare le aree da migliorare e applicare le ottimizzazioni.

NoOps: l’evoluzione finale del DevOps

Nella definizione della società di ricerche Forrester, che ha coniato il termine, il modello NoOps (No Operations) risponde all’obiettivo di automatizzare completamente il deployment, il monitoraggio e la gestione delle applicazioni e dell’infrastruttura sulla quale esse girano. Nel modello DevOps gli sviluppatori devono rilasciare il software con maggiore frequenza, mentre i professionisti delle operation si preoccupano di proteggere la stabilità dell’infrastruttura. Con NoOps l’idea è eliminare la necessità di interazione tra sviluppatori e operation, grazie all’automazione. In effetti, i due fattori chiave dietro l’emergere di NoOps sono la crescente automazione dell’IT e il cloud computing.

In particolare, nel modello NoOps, utilizzando le tecnologie IaaS (Infrastructure as a Service) e PaaS (Platform as a Service), gli sviluppatori sono in grado di accedere a tutte le risorse e gli strumenti necessari per implementare con affidabilità le applicazioni, senza richiedere l’intervento del team operation.

Tuttavia, va detto che il paradigma NoOps non è adottabile in tutti i casi, e la sua validità è circoscrivibile alle applicazioni integrabili con facilità nelle soluzioni PaaS esistenti, e non a quelle legacy monolitiche, che richiederebbero aggiornamenti, o pesanti interventi di riscrittura del codice, per operare in modalità PaaS.

In conclusione, si può affermare che NoOps non ha l’obiettivo di sostituire il modello DevOps, ma piuttosto di porsi come un metodo complementare, con il potenziale, laddove è possibile, di migliorare e accelerare ulteriormente il processo di implementazione applicativa.