Che diavolo è DevOps?

Una breve storia del tempo

Per capire DevOps, dobbiamo viaggiare indietro nel tempo fino alla vecchiaia quando non c'erano altro che programmatori.

Come ci insegna il Tao:

I programmatori del passato erano misteriosi e profondi. Non riusciamo a sondare i loro pensieri, quindi tutto ciò che facciamo è descrivere il loro aspetto:

• Consapevole, come una volpe che attraversa l'acqua
• Vigile, come un generale sul campo di battaglia
• Gentile, come una hostess che saluta i suoi ospiti
• Semplici, come blocchi di legno non scolpiti
• Opache, come pozze nere in caverne buie

Il Programmatore ha dato vita al linguaggio macchina. Il linguaggio macchina ha dato vita all'assemblatore. L'assemblatore ha dato vita al compilatore. Ora ci sono migliaia di lingue. Ogni lingua ha il suo scopo, per quanto umile. Ogni lingua esprime lo Yin e lo Yang del software. Ogni lingua ha il suo posto all'interno del software.

A quel tempo, gli uffici di sviluppo software erano per lo più chiamati laboratori e i programmatori erano scienziati. Per creare una buona applicazione, i programmatori dovevano comprendere appieno il problema che l'applicazione stava risolvendo. Dovevano sapere dove verrà utilizzata l'applicazione e che tipo di sistema la eseguirà. In sostanza, i programmatori sapevano tutto sulla loro applicazione, dalle specifiche, allo sviluppo, all'implementazione e al supporto.

E poi la natura umana ha preso il sopravvento e abbiamo iniziato a chiedere di più. Più velocità, più funzionalità, più utenti, più tutto.

Essendo creature modeste, umili e pacifiche, i programmatori avevano pochissime possibilità di sopravvivere a tale esplosione di utenti bisognosi che chiedevano sempre di più. La migliore possibilità di prevalere era iniziare a evolversi in direzioni diverse e creare caste. Ben presto, i programmatori si estinsero come antenati di nuove razze chiamate sviluppatori, ingegneri del software, amministratori di rete, sviluppatori di database, sviluppatori web, architetti di sistema, ingegneri del controllo qualità e molti altri. Evolversi rapidamente e adattarsi alle sfide del mondo esterno è diventato parte del loro DNA. La nuova casta potrebbe evolversi nel giro di poche settimane. Gli sviluppatori Web sono diventati sviluppatori back-end, sviluppatori front-end, sviluppatori PHP, sviluppatori Ruby, sviluppatori Angular... tutto stava andando all'inferno.

Ben presto si dimenticarono tutti che provenivano dallo stesso padre, un Programmatore. Uno scienziato semplice e pacifico che voleva solo rendere il mondo un posto migliore. Hanno iniziato a litigare tra loro, affermando che ognuno di loro è un vero discendente di "The Programmer" e che il loro sangue è più puro degli altri.

Con il passare del tempo, hanno ridotto al minimo la loro interazione e si sono parlati solo quando era davvero necessario. Hanno smesso di celebrare il successo dei loro lontani familiari e alla fine hanno persino smesso di inviare una cartolina ogni tanto.

Se solo cercassero i loro sentimenti, scoprirebbero che la scintilla del Programmatore era nei loro cuori, in attesa di brillare e portare la pace nella galassia.

Nella loro corsa egoistica ed egocentrica alla conquista del mondo, i discendenti dei programmatori hanno dimenticato lo scopo stesso del loro lavoro: risolvere i problemi per i loro clienti. I clienti hanno iniziato a sentire il dolore di tale comportamento poiché i progetti sono stati ritardati, troppo costosi o addirittura falliti.

Di tanto in tanto, una stella luminosa brillava e qualcuno traeva ispirazione per cercare di fare pace tra i discendenti. Hanno inventato Waterfall. Questa è stata un'idea brillante, poiché ha utilizzato il fatto che diversi gruppi di sviluppatori comunicavano solo quando necessario. Quando un gruppo ha terminato la sua parte del lavoro, ha comunicato con il gruppo successivo di inviare il lavoro attraverso il processo e non ha mai guardato indietro.

Questo ha funzionato per un po', ma come al solito, gli umani (clienti) volevano ancora di più. Volevano partecipare in modo più attivo all'intero processo di creazione del software, esprimere la loro opinione più spesso e chiedere modifiche anche quando era troppo tardi.

I progetti software sono diventati così inclini al fallimento da essere accettati come standard del settore. Le statistiche hanno mostrato che oltre il 50% dei progetti stava fallendo e sembra che non ci fosse nulla da fare al riguardo (ZDNet, CNet)

Ogni generazione ha avuto alcune persone di mentalità aperta che sapevano che tutti questi gruppi di sviluppatori devono trovare un modo per lavorare insieme, comunicare ed essere flessibili per garantire che i loro clienti riceveranno la migliore soluzione possibile. Di questi tentativi si hanno tracce già nel 1957, ad opera dei colleghi del grande John Von Neumann. Tuttavia abbiamo dovuto aspettare fino all'inizio del 2001 per iniziare la rivoluzione, quando una sporca dozzina ha creato un Manifesto Agile.

Il Manifesto Agile si basa su dodici principi:

1. Soddisfazione del cliente grazie alla consegna anticipata e continua di software di valore
2. Benvenuto ai requisiti che cambiano, anche in fase di sviluppo avanzata
3. Il software funzionante viene consegnato frequentemente (settimane anziché mesi)
4. Cooperazione stretta e quotidiana tra uomini d'affari e sviluppatori
5. I progetti sono costruiti attorno a persone motivate, di cui ci si dovrebbe fidare
6. La conversazione faccia a faccia è la migliore forma di comunicazione (co-location)
7. Il software funzionante è la principale misura del progresso
8. Sviluppo sostenibile, in grado di mantenere un ritmo costante
9. Attenzione continua all'eccellenza tecnica e al buon design
10. La semplicità, l'arte di massimizzare la quantità di lavoro non svolto, è essenziale
11. Squadre auto-organizzate
12. Adattamento regolare alle mutevoli circostanze

Il manifesto agile è stato il primo grande passo per portare la pace nella Galassia e ristabilire l'equilibrio nella Forza. Per la prima volta da molto tempo, il collegamento di tutte le parti interessate nel processo di sviluppo del software si è basato sul modo culturale e “umano”, oltre che su quello procedurale e meccanizzato. Le persone hanno iniziato a parlarsi, incontrarsi regolarmente e scambiarsi idee e commenti tutto il tempo. Si sono resi conto di avere molto più in comune di quanto pensassero e i clienti sono diventati parte del team, non solo un fattore esterno che avrebbe dovuto inviare i soldi e non fare domande.

C'erano ancora alcuni ostacoli da superare, ma il futuro sembrava più luminoso che mai. Essere agili significa essere aperti e disposti ad adattarsi ai continui cambiamenti. Tuttavia, con tutti i troppi cambiamenti, è difficile rimanere concentrati sull'obiettivo finale e sulla consegna. Ed è così che ha preso vita il Lean Software Development.

Affamati dall'LSD (gioco di parole) e rischiando di essere esiliati ed emarginati, alcuni dei discendenti cercarono soluzioni al di fuori della loro casta e dell'industria del software. Hanno trovato la salvezza nelle opere di una grande casa automobilistica. Toyota Production System è stato sorprendente nella sua semplicità ed era così ovvio che la sua produzione snella può essere facilmente applicata allo sviluppo del software.

Ci sono 7 principi di lean:

1. Eliminate lo spreco
2. Qualità costruttiva
3. Crea conoscenza (Amplifica l'apprendimento)
4. Differisci l'impegno (decidi il più tardi possibile)
5. Consegna il più velocemente possibile
6. Rispetta le persone (potenzia il team)
7. Ottimizza il Tutto

Aggiunti oltre all'Agile, i principi Lean hanno supportato la mentalità e l'attenzione sul fare le cose giuste, pur essendo flessibili durante l'intero processo.

Una volta che Agile e Lean sono stati adottati dai team di sviluppo software, è bastato un altro passo per applicare l'intera serie di principi all'IT nel suo insieme, il che ci ha finalmente portato a DevOps!

Entra in DevOps - Autostrada a tre corsie

La visione della vecchia scuola dei team di sviluppo software includeva analisti aziendali, architetti di sistema, sviluppatori front-end, sviluppatori back-end, tester e così via. L'ottimizzazione del processo di sviluppo del software, inclusi i principi agili e snelli, si è concentrata principalmente su questi. Una volta che l'applicazione era "pronta per la produzione", è stata inviata alle "Operazioni", inclusi ingegneri di sistema, ingegneri di rilascio, DBA, ingegneri di rete, professionisti della sicurezza, ecc. La rimozione del grande muro tra Dev e Ops è la principale forza trainante di DevOps .

DevOps è il risultato dell'implementazione di principi lean nell'intero flusso di valore IT. Il flusso di valore IT estende lo sviluppo alla produzione, combinando tutti i "parenti lontani" che discendevano dal programmatore originale.

La migliore spiegazione delle soluzioni DevOps è data da Gene Kim, e se non avete letto The Phoenix Project vi consiglio di prendervi un po' di tempo e farlo.

Non dovresti assumere un ingegnere DevOps e DevOps non dovrebbe essere un nuovo dipartimento nel tuo IT. DevOps è una cultura, una mentalità e fa parte dell'IT nel suo insieme. Non ci sono strumenti che renderanno il tuo IT un'organizzazione DevOps e nessun livello di automazione consentirà ai tuoi team di offrire il massimo valore ai tuoi clienti.

DevOps viene solitamente indicato come metodo a tre vie, ma li vedo come tre corsie della stessa autostrada. Inizi nella corsia uno, poi acceleri e passi alla corsia due, e alla fine stai sfrecciando nella terza corsia.

• Corsia uno - Le prestazioni del sistema nel suo insieme sono il punto focale principale ed è enfatizzato rispetto alle prestazioni di ogni singolo elemento del sistema

• Corsia due: assicurati che ci sia un ciclo di feedback costante inviato a monte e non ignorato

• Corsia tre - Coltiva gli esperimenti, il miglioramento costante e fallisci velocemente

Corsia uno - Al passo con la velocità

Comprendere l'importanza dell'intero sistema e assegnare correttamente le priorità agli elementi di lavoro è la prima cosa che un'organizzazione IT deve imparare quando adotta i principi DevOps. Nessuno nel flusso di valore IT è autorizzato a creare un collo di bottiglia e ridurre il flusso di lavoro.

Garantire un flusso di lavoro senza interruzioni è l'obiettivo finale per tutti coloro che sono coinvolti nel processo. Indipendentemente dal ruolo che una persona o una squadra ha, è imperativo che cerchino di raggiungere una profonda comprensione del sistema. L'adozione di questo modo di pensare ha un impatto diretto sulla qualità, poiché i difetti non vengono mai inviati a valle perché causerebbero colli di bottiglia.

Fare in modo che il lavoro non si fermi non è abbastanza. Un'organizzazione produttiva dovrebbe sempre cercare di aumentare il flusso. Esistono numerose metodologie per aumentare il flusso. Puoi trovare una soluzione in Theory Of Constraints, Six Sigma, Lean o Toyota Production System. Sentiti libero di scegliere uno di questi, crearne uno tuo o combinarli.

I principi DevOps non si preoccupano del team a cui appartieni, se sei un architetto di sistema, un DBA, un QA o un amministratore di rete. Le stesse regole valgono per tutti e tutti sono tenuti a seguire due semplici principi:

• Mantieni il flusso del sistema ininterrotto
• Aumenta e ottimizza il flusso di lavoro in ogni momento

Corsia due - Preparati

Il flusso ininterrotto del sistema è unidirezionale e si prevede che passi dallo sviluppo alle operazioni. In un mondo ideale, ciò significa che il software viene creato rapidamente con alta qualità, distribuito alla produzione e fornendo valore ai clienti.

Tuttavia, DevOps non è un'utopia e se fosse possibile la consegna unidirezionale il metodo a cascata sarebbe sufficiente. Valutare i risultati finali e comunicare il flusso è molto importante per garantire la qualità. Il primo canale di comunicazione "a monte" che deve essere implementato è Ops to Dev.

Dare il cinque a te stesso è facile, ma chiedere un feedback e dare un feedback è il modo per vedere il quadro reale. È imperativo che ogni piccolo passo a valle sia seguito da una conferma istantanea a monte.

Non importa come stabilisci il ciclo di feedback. Puoi invitare gli sviluppatori a partecipare alle riunioni del team di supporto o coinvolgere l'amministratore di rete per la pianificazione settimanale dello sprint. Finché il tuo feedback è a posto e i commenti vengono raccolti e gestiti, la tua organizzazione sta accelerando l'autostrada DevOps.

Corsia tre - Warp 10

La corsia preferenziale DevOps non è per i deboli di mente. Per entrare nella corsia preferenziale di DevOps, la tua organizzazione deve essere sufficientemente matura. Si tratta di correre rischi e imparare dal fallimento, sperimentare continuamente e accettare che la ripetizione e la pratica sono il prerequisito per la padronanza. Abbastanza spesso sentirai il termine Kata, e questo è per una ragione. L'allenamento continuo e la ripetizione portano alla padronanza perché trasformano le mosse complesse in una routine.

Ma prima di iniziare a combinare le mosse, è imperativo padroneggiare ogni singolo passaggio.

“Ciò che è appropriato per il Maestro non è appropriato per il novizio. Devi capire il Tao prima di trascendere la struttura”.

DevOps Third Way/Fast Lane include l'allocazione del tempo per la sperimentazione continua su base giornaliera, la premiazione costante del team per l'assunzione di rischi e l'introduzione di errori nel sistema per aumentare la resilienza.

Per garantire che la tua organizzazione non implodi durante l'implementazione di questo tipo di misure, devi creare frequenti cicli di feedback tra tutti i team, assicurandoti che tutti i colli di bottiglia siano chiari e che il flusso del sistema sia ininterrotto.

L'implementazione di queste misure rende la tua organizzazione sempre all'erta e in grado di rispondere alle sfide in modo rapido ed efficace.

Riepilogo - Elenco di controllo dell'organizzazione DevOps

Ecco un elenco di controllo che puoi utilizzare per convalidare il modo in cui DevOps ha abilitato la tua organizzazione IT. Per favore, sentiti libero di commentare l'articolo e aggiungere i tuoi punti.

• Non c'è muro tra il team di sviluppo e il team operativo. Entrambi fanno parte dello stesso processo
• Il lavoro che viene inviato da un team all'altro è sempre verificato e di alta qualità
• Non c'è "accumulo" di lavoro e tutti i colli di bottiglia vengono gestiti
• Il team di sviluppo non utilizza il tempo delle operazioni per le sue attività, perché la distribuzione e la manutenzione fanno parte della stessa fascia oraria
• Il team di sviluppo non fornisce il codice per la distribuzione alle 17:00 del venerdì, lasciando le operazioni per ripulire il proprio lavoro durante il fine settimana
• Gli ambienti di sviluppo sono standardizzati e le operazioni possono riprodurli facilmente e portarli in produzione
• Il team di sviluppo può fornire nuove versioni quando lo ritiene appropriato e le operazioni possono distribuirle facilmente nella produzione
• Ci sono chiare linee di comunicazione tra tutte le squadre
• Tutti i membri del team hanno tempo per sperimentare e lavorare al miglioramento del sistema
• I difetti vengono introdotti (o simulati) e gestiti regolarmente nel sistema. Le lezioni apprese da ogni esperimento sono documentate e condivise con tutte le persone interessate. La gestione degli incidenti è una routine e per lo più gestita in modo noto

Conclusione

L'utilizzo di moderni strumenti DevOps come Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS, ecc. non significa che stai applicando i principi DevOps. DevOps è un modo di pensare. Facciamo tutti parte dello stesso processo, condividiamo lo stesso tempo e forniamo valore insieme. Ogni persona che prende parte al processo di consegna del software può accelerare o rallentare l'intero sistema. Un bug creato durante lo sviluppo può far cadere il sistema, così come la configurazione errata del firewall.

Tutte le persone fanno parte di DevOps e, una volta che la tua organizzazione lo comprende, gli strumenti e lo stack tecnologico che ti aiuteranno a gestirlo appariranno magicamente.