Ehi Habr! Presento alla vostra attenzione la traduzione dell'articolo "Le origini di DevOps: cosa c'è in un nome?" di Steve Mezak.

A seconda del punto di vista, quest’anno DevOps festeggerà il suo nono o decimo anniversario. Nel 2016, il rapporto State of the Cloud di RightScales ha rilevato che il 70% delle PMI sta adottando pratiche DevOps. Da allora ogni indicatore che compone questo punteggio è aumentato. Mentre DevOps si prepara a entrare nel suo secondo decennio, sarebbe fantastico fare una passeggiata nel passato e tornare alle origini di DevOps e persino alle origini del nome stesso.

Prima del 2007: Una catena di eventi perfetta

Prima del 2007, una serie di circostanze hanno dato vita a ciò che oggi è conosciuto come DevOps.

Pendere ha già dimostrato di essere la migliore pratica. Conosciuto anche come Sistema di produzione Toyota, La Lean Manufacturing si impegna a ottimizzare i processi nel reparto di produzione. (A proposito, il management della Toyota si è inizialmente ispirato ai metodi originali della catena di montaggio introdotti dalla Ford Motor Company). Miglioramento continuo è il mantra della produzione snella. In pratica vengono costantemente valutati i seguenti percorsi:

1. Mantenere al minimo i livelli di inventario delle materie prime e dei prodotti finiti. La produzione snella significa una quantità minima di scorte di materie prime per produrre beni e una quantità minima di prodotti finiti in attesa di essere ordinati o spediti.
2. Ridurre al minimo la coda degli ordini. Idealmente, gli ordini ricevuti passano immediatamente allo stato completato. Il parametro chiave per la produzione snella sarà sempre il tempo che intercorre tra la ricezione dell'ordine e la consegna.
3. Massimizzare l’efficienza del processo produttivo. La reingegnerizzazione dei processi e una migliore automazione si stanno combinando per produrre beni il più rapidamente possibile. Ogni area della produzione lungo l'intero percorso (taglio, saldatura, assemblaggio, collaudo, ecc.) viene valutata per inefficienze.

Nel mondo IT, i metodi tradizionali del modello a cascata di sviluppo software hanno già lasciato il posto a metodi iterativi rapidi come Agile. La velocità era il grido di battaglia, anche se la qualità a volte soffriva nel perseguimento di un rapido sviluppo e dispiegamento. Allo stesso modo, in particolare, il cloud computing Infrastructure-as-a-Service (IaaS) e Platform-as-a-Service (PaaS) si sono dimostrati soluzioni mature nei processi e nelle infrastrutture IT.

Infine, recentemente hanno iniziato ad apparire kit di strumenti Integrazione continua (CI). L'idea degli strumenti CI è nata e presentata da Gradi Booch nel lontano 1991 nel suo Metodo Booch.

2007-2008: Belga deluso

Patrick Debois, consulente belga, project and practice manager Agile, ha accettato un incarico da parte di un ministero del governo belga per assistere nella migrazione dei data center. In particolare, è stato coinvolto nella certificazione e nei test di preparazione. Le sue responsabilità gli richiedevano di coordinare e costruire relazioni tra i team di sviluppo software e i team operativi di server, database e rete. La sua frustrazione per la mancanza di coesione e i muri che separano i metodi di sviluppo e operativi lo lasciarono amareggiato. Il desiderio di migliorare di Desbois lo ha presto portato all'azione.
Alla conferenza Agile del 2008 a Toronto, Andrew Schaefer ha proposto di moderare un incontro informale appositamente organizzato per discutere l'argomento "Infrastruttura agile"E solo una persona è venuta a discutere l'argomento: Patrick DeBois. La loro discussione e lo scambio di idee hanno fatto avanzare il concetto di amministrazione dei sistemi Agile. Nello stesso anno, DeBois e Schaefer hanno creato il gruppo Agile Systems Administrator di discreto successo presso 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, hanno tenuto l'ormai famosa presentazione "10 implementazioni al giorno: collaborazione tra sviluppo e operazioni su Flickr".

La presentazione è stata drammatica, con Allspaw e Hammond che hanno ricostruito le complesse interazioni tra i rappresentanti dello sviluppo e delle operazioni durante il processo di distribuzione del software, con tanto di puntare il dito e recriminazioni sulla falsariga di "Non è il mio codice, sono tutti i tuoi computer!" La loro presentazione ha confermato che l'unica opzione sensata è che le attività di sviluppo e distribuzione del software siano fluide, trasparenti e pienamente integrate. Nel corso del tempo, questa presentazione è diventata leggendaria ed è oggi storicamente considerata una pietra miliare fondamentale quando il settore IT ha iniziato a richiedere la metodologia conosciuta oggi come DevOps.

2010: DevOps negli Stati Uniti d'America

Con un seguito in crescita, la conferenza DevOpsDays si è tenuta per la prima volta negli Stati Uniti a Mountain View, in California, subito dopo la conferenza annuale Velocity. Nel 2018 sono previste più di 30 conferenze DevOpsDays, tra cui dozzine negli Stati Uniti.

2013: Progetto "Fenice"

Per molti di noi, un altro momento degno di nota nella storia di DevOps è stata la pubblicazione del libro “The Phoenix Project” di Gene Kim, Kevin Behr e George Safford. Questo romanzo racconta la storia di un manager IT che si trova in una situazione disperata: ha il compito di salvare un progetto critico di e-commerce che è andato storto. Il misterioso mentore del manager - un membro del consiglio di amministrazione appassionato di metodi di produzione snella - suggerisce al personaggio principale nuovi modi di pensare all'IT e allo sviluppo di applicazioni, anticipando il concetto di DevOps. A proposito, "The Phoenix Project" ci ha ispirato a scrivere il libro "Outsource or else..." su una storia aziendale simile in cui un vicepresidente del software utilizza DevOps durante lo sviluppo di un nuovo importante prodotto in outsourcing.

DevOps per il futuro

Vale la pena descrivere DevOps come un viaggio, o forse un'aspirazione, piuttosto che come una destinazione finale. DevOps, come la produzione snella, mira al miglioramento continuo, all'aumento della produttività e dell'efficienza e persino all'implementazione continua. Gli strumenti automatizzati per supportare DevOps continuano ad evolversi.

Molto è stato fatto dall’avvio di DevOps nell’ultimo decennio, e prevediamo di vedere ancora di più nel 2018 e oltre.

Fonte: habr.com