Orixe de DevOps: que hai no nome?

Ola Habr! Presento á súa atención a tradución do artigo "As orixes de DevOps: que hai nun nome?" por Steve Mezak.

Dependendo do teu punto de vista, DevOps celebrará este ano o seu noveno ou décimo aniversario. En 2016, o informe State of the Cloud de RightScales sinalou que o 70 por cento das pemes están adoptando prácticas DevOps. Todos os indicadores que compoñen esta puntuación aumentaron desde entón. Mentres DevOps prepárase para entrar na súa segunda década, sería xenial dar un paseo polo pasado e volver ás orixes de DevOps, e mesmo ás orixes do propio nome.

Antes de 2007: unha cadea perfecta de eventos

Antes de 2007, unha serie de circunstancias finalmente deron a luz ao que hoxe se coñece como DevOps.

Delgado xa demostrou ser a mellor práctica. Tamén coñecido como Sistema de produción Toyota, Lean Manufacturing esfórzase por optimizar os procesos na planta de fabricación. (Por certo, a dirección de Toyota inspirouse inicialmente nos métodos orixinais da cadea de montaxe introducidos pola Ford Motor Company). Mellora continua é o mantra para a manufactura esbelta. Na práctica, avalíanse constantemente os seguintes camiños:

  1. Manter os niveis de inventario de materias primas e produtos acabados ao mínimo. Lean manufacturing significa unha cantidade mínima de inventario de materias primas para producir bens e unha cantidade mínima de produtos acabados á espera de ser encargados ou enviados.
  2. Minimizar a cola de pedidos. O ideal é que as ordes recibidas pasen inmediatamente ao estado completado. A métrica clave para a fabricación lean será sempre o tempo desde a recepción do pedido ata a entrega.
  3. Maximizar a eficiencia do proceso produtivo. A re-enxeñaría de procesos e a automatización mellorada combínanse para producir bens o máis rápido posible. Todas as áreas de produción ao longo de todo o camiño (corte, soldadura, montaxe, probas, etc.) avalíanse para detectar ineficiencias.

No mundo das TI, os métodos tradicionais do modelo en cascada de desenvolvemento de software xa deron paso a métodos iterativos rápidos como Áxil. A velocidade foi o berro de guerra, aínda que ás veces a calidade sufriu na procura dun desenvolvemento e despregamento rápidos. Do mesmo xeito, a computación na nube, en particular Infraestrutura como servizo (IaaS) e Plataforma-como-servizo (PaaS) demostraron ser solucións maduras en procesos e infraestruturas de TI.

Finalmente, recentemente comezaron a aparecer ferramentas para Integración continua (CI). A idea das ferramentas CI naceu e presentou Gradi Booch en 1991 no seu Método Booch.

2007-2008: belga decepcionada

O consultor belga, xestor de proxectos e prácticas Agile Patrick Debois aceptou un nomeamento dun ministerio do goberno belga para axudar na migración do centro de datos. En particular, estivo involucrado nas probas de certificación e preparación. As súas responsabilidades esixíronlle coordinar e construír relacións entre os equipos de desenvolvemento de software e os equipos de operacións de servidores, bases de datos e redes. A súa frustración pola falta de cohesión e os muros que separan os métodos de desenvolvemento e operación deixárono amargo. As ganas de mellorar de Desbois levouno pronto á acción.
Na conferencia Agile de 2008 en Toronto, Andrew Schaefer propuxo moderar unha reunión informal especialmente organizada para discutir o tema "Infraestrutura áxil"E só unha persoa veu para tratar o tema: Patrick DeBois. A súa discusión e intercambio de ideas avanzaron no concepto de administración de sistemas áxiles. Ese mesmo ano, DeBois e Schaefer crearon o grupo de administradores de sistemas áxiles de moderado éxito en Google.

2009: O caso da cooperación entre Dev e Ops

Na conferencia O'Reilly Velocity, dous empregados de Flickr, o vicepresidente sénior de operacións técnicas John Allspaw e o director técnico Paul Hammond, fixeron a xa famosa presentación. "10 implementacións ao día: colaboración entre desenvolvedores e operacións en Flickr".

A presentación foi un drama, con Allspaw e Hammond recreando as complexas interaccións entre os representantes de Desenvolvemento e Operacións durante o proceso de implantación do software, con indicacións co dedo e recriminacións como "Non é o meu código, son todos os teus ordenadores!" A súa presentación confirmou que a única opción sensata é que as actividades de desenvolvemento e implantación de software sexan perfectas, transparentes e totalmente integradas. Co paso do tempo, esta presentación converteuse en lendaria e agora é históricamente vista como un fito fundamental cando a industria das TI comezou a pedir a metodoloxía coñecida hoxe como DevOps.

2010: DevOps nos Estados Unidos de América

Cun crecente número de seguidores, a conferencia DevOpsDays celebrouse por primeira vez nos Estados Unidos en Mountain View, California, inmediatamente despois da conferencia anual Velocity. Avance rápido ata 2018, e hai máis de 30 conferencias DevOpsDays programadas, incluídas ducias nos Estados Unidos.

2013: Proxecto "Phoenix"

Para moitos de nós, outro momento destacable na historia de DevOps foi a publicación do libro "The Phoenix Project" de Gene Kim, Kevin Behr e George Safford. Esta novela conta a historia dun responsable informático que se atopa nunha situación desesperada: encárgase de rescatar un proxecto crítico de comercio electrónico que saíu mal. O misterioso mentor do xestor, un membro do consello de administración apaixonado polos métodos de manufactura lean, suxire novas formas ao personaxe principal de pensar en TI e desenvolvemento de aplicacións, anticipándose ao concepto de DevOps. Por certo, "The Phoenix Project" inspirounos a escribir o libro "Outsource or else..." sobre unha historia empresarial similar na que un vicepresidente de software usa DevOps durante o desenvolvemento dun novo produto importante externalizado.

DevOps para o futuro

Paga a pena describir DevOps como unha viaxe, ou quizais unha aspiración, máis que como un destino final. DevOps, como a manufactura esbelta, esfórzase por mellorar continuamente, aumentar a produtividade e a eficiencia e mesmo a implantación continua. As ferramentas automatizadas para apoiar DevOps seguen evolucionando.

Conseguiuse moito desde o inicio de DevOps na última década, e esperamos ver aínda máis en 2018 e máis aló.

Fonte: www.habr.com

Engadir un comentario