Ciao, Habr! Ti presento la traduzione di un articolo autore Steve Mezak.
A seconda del proprio punto di vista, il DevOps celebrerà quest'anno il suo nono o decimo anniversario. Nel 2016, il rapporto di RightScale sullo stato del cloud evidenziava che il 70% delle piccole e medie imprese adotta pratiche DevOps. Ogni indicatore di questa valutazione è aumentato da allora. Mentre il DevOps si prepara a entrare nel suo secondo decennio, sarebbe interessante passeggiare tra i meandri del passato e tornare alle radici del DevOps — e anche all'origine di questo nome.
Prima del 2007: La catena di eventi ideale
Fino al 2007, una serie di circostanze ha infine dato origine a quello che oggi conosciamo come DevOps.
Lean Manufacturing si era già affermato come una prassi migliore. Conosciuto anche come sistema produttivo Toyota, il lean manufacturing mira a ottimizzare i processi nel reparto produttivo. (A proposito, la gestione Toyota era inizialmente ispirata dai metodi originali della catena di montaggio presentati dalla Ford Motor Company). Miglioramento continuo — è un mantra per la produzione snella. Nella pratica, vengono continuamente valutati i seguenti percorsi:
- Mantenere il livello delle scorte di materie prime e prodotti finiti al minimo. La produzione snella implica una quantità minima di scorte di materie prime per la produzione di beni e un numero ridotto di prodotti già realizzati, in attesa di distribuzione o spedizione.
- Minimizzare la coda degli ordini. È ideale se gli ordini ricevuti passano immediatamente allo stato di completati. Una metrica chiave della produzione snella sarà sempre il tempo tra la ricezione dell'ordine e la consegna.
- Massimizzare l'efficienza del processo produttivo. La riorganizzazione dei processi e un'automazione migliorata si uniscono con l'obiettivo di produrre beni il più rapidamente possibile. Ogni stazione di produzione lungo il percorso (taglio, saldatura, assemblaggio, collaudo, ecc.) viene valutata per inefficienze.
Nel mondo IT, i metodi tradizionali della cascata nello sviluppo software hanno già ceduto il passo a metodi iterativi rapidi come Agile. La velocità era un grido di battaglia, anche se la qualità a volte ne risentiva nella corsa allo sviluppo e al deployment. Allo stesso modo, il cloud computing, in particolare Infrastructure-as-a-Service (IaaS) e Platform-as-a-Service (PaaS) si sono affermati come soluzioni mature nei processi e nell'infrastruttura IT.
Infine, di recente sono emersi strumenti per Continuous Integration. (CI). L'idea degli strumenti CI è stata concepita e presentata da Grady Booch nel 1991 con il suo Metodo Booch.
2007-2008: Il belga deluso
Il consulente belga, project manager e praticante Agile Patrick Debois ha accettato un incarico dal Ministero del governo belga per assistere nella migrazione dei data center. In particolare, si è occupato della certificazione e della verifica della preparazione. Le responsabilità richiedevano di coordinare le azioni e costruire relazioni tra i team di sviluppo software e i gruppi operativi. server, database e reti. La sua frustrazione per la mancanza di coesione e dei muri che separano lo sviluppo e le operazioni gli ha suscitato risentimento. La ricerca di un miglioramento lo ha spinto all'azione.
Nel 2008, alla conferenza Agile a Toronto, Andrew Shefer propose di moderare un incontro informale appositamente pensato per discutere il tema "Infrastruttura Agile". E solo una persona si presentò per discutere: Patrick Debois. La loro discussione e lo scambio di idee hanno fatto avanzare il concetto di amministrazione di sistema in chiave Agile. Nello stesso anno, Debois e Shefer fondarono un gruppo moderatamente riuscito di Agile Systems Administrator su Google.
2009: Il caso della collaborazione tra Dev e Ops
Alla conferenza O'Reilly Velocity, due dipendenti di Flickr, il vicepresidente senior delle operazioni tecniche John Allspaw e il CTO Paul Hammond, presentarono la loro famosa presentazione «10 distribuzioni al giorno: collaborazione tra Dev e Ops in Flickr».
La presentazione era in stile drammatico, Allspaw e Hammond interpretavano una complessa interazione tra i rappresentanti dello sviluppo e delle operazioni durante il processo di distribuzione del software, insieme alla ricerca dei colpevoli e a reciproche accuse nello spirito di "Non è il mio codice, sono tutti i tuoi computer!" La loro presentazione ha confermato che l'unica soluzione ragionevole è che le attività di sviluppo e distribuzione del software siano fluide, trasparenti e completamente integrate. Col tempo, questa presentazione è diventata leggendaria e ora è storicamente vista come una pietra miliare fondamentale, quando nel settore IT è emersa la richiesta di una metodologia conosciuta oggi come DevOps.
2010: DevOps negli Stati Uniti d'America
Con l'aumento dei sostenitori, la conferenza DevOpsDays è stata tenuta per la prima volta negli Stati Uniti d'America a Mountain View (California) subito dopo la conferenza annuale Velocity. Passiamo al 2018: sono programmati oltre 30 conferenze DevOpsDays, comprese decine negli Stati Uniti.
2013: Progetto "Phoenix"
Per molti di noi, un momento significativo nella storia del DevOps è stata la pubblicazione del libro "Il progetto Phoenix" di Gene Kim, Kevin Behr e George Spafford. Questo romanzo racconta la storia di un manager IT in una situazione senza uscita: gli è stato affidato il compito di salvare un progetto di e-commerce critico che è andato storto. Un misterioso mentore del manager, un membro del consiglio di amministrazione appassionato delle metodologie lean, suggerisce al protagonista nuovi modi di concepire l'IT e lo sviluppo delle applicazioni, anticipando il concetto di DevOps. A proposito, "Il progetto Phoenix" ci ha ispirato a scrivere il libro "Passa all'esternalizzazione, altrimenti..." su una storia simile nel business, in cui il vicepresidente del software utilizza il DevOps durante lo sviluppo di un nuovo prodotto di grande rilievo in outsourcing.
DevOps per il futuro
È opportuno descrivere DevOps più come un viaggio o, forse, un'aspirazione, piuttosto che come un obiettivo finale. DevOps, come la produzione snella, mira al miglioramento continuo, all'aumento della produttività e dell'efficienza, e persino al dispiegamento costante. Gli strumenti automatizzati a supporto di DevOps continuano a evolversi.
Molto è stato raggiunto sin dalla nascita di DevOps nell'ultimo decennio, e ci aspettiamo di vedere ancora di più nel 2018 e nel futuro.
Fonte: habr.com
