Ciao, Habr! Vi presento la traduzione dell'articolo autore Steve Mezak.
A seconda del vostro punto di vista, il DevOps festeggerà il suo nono o decimo anniversario quest'anno. Nel 2016, nel rapporto di RightScale sulla situazione del cloud, è stato riportato che il 70% delle piccole e medie imprese adotta metodi DevOps. Ogni indicatore che ha contribuito a questa stima è aumentato da allora. Mentre il DevOps si prepara a entrare nel secondo decennio della sua esistenza, sarebbe interessante fare una passeggiata nei vicoli del passato e tornare alle origini del DevOps — e persino all'origine di questo stesso nome.
Fino al 2007: Una catena di eventi ideale
Fino al 2007, una serie di circostanze ha infine dato vita a ciò che oggi è conosciuto come DevOps.
Lean Production si è già affermata come migliore pratica. Conosciuta anche come sistema produttivo Toyota, la Lean Production mira all'ottimizzazione dei processi nel reparto di produzione. (A proposito, la direzione Toyota è stata inizialmente ispirata dai metodi originali di linea di assemblaggio presentati dalla Ford Motor Company). Miglioramento continuo è il mantra della Lean Production. Nella pratica, si valutano costantemente i seguenti percorsi:
- Mantenere i livelli di scorte di materie prime e prodotti finiti al minimo. La Lean Production implica la minima quantità di materie prime necessaria per la produzione e la minima quantità di prodotti già pronti in attesa di distribuzione o spedizione.
- Minimizzazione delle code degli ordini. Idealmente, gli ordini ricevuti passano immediatamente allo stato di completati. Un indicatore chiave della Lean Production sarà sempre il tempo dall'arrivo dell'ordine alla consegna.
- Massimizzazione dell'efficienza del processo produttivo. La riorganizzazione dei processi e una migliore automazione si uniscono con l'obiettivo di produrre beni il più rapidamente possibile. Ogni passaggio della produzione lungo il percorso (taglio, saldatura, assemblaggio, test, ecc.) è valutato per l'inefficienza.
Nel mondo IT, i metodi tradizionali del modello a cascata per lo sviluppo software hanno già ceduto il passo a metodi rapidi e iterativi, come Agile. La velocità era un grido di battaglia, anche se la qualità a volte soffriva nella ricerca di uno sviluppo e di un'implementazione rapidi. 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, sono recentemente emersi set di strumenti per Integrazione Continua (CI). L'idea di strumenti CI è stata concepita e presentata da Grady Booch nel 1991 nel suo Metodo Booch.
2007-2008: Un belga deluso
Il consulente belga, project manager e praticante Agile Patrick Debois ha accettato un incarico dal governo belga per assistere nella migrazione dei data center. In particolare, si occupava di certificazione e verifica della prontezza. Le sue responsabilità richiedevano di coordinare le azioni e costruire relazioni tra i gruppi di sviluppo software e i gruppi operativi server, dei database e delle reti. La sua delusione per la mancanza di coesione e per i muri che separavano i metodi di sviluppo e operativi lo ha portato a provare frustrazione. La sua ricerca del miglioramento lo ha presto spinto all'azione.
Nel 2008, alla conferenza Agile di Toronto, Andrew Shafer propose di moderare un incontro informale appositamente organizzato per discutere del tema "Infrastruttura Agile". E solo una persona si presentò per discutere l'argomento: Patrick Debois. La loro discussione e lo scambio di idee hanno fatto avanzare il concetto di amministrazione sistematica in chiave Agile. Nello stesso anno, Debois e Shafer crearono un gruppo di Agile Systems Administrator moderatamente di successo su Google.
2009: Il caso della collaborazione tra Dev e Ops
Alla conferenza O'Reilly Velocity, due membri di Flickr, il vicepresidente senior per le operazioni tecniche John Allspaw e il CTO Paul Hammond, presentarono la famosa presentazione «10 deploys al giorno: collaborazione tra Dev e Ops in Flickr».
La presentazione è stata in stile drammatico, Allspaw e Hammond hanno messo in scena un'interazione complessa tra i rappresentanti dello sviluppo e delle operazioni nel processo di distribuzione del software, insieme alla ricerca di colpevoli e reciproche accuse nel senso di 'Non è il mio codice, sono tutti i tuoi computer!' La loro presentazione ha confermato che l'unica soluzione sensata è che le attività di sviluppo e distribuzione del software siano fluide, trasparenti e completamente integrate. Con il tempo, questa presentazione è diventata leggendaria ed è ora storicamente considerata una pietra miliare fondamentale, quando nel settore IT si è presentata la domanda di una metodologia conosciuta oggi come DevOps.
2010: DevOps negli Stati Uniti d'America
Con la crescita del numero di 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. Spostiamoci nel 2018: sono programmati più di 30 conferenze DevOpsDays, comprese decine negli Stati Uniti.
2013: Progetto Phoenix
Per molti di noi, un altro momento significativo nella storia del DevOps è stata la pubblicazione del libro 'Progetto Phoenix' di Gene Kim, Kevin Behr e George Spafford. In questo romanzo si narra la storia di un manager IT in una situazione disperata: gli è stato assegnato il compito di salvare un progetto critico di e-commerce, che è andato storto. Un misterioso mentore del manager — un membro del consiglio di amministrazione appassionato di metodi di produzione snella — suggerisce al protagonista nuovi modi di concepire l'IT e lo sviluppo delle applicazioni, anticipando il concetto di DevOps. A proposito, 'Progetto Phoenix' ci ha ispirato a scrivere un libro intitolato 'Passa all'outsourcing, altrimenti...' su una storia simile nel business, dove un vicepresidente del software utilizza DevOps nello sviluppo di un nuovo grande prodotto in outsourcing.
DevOps per il futuro
È opportuno descrivere il DevOps più come un viaggio o, forse, un'aspirazione, piuttosto che come un punto di arrivo finale. Il DevOps, come la produzione snella, mira al miglioramento continuo, all'aumento della produttività e dell'efficienza e persino a distribuzioni costanti. Gli strumenti automatizzati a sostegno del DevOps continuano a evolversi.
Molto è stato raggiunto dalla creazione del DevOps nell'ultimo decennio, e ci aspettiamo di vedere ancora di più nel 2018 e in futuro.
Fonte: habr.com
