¡Hola, Habr! Presento a su atención la traducción del artículo. por Steve Mezak.
Dependiendo de su punto de vista, DevOps celebrará este año su noveno o décimo aniversario. En 2016, el informe State of the Cloud de RightScales señaló que el 70 por ciento de las PYMES están adoptando prácticas de DevOps. Todos los indicadores que componen este puntaje han aumentado desde entonces. Mientras DevOps se prepara para entrar en su segunda década, sería fantástico dar un paseo hacia el altar y regresar a los orígenes de DevOps, e incluso a los orígenes del nombre mismo.
Antes de 2007: una cadena perfecta de acontecimientos
Antes de 2007, una serie de circunstancias acabaron dando origen a lo que hoy se conoce como DevOps.
Inclinarse ya ha demostrado ser una buena práctica. También conocido como sistema de producción toyota, Lean Manufacturing se esfuerza por optimizar los procesos en la planta de fabricación. (Por cierto, la dirección de Toyota se inspiró inicialmente en los métodos de cadena de montaje originales introducidos por Ford Motor Company). Mejora continua es el mantra de la fabricación ajustada. En la práctica, se evalúan constantemente los siguientes caminos:
- Mantener al mínimo los niveles de inventario de materias primas y productos terminados.. La fabricación ajustada significa una cantidad mínima de inventario de materias primas para producir bienes y una cantidad mínima de productos terminados en espera de ser ordenados o enviados.
- Minimizar la cola de pedidos. Idealmente, los pedidos recibidos pasan inmediatamente al estado completado. La métrica clave para la fabricación ajustada siempre será el tiempo transcurrido desde la recepción del pedido hasta la entrega.
- Maximizar la eficiencia del proceso de producción. La reingeniería de procesos y la automatización mejorada se combinan para producir bienes lo más rápido posible. Se evalúan las ineficiencias de cada área de producción a lo largo de todo el recorrido (corte, soldadura, montaje, pruebas, etc.).
En el mundo de TI, los métodos tradicionales del modelo en cascada de desarrollo de software ya han dado paso a métodos iterativos rápidos como Agil Modelo de. La velocidad fue el grito de guerra, incluso si la calidad a veces se vio perjudicada en la búsqueda de un desarrollo y despliegue rápidos. De la misma manera, la computación en la nube, en particular Infraestructura-as-a-Service (IaaS) y Plataforma como servicio (PaaS) han demostrado ser soluciones maduras en infraestructura y procesos de TI.
Por último, recientemente han comenzado a aparecer conjuntos de herramientas para Integración continua (CI). La idea de las herramientas de CI nació y fue presentada por Gradi Booch allá por 1991 en su Método Booch.
2007-2008: belga decepcionado
El consultor belga, director de prácticas y proyectos Agile, Patrick Debois, aceptó un nombramiento de un ministerio del gobierno belga para ayudar con la migración del centro de datos. En particular, participó en las pruebas de certificación y preparación. Sus responsabilidades le exigían coordinar y establecer relaciones entre los equipos de desarrollo de software y los equipos de operaciones de servidores, bases de datos y redes. Su frustración por la falta de cohesión y los muros que separan los métodos de desarrollo y operación lo dejaron amargado. El deseo de mejorar de Desbois pronto le llevó a la acción.
En la conferencia Agile de 2008 en Toronto, Andrew Schaefer propuso moderar una reunión informal especialmente organizada para discutir el tema "Infraestructura ágil"Y sólo una persona vino a discutir el tema: Patrick DeBois. Su discusión e intercambio de ideas avanzaron el concepto de administración de sistemas ágiles. Ese mismo año, DeBois y Schaefer crearon el grupo de administradores de sistemas ágiles, de éxito moderado, en Google.
2009: El caso de la cooperación entre Dev y Ops
En la conferencia O'Reilly Velocity, dos empleados de Flickr, el vicepresidente senior de operaciones técnicas, John Allspaw, y el director de tecnología, Paul Hammond, hicieron la ahora famosa presentación. "Diez implementaciones al día: colaboración de desarrollo y operaciones en Flickr".
La presentación fue un drama, con Allspaw y Hammond recreando las complejas interacciones entre los representantes de Desarrollo y Operaciones durante el proceso de implementación del software, con acusaciones y recriminaciones como "¡No es mi código, son todas sus computadoras!" Su presentación confirmó que la única opción sensata es que las actividades de desarrollo e implementación de software sean fluidas, transparentes y totalmente integradas. Con el tiempo, esta presentación se volvió legendaria y ahora se considera históricamente como un hito fundamental cuando la industria de TI comenzó a exigir la metodología conocida hoy como DevOps.
2010: DevOps en los Estados Unidos de América
Con un número cada vez mayor de seguidores, la conferencia DevOpsDays se celebró por primera vez en los Estados Unidos en Mountain View, California, inmediatamente después de la conferencia anual Velocity. Si avanzamos hasta 2018, hay más de 30 conferencias DevOpsDays programadas, incluidas docenas en los Estados Unidos.
2013: Proyecto "Fénix"
Para muchos de nosotros, otro momento digno de mención en la historia de DevOps fue la publicación del libro “The Phoenix Project” de Gene Kim, Kevin Behr y George Safford. Esta novela cuenta la historia de un director de TI que se encuentra en una situación desesperada: tiene la tarea de rescatar un proyecto crítico de comercio electrónico que salió mal. El misterioso mentor del directivo, un miembro de la junta directiva apasionado por los métodos de producción eficiente, sugiere al personaje principal nuevas formas de pensar en TI y en el desarrollo de aplicaciones, anticipándose al concepto de DevOps. Por cierto, "The Phoenix Project" nos inspiró a escribir el libro "Outsource or else..." sobre una historia empresarial similar en la que un vicepresidente de software utiliza DevOps durante el desarrollo de un nuevo producto importante subcontratado.
DevOps para el futuro
Vale la pena describir DevOps como un viaje, o quizás una aspiración, más que un destino final. DevOps, al igual que la fabricación ajustada, se esfuerza por lograr una mejora continua, una mayor productividad y eficiencia e incluso una implementación continua. Las herramientas automatizadas para respaldar DevOps continúan evolucionando.
Se ha logrado mucho desde el inicio de DevOps en la última década, y esperamos ver aún más en 2018 y en adelante.
Fuente: habr.com