DevOps
Da dove deriva il termine DevOps
In informatica, il termine DevOps deriva dalla contrazione inglese delle parole development ed operations.
Il termine venne utilizzato per la prima volta nel 2008 da Patrick Deboisè ed Andrew Shafer[1] ma entrò davvero in uso comune dopo una presentazione al Velocity Conference del 2009 nella quale John Allspaw and Paul Hammond presentarono "+10 Deploy Software al Giorno: il Metodo di Cooperazione di Dev ed Ops a Flickr"
Che cos'è DevOps, in breve
Devops è un metodo di rilascio e gestione, sia del software che dell'infrastruttura (Hardware o Cloud) su cui il software viene sviluppato e messo in produzione.
La filosofia DevOps si basa sul concetto delle '3 Ways' e sul creare una cultura di collaborazione e sperimentazione fra tutte le persone coinvolte nel rilascio di un determinato progetto software, sia personale tecnico che non tecnico.
La Cultura DevOps nasce come risposta ad un comune problema che si incontra in aziende medio-grandi che operano nell'IT, dove sviluppatori e amministratori di sistemi si trovano spesso con obiettivi contrapposti.
Gli uni, con lo scopo di inserire più funzionalità possibili nella prossima release; utilizzeranno sino all'ultimo giorno disponibile per scrivere codice.
Gli altri, con lo scopo di mantenere l'uptime dei sistemi, che si ritroveranno con codice non propriamente testato e probabilmente contenente incongruenze da far funzionare in produzione.
Descrizione
Premesso che tutte le aziende nell'IT possono trarre beneficio da una Cultura DevOps, passiamo a definire i 3 principi di base a cui si fa spesso riferimento in letteratura DevOps come 'The Three Ways[2]'.
The First Way: si parla di un flusso di lavoro che fa in un senso unico, in piccoli moduli e sopratutto nella maniera più automatizzata possibile; il flusso di codice va dallo Sviluppatore, al Tester, all'amministratore di sistema sino alla messa in produzione.
L'obiettivo è quello di ridurre il lavoro in moduli molto piccoli dove se un errore viene introdotto sia facilmente rintracciabile e non venga passato alle unità di lavoro seguenti.
The Second Way: si parla del concetto di feedback; questo flusso va in un senso unico opposto alla First Way, doce tutti gli errori e risultati dei test che vengono fatti sul codice, a qualsiasi livello prima di arrivare in produzione, vengono immediatamente segnalati all'unità di lavoro precedente. Questo evita che gli errori, anche se minimi, vengano passati verso l'ambiente di produzione, e corretti, seguendo un modello agile di sviluppo.
The Third Way: Si parla di creare una cultura che faccia della sperimentazione e del rischio calcolato uno stile di lavoro. Uno stile di lavoro da cui si impara dai propri errori e si creano automazioni atte a riconoscere e riparare queste mancanze del software utilizzando sistemi terzi. Si parla, in pratica di fare esattamente il contrario di quello che succede in un normale modello di sviluppo software e gestione sistemi: si cercano i punti deboli dell'infrastruttura o del codice e si causa il problema con l'obiettivo di trovare una soluzione che potrà gestire l'errore (gestire e non eliminare).
Utilizzando il sistema delle 3 Ways in azienda è possibile, con un ragionevole investimento iniziale, creare un team capace di rilasciare con cadenza regolare ed automatizzare i processi in maniera tale che, anche se una versione contenente errori arrivasse in produzione, avremmo sui nostri sistemi un processo talmente standardizzato e testato che il roll-back ad una precedente versione, o il rilascio di una hot-fix non rappresenterebbe una preoccupazione.
DevOps fa inoltre uso di tools software molto avanzati e di concetti innovativi che permettono alle aziende di salvaguardare tutta la produzione ed installazione del software, documentando i processi mentre si scrive il codice per i processi stessi, rendendo tutte le operazioni che costituiscono una piattaforma software, ripetibili.
Concetti come Monitoring, Automazione delle installazioni, Configuration Management, Installazione ed aggiornamento software vengono portati all'estremo, proprio per testare i limiti stessi delle piattaforme con l'obiettivo di migliorarle.
Impatto sui rilasci applicativi
In aziende che non fanno uso della Cultura DevOps i rilasci applicativi (releases) sono eventi ad alto impatto e rischio che coinvolgono più gruppi di lavoro; con la metodologia DevOps questo rischio si riduce, vediamo perché:
- Numero ridotto di modifiche
- L'adozione del modello agile o modello incrementale, in contrasto con il tradizionale modello a cascata(Waterfall), comporta minori modifiche, anche se più frequenti, dove l'impatto di un errore può essere misurato a priori e facilmente individuato.
- Coordinamento nei rilasci
- Non ci sono più "Silos" fra gli addetti ai lavori, tutti sono al corrente dei rilasci, dei task dei colleghi e dello stato della release software
- Automazione
- Una estrema automazione assicura la facile ripetibilità dei rilasci e riduce gli errori umani nelle operazioni, dalle più triviali alle più complesse.
Coordinatore del Rilascio (Release manager or release Team)
Si tratta di un ruolo relativamente nuovo nelle aziende IT, il cui compito è di coordinare i rilasci in più ambienti di sviluppo partendo dagli ambienti di test per arrivare agli ambienti di produzione.
Questo ruolo è diventato necessario in aziende dove la Cultura DevOps ha attecchito particolarmente bene e dove i rilasci sono stati automatizzati a punto che ci si trova nella necessità di "rallentare" e registrare i rilasci software così che in presenza di un errore si possa tornare indietro e correggere il rilascio software colpevole del malfunzionamento (Si parla ancora delle 3 Ways)
I falsi miti legati alla Cultura DevOps[2]
Il metodo DevOps rimpiazza il metodo Agile: decisamente no, è infatti il contrario, DevOps cerca di rendere Agile cose che non lo sono mai state come infrastruttura, tests e sicurezza delle piattaforme.
DevOps significa NoOps: a volte c'è chi pensa che DevOps possa significare l'eliminazione del reparto sistemi o test lasciando tutto sulle spalle degli sviluppatori. In pratica DevOps si basa sulle automazioni e le automazioni devono essere testate al pari del codice e del codice dell'infrastruttura.
Dedicando il solito numero di sviluppatori a task che prima erano di competenza di Testers e Sys-Admins si sta di fatto sovraccaricando la risorsa Sviluppatore che non sarà in grado di produrre codice alla stessa velocità .
DevOps è solo per chi lavora con Software Open Source: anche se agli albori questa tecnica di rilascio e gestione era praticata principalmente in ambito Linux ed Open Source Software, oggi si contano molteplici organizzazioni che sviluppano in .Net, Sap o Cobol fra gli utilizzatiori di questa metodologia.
Si pensi che ad oggi ci sono applicazioni di DevOps per apparati di rete e SMART appliances.
DevOps è solo per gestire le infrastrutture Cloud(IaaC): anche se in effetti uno dei vantaggi principali dei Tolls Devops è quello di trasformare l'infrastruttura in codice per poi lavorarla con i sistemi Agile, gli obiettivi del metodo vanno ben oltre quello che resta un semplice tool.
DevOps è solo per Start-Up ed aziende software: un grande numero di compagnie ad oggi fa uso di DevOps come strumento principale di release e gestione software, partendo dai pionieri Google, Amazon, Twitter ad arrivare a molte Banche ed Assicurazioni a livello internazionale, per poi parlare di NETFLIX che ha fatto del metodo DevOps il cavallo di battaglia che ha portato la compagnia al successo.
Note
- ^ (EN) 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr, su slideshare.net. URL consultato il 15 luglio 2015.
- ^ a b Kim, Gene. Phoenix project., Summary of The phoenix project by Gene Kim, Kevin Behr, and George Spafford : a novel about IT, DevOps, and helping your business win., ISBN 9781945251078, OCLC 957127022. URL consultato il 15 novembre 2019.