Introduzione

DevOps è un termine entrato da qualche anno nel gergo informatico delle metodologie di sviluppo IT. Con questa serie si esploreranno tutte le sue sfaccettature, dalla componente metodologica al modo in cui questa si applichi nella realtà e con quali strumenti. Il primo articolo darà una panoramica ciò che DevOps è e cercherà di spiegare le ragioni per cui sta diventando il punto di partenza per avere un software robusto, sia dal punto di vista del business che dal punto di vista più propriamente informatico.

Che cosa è DevOps

DevOps è un termine coniato nel 2009. Nei paragrafi seguenti racconteremo brevemente come è nato e quali sono le sue principali caratteristiche.

Un po’ di storia

Patrick Debois, un consulente IT Belga, organizzò un evento dove si parlava del lavoro che lui stesso stava svolgendo da circa due anni. Nel 2007 gli era stato commissionata una consulenza in cui, in qualità di Test Manager, doveva seguire un progetto per la migrazione massiva di un Datacenter governativo. Per il ruolo che ricopriva nel progetto, si trovava in mezzo ai due dipartimenti più importanti che stavano collaborando al progetto: Sviluppo (Development) ed Esercibilità (Operations).

Debois analizzò i comportamenti dei due dipartimenti intuendo fin da subito che essi divergevano sia per interessi sia per obiettivi, essendo entrambi governati come entità a sé stanti. Nel 2008, a una conferenza Agile, Patrick propose un intervento dal nome “Agile Infrastructure” che suscitò subito molto interesse nella comunità agile. Nel 2009 lui stesso organizzò un evento chiamato DevOpsDays. L’evento ebbe molto successo radunando personaggi di tutta la catena produttiva del software e del mondo IT in generale, da Business Manager a sistemisti a grandi esponenti del mondo agile. Finito l’evento, se ne continuò ancora a parlare, e come hashtag fu scelta la parola DevOps la quale diede origine ad un movimento che sta rivoluzionando la maniera di concepire il processo di sviluppo software.

Integrare i dipartimenti in un’ottica Lean/Agile

In termini generali, DevOps è un approccio basato nei principi Lean e Agile, nel quale business, cantieri di sviluppo, operations e controllo qualità collaborano in maniera continuativa in modo da rendere il business più reattivo alle nuove richieste di mercato, riducendo al contempo il tempo di reazione rispetto ai feedback ricevuti da parte dei clienti.

Al giorno d’oggi le applicazioni Enterprise sono molto diverse tra loro, integrano molteplici tecnologie e sistemi informativi diversi e devono essere fruibili a dispositivi innovativi e sempre diversi. L’approccio DevOps è in grado di amalgamare questa complessità, in modo da rendere fluide tra di loro tutte le componenti di un servizio/prodotto Enterprise a partire dal business e finendo al dato grezzo.

La cosa non risulta semplice visto che gli attori in gioco sono tanti ed eterogenei. Per questo motivo DevOps, prima di tutto, deve partire da una partecipazione massiccia da parte dei protagonisti di tutta la catena produttiva, dal business e marketing fino a chi gestisce l’infrastruttura informatica dell’applicativo.

DevOps applica i principi Lean e Agile in tutta la catena di produzione del software. Riesce a velocizzare il rilascio di un prodotto/servizio dalla sua idea iniziale alla messa in produzione. Il tutto basato sui feedback dei clienti e sul miglioramento possibile proprio grazie a quei feedback.

Stabilità vs. nuove funzionalità

Pensiamo un attimo a una struttura enterprise che produce e mette in esercizio un sistema pensato per gestire situazioni di una certa complessità e in cui magari si devono trattare dati molto “delicati” come nel caso dell’infrastruttura informatica di una banca. Lo scenario tipico è quello di scegliere la stabilità a fronte di introdurre nuove funzionalità.

In un’ambiente “tradizionale”, infatti, c’è sempre molta tensione quando il business vuole introdurre nuove funzionalità perchè questo, il più delle volte, introduce anche instabilità nel software già esistente. In DevOps ogni singolo team è responsabile del rilascio di nuove funzionalità che siano stabili per principio. Questo è applicabile grazie a sistemi di versionamento, test automatici, continuous integration, continuous delivery e altre tecniche che verranno illustrate in questa serie di articoli.

Un’altra considerazione sempre vera è che i cambiamenti, per definizione, inducono ad un investimento, di cui il business deve tener conto. Per questo motivo è il business che guida il cambiamento. Con DevOps, bisogna capire il vero valore di business che effettivamente può possedere un nuovo bisogno.

Lo scopo di un’impresa è quello di creare nuovi prodotti/servizi per risolvere un problema e per avere dunque nuove opportunità di business. Per riuscire in questo, le aziende si affidano a progetti software che molte volte si prendono il rischio di un nuovo sviluppo software e della sua messa in produzione. Le due cose, messe in relazione, possono raggiungere una criticità molto elevata per la riuscita di un progetto software, facendo perdere le opportunità che il business aveva individuato e l’investimento nel progetto stesso.

Da System of Record a System of Engagement

Negli anni si è assistito a una graduale migrazione da System of Record a System of Engagement.

System of Record (SOR) [1] è una terminologia usata per definire quelle applicazioni tradizionali che gestiscono una grande quantità di dati e/o transazioni. Si tratta di applicazioni progettate per essere stabili e affidabili. Non hanno bisogno di grandi cambiamenti, che possono essere assorbiti in sole due major release all’anno.

Con il System of Engagement [2], invece, il focus viene spostato sui clienti che possono avere diretto accesso alle risorse software in modo da interagire direttamente con il business. Si capisce pertanto come le applicazioni debbano essere sempre reattive ai bisogni del mercato.

Come funziona DevOps?

Diciamo subito che nell’interpretazione di DevOps esistono anche delle sfumature diverse a seconda degli autori. C’è però un sostanziale accordo su alcuni fondamenti, che sono condivisi dalla maggior parte della comunità.

In tal senso, i principi cardine di DevOps sono quattro: shift left, automatizzazione dei rilasci, supervisione e validazione della qualità del software, sistema di feedback ciclici. Vediamoli di seguito in maggior dettaglio.

Shift left

DevOps esprime il principio di shift left. Questo concetto avvicina il dipartimento di operations allo sviluppo vero e proprio del software. Si traduce permettendo ai team di sviluppo e quelli che si occupano della qualità del software di sviluppare e testare il software in ambienti il più simile possibile all’ambiente di produzione. In questo modo, già molto prima del suo rilascio vero e proprio, tutti possono rendersi conto di come l’applicativo reagisce e si comporta.

La prima esposizione dell’applicativo all’ambiente di produzione deve avvenire il più presto possibile nel ciclo di vita del software in modo da indirizzare le due sfide maggiori. La prima è quella di permettere all’applicativo di essere testato in un ambiente che è molto vicino a quello di produzione. La seconda è quella di permettere al processo di rilascio in produzione di essere testato e validato fin dall’inizio.

Dal punto di vista di operations, questo principio ha un grande valore in quanto si può vedere molto presto come l’ambiente di produzione reagirà all’applicazione avendo la possibilità di tarare in maniera ottimale l’infrastruttura sottostante.

Automatizzazione dei rilasci

DevOps permette a sviluppo e operations di implementare processi Agili e Lean, dallo sviluppo alla messa in produzione, rendendo l’automazione essenziale in tutto il processo produttivo in modo da avere fasi iterabili, frequenti, ripetibili e affidabili.

Supervisione e validazione della qualità del software

Grazie a tool e sonde software, una parte dell’IT è concentrata al monitoring delle applicazioni software in modo da catturare metriche di comportamento in tempo reale. DevOps spinge su questo principio portandolo all’inizio del ciclo di vita del software in modo da avere test automatici che monitorano sia aspetti funzionali che non funzionali dell’applicazione. Così facendo, il monitoring frequente, già dai primi stadi dello sviluppo, mette a nudo eventuali problemi sia di infrastruttura che di sviluppo in modo da essere corretti nelle successive iterazioni.

Sistema di feedback ciclici

DevOps istruisce e permette alle aziende di reagire con facilità ai cambiamenti del mondo esterno, fatto per lo più dagli utilizzatori del software e dai driver del mercato. Nel ciclo di rilascio del software questo è permesso solo se si hanno continui feedback e questi ultimi sono integrati il più rapidamente possibile nei rilasci successivi. Per questo tipo di approccio le aziende si devono organizzare in canali di comunicazione molto stretti ed efficaci nei quali i clienti finali devono avere accesso e fare da attori principali.

DevOps: quando diventa necessario?

DevOps diventa necessario in quelle realtà aziendali che soffrono di alcune pecche che si evidenziano sempre di più quando si affronta un cambiamento in termini di funzionalità o anche semplicemente di infrastruttura.

Uno dei primi sintomi, ad esempio, è quando si percepisce che l’applicazione, intesa come l’insieme del software e dell’infrastruttura sottostante, è fragile. Se la maggior parte delle volte che cambia qualcosa, questa azione, anche se piccola, comporta uno sforzo in termini di attività non pianificate, per tamponare eventuali regressioni… allora siamo di fronte a un IT fragile. Ancora più frustrante è quando arrivano all’IT delle chiamate dal business, denunciando un fermo in produzione che ha portato a una grossa perdita in termini economici.

Un’altra bandierina si alza quando il business comincia a pressare per il rilascio di una funzionalità ritenuta molto importante in termini di resa economica, o quando ci si deve adattare a leggi, normative o policy, scenario quest’ultimo molto tipico nel settore finance.

Quando si innesca questo meccanismo, le fabbriche di sviluppo cominciano a ragionare per “data” e quindi per “tempo”. Questo costringe gli sviluppatori a fare si che che il software “semplicemente” funzioni tralasciando altri aspetti non meno importanti come qualità del codice, scalabilità, affidabilità, aspetti legati alla sicurezza e così via.

Il tutto viene gestito, nei casi più fortunati, in liste enormi di debiti tecnici. Se questi debiti cominciano ad accumularsi, si avverte un rallentamento, nel tempo, di tutto il processo di sviluppo. Questo meccanismo mette in contrasto le persone di sviluppo con quelle di operations che cominciano a in entrare stallo riaddossandosi l’un l’altro le responsabilità del debito tecnico accumulato.

È in questi casi che DevOps diventa di fondamentale importanza. DevOps permette molteplici rilasci al giorno in produzione, non tralasciando nessuno degli aspetti legati alla qualità, in senso lato, del software.

Conclusioni

In questa prima parte abbiamo visto i principi alla base di DevOps in modo da interpretarlo come una metodologia che porta ad avere un software sempre reattivo ai requisiti di business abbassando i rischi di messa in produzione dello stesso a fronte di cambiamenti anche radicali.

Nei prossimi articoli, verranno trattati argomenti più implementativi introducendo le varie fasi in cui DevOps fa la differenza in termini di metodologia di sviluppo.