DevOps: vantaggi, svantaggi e best practice della metodologia

Nata per velocizzare lo sviluppo di applicazioni, la metodologia DevOps viene ora anche applicata ai progetti di business, anche in modalità data-driven. Cosa bisogna sapere per cominciare.

Entro i prossimi 5 anni, le figure specializzate più richieste saranno i Data Analyst, seguiti dagli sviluppatori web/mobile e dagli esperti di soluzioni DevOps, dichiara la Hayes Salary Guide 2018.

Secondo Service Now, in Italia a fine 2017 la percentuale di aziende già impegnate in qualche forma di DevOps era di ben il 94%, ma solo il19% dei casi mostrava impatto sui processi.

Seguire queste ultime tendenze è quindi interessante sia per l’azienda, sia per il professionista.

Leggi anche: Le nuove professioni dell’IT tra Data Analyst e DevOps (Hayes Salary Guide)

Come lo stesso nome suggerisce, l’approccio DevOps fonde insieme sviluppo (development) ed operazioni (operations). Nasce per rendere più veloce e controllabile lo sviluppo e l’implementazione di applicazioni in azienda enfatizzando la collaborazione tra team di sviluppo e quello delle operations, ossia i sistemisti che gestiranno le applicazioni dopo il loro rilascio.

Nel modello tradizionale di sviluppo questa collaborazione è limitata: chi sviluppa recepisce all’inizio dello sviluppo i requisiti che il software deve soddisfare, scrive il codice, produce l’applicazione e la testa in un ambiente controllato per poi rilasciarla. Molti problemi che impediscano all’applicazione di operare come previsto si evidenziano solo a questo punto, dopo il rilascio. Anche molti di quelli che potevano essere evidenziati direttamente dal team delle operations, perché legati al funzionamento quotidiano dell’infrastruttura IT e dei suoi componenti.

L’approccio DevOps mira a eliminare questa distonia introducendo una più stretta collaborazione fra i due team e si è affermato con la diffusione dello sviluppo per le applicazioni cloud e delle architetture software-defined. In entrambi questi ambiti il software ha una concezione modulare e strettamente integrata con i processi aziendali, perché questi sono sempre più digitalizzati: uno scenario che rende poco efficace il modello dello sviluppo monolitico e sequenziale.

Poiché il metodo enfatizza l’individuazione di responsabilità e la collaborazione dentro il team e tra team, questo approccio sta trovandosi a suo agio anche in altri ambiti che necessitino di processi digitali, veloci e controllabili, come per esempio il cloud computing, la agile methodology e i big data.

DevOps e cloud

Il cloud raddoppia l’effetto DevOps nel software delivery, almeno secondo una ricerca Freeform Dynamics sviluppata all’inizio del 2017. Nel settore specifico il cloud in azienda (senza DevOps) migliorerebbe i tempi del 67%, l’approccio DevOps (senza cloud) dell’81%, mentre la combinazione tra cloud e DevOps di ben il 129%.

DevOps e metodologia Agile

La caduta del muro tra development e operations ha rimappato molte altre funzioni, trovando nuove contiguità che prima della fusione DevOps non erano così immediate. L’approccio DevOps amplifica l’effetto dell’agilità. Senza questa integrazione, infatti, i vantaggi nello sviluppo della applicazioni verrebbero rallentati se non vanificati. L’adozione delle metodologie Agile e DevOps deve essere guidata dal business, integrata tra i vari team e iterativa. Deve inoltre sfruttare le analisi e i loop di feedback appropriati, per consentire miglioramenti rapidi e costanti, a ogni livello.

Leggi anche: Far bene l’Agile fa bene al business, anche in Italia

Gli svantaggi dell’approccio DevOps

La filosofia DevOps potrebbe, in alcuni casi, avere delle controindicazioni. Dovendo coinvolgere più persone, aumentano la complicazioni nell’organizzazione e gestione delle riunioni del team.

Siccome il team è composto da persone eterogenee, ciascuna specialista in campi diversi (sviluppo, gestione sistemi, erogazione dei servizi, responsabili di business…), potrebbe essere necessario impiegare del tempo per spiegare concetti che per alcuni sono scontati, o che in ogni caso non interessano tutti i componenti del gruppo. Per questo, è importante ridurre il team al minimo e organizzare semmai riunioni in cui partecipano solo le persone direttamente coinvolte nella particolare fase del progetto trattata nel meeting.

La flessibilità nel poter cambiare direzione al progetto in ogni momento, può inoltre portare all’aggiunta in corso di così tante modifiche da costringere a rimandare le scadenze dei rilasci. È quindi opportuno tenere traccia dell’avanzamento dei lavori e definire milestone inderogabili, fissando a un certo punto le specifiche di ogni fase. A questo scopo, e per valutare l’andamento di un processo, esistono quattro metriche principali.

Leggi anche: Tendenze nei DevOps

DevOps, Big Data e Data Driven DevOps

La più recente integrazione al modello DevOps è orientata alla data scienze e ad un pesante approccio data driven. Questo recente sviluppo, spesso citato come Data-Driven DevOps, merita un minimo di dettaglio.

Si parte dalla Data-Driven Culture, nella quale ogni figura coinvolta nel processo decisionale basa ogni sua scelta su dati certi e metriche condivise da tutti. Le culture basate sui dati quantificano il maggior numero possibile di obiettivi e lavorano in tempo reale.

L’approccio DevOps, che favorisce una rete di collaborazione più piatta all’interno di team interfunzionali piuttosto che modelli gerarchici tradizionali, è particolarmente adatto a questo approccio. I team di sviluppo e quelli operativi lavorano fuori dal silo delle informazioni e condividono costantemente la conoscenza. La natura flessibile e collaborativa di DevOps amplifica la collaborazione tra le aree di competenza.

Leggi anche: Come il DevOps migliora i risultati di business

In una cultura basata sui dati, ciascuna decisione viene presa analizzando i dati relativi. Ciò significa che i decisori hanno accesso ai dati e agli strumenti per analizzarli. Un’infrastruttura DevOps offre al team un flusso di lavoro collaborativo per agire in base ai dati, aumentando l’efficienza e l’agilità.

Quattro metriche per i DevOps

Ci vuole tempo per costruire una cultura basata sui dati, soprattutto in un sistema che parte da segnalazioni o “incidenti”. La risposta agli incidenti è essenziale per l’attività ed è un ambiente ideale per il miglioramento del team. La scelta delle metriche di mappatura dell’IT sul business è essenziale. Le metriche principali sono quattro:

1. Conteggio degli incidenti grezzi
   È necessario conoscere il numero di incidenti che ogni squadra incontra nel periodo di riferimento. Si monitorano i picchi, che indicano un punto debole nel team o l’inadeguatezza degli strumenti.
2. (Mean) Time to Acknowledgment
   Il Time to Acknowledgment è un buon modo per misurare le prestazioni individuali.
3. Escalation
   La gestione degli incidenti comprende il modo in cui vengono allertate le singole persone o funzioni e i ritardi tra gli allarmi stessi. Per la maggior parte delle organizzazioni che utilizzano software di gestione delle operazioni IT, le escalation sono rare. Sono un segno di inadeguatezza: o un rispondente non è stato in grado di arrivare a un incidente in tempo, o che non sono disponibili strumenti o competenze per gestirlo.
4. (Mean) time to resolution
   Gli incidenti aumentano con l’attività e diminuiscono con l’organizzazione. Dopotutto, la metrica di base più importante per l’azienda è il tempo medio di soluzione dell’incidente. È anche uno dei numeri più complessi da maneggiare.

Evitare lo stallo decisionale nel DevOps

Un problema basilare dell’analisi dei dati è il rumore di fondo. La sua presenza rende pesante separare le informazioni utili da quelle inutili. Un team DevOps guidato dai dati riduce il rumore e la conseguente fatica di analisi grazie a metriche orientate al business.

Partire dai dati ha un immediato vantaggio nello sviluppo del processo: l’individuazione delle responsabilità dirette e collegate è chiara e immediata e il manager sa a quale team o professionista rivolgersi per ogni punto carente.

È qui che s’innesta l’importanza della cultura DevOps applicata ai dati. Grazie a metriche chiare, infatti, la risposta agli incidenti è sotto controllo e viene migliorata continuamente.

È necessario collegare le metriche con specifici obiettivi aziendali, incoraggiando i team ad agire, prendere decisioni data-driven e agire in base a tali decisioni.

Le metriche sono un mezzo per capire come migliorare i processi futuri, non per assegnare responsabilità di imprecisioni passate. Un’analisi errata porterebbe alla paralisi del processo decisionale: bisogna evitare il tipico stallo che proviene dal tentativo di lavorare con troppi dati in un momento troppo anticipato.

Leggi anche: DevOps: 10 consigli per lanciare al meglio un progetto

Strumenti e framework per DevOps

L’approccio DevOps richiede ovviamente l’uso di sistemi di sviluppo e gestione delle applicazioni più integrate rispetto al passato e che abbiano anche recepito i modelli di Agile Development e Continuous Delivery, ambiti strettamente collegati ma distinti tra loro.

Alcuni software vendor hanno presentato piattaforme per DevOps che cercano di raccogliere tutte le funzioni necessarie. Tra le aziende impegnate in DevOps troviamo RedHat, CA Technologies, HPE e molte altre. E’ anche possibile adottare il modello DevOps facendo cooperare moduli distinti e più mirati, molti dei quali vengono dal mondo open source.

DevOps e sicurezza

Molti professionisti di cybersicurezza di aziende che fanno uso di DevOps nel cloud pubblico ritengono che si stia privilegiando la velocità a scapito della sicurezza. Per il 72% la velocità dell’adozione del cloud pubblico sta infatti introducendo prevenibili rischi di sicurezza negli aggiornamenti software.

C’è infatti preoccupazione tra i professionisti su come riuscire a far viaggiare la sicurezza alla stessa velocità e frequenza di aggiornamento di app e servizi DevOps nel cloud pubblico. Abbiamo pubblicato qui i risultati di una ricerca su DevOps e Cybersecurity.