¡Hola, Habr! Les presento la traducción del artículo del autor Steve Mezak.
Dependiendo de tu perspectiva, DevOps celebrará su noveno o décimo aniversario este año. En 2016, un informe de RightScale sobre el estado de la nube indicaba que el 70 por ciento de las pequeñas y medianas empresas estaban adoptando métodos DevOps. Cada uno de los indicadores que constituyeron esa evaluación ha aumentado desde entonces. Mientras DevOps se prepara para entrar en su segundo decenio, sería genial recorrer los rincones del pasado y volver a los orígenes de DevOps — y hasta del propio nombre.
Antes de 2007: La Cadena de Eventos Perfecta
Antes de 2007, una serie de circunstancias finalmente dio origen a lo que hoy se conoce como DevOps.
La producción ajustada ya se había establecido como la mejor práctica. También conocida como el Sistema de Producción Toyota, la producción ajustada busca optimizar los procesos en el taller de producción. (Por cierto, la dirección de Toyota se inspiró originalmente en los métodos de la línea de montaje presentados por Ford Motor Company). La mejora continua es un mantra para la producción ajustada. En la práctica, se evalúan constantemente las siguientes vías:
- Mantener el nivel de inventario de materias primas y productos terminados al mínimo. La producción ajustada implica la menor cantidad posible de materias primas para producir bienes y la menor cantidad de productos terminados que esperan ser distribuidos por pedidos o despachados.
- Minimizar la cola de pedidos. Idealmente, los pedidos recabados pasan inmediatamente al estado de completados. Una métrica clave de la producción ajustada siempre será el tiempo desde la recepción del pedido hasta la entrega.
- Maximizar la eficiencia del proceso de producción. La reorganización de procesos y la automatización mejorada se combinan con el objetivo de producir bienes lo más rápido posible. Cada etapa del proceso de producción en todo el camino (corte, soldadura, ensamblaje, prueba, etc.) se evalúa en busca de ineficiencias.
En el mundo de TI, los métodos tradicionales de cascada en el desarrollo de software han dado paso a métodos iterativos rápidos, como AgileLa velocidad era un grito de guerra, incluso si la calidad a veces se deterioraba en la búsqueda de un desarrollo y despliegue rápidos. De manera similar, la computación en la nube, en particular Infraestructura como Servicio (IaaS) y Plataforma como Servicio (PaaS) se han consolidado como soluciones maduras en los procesos e infraestructura de TI.
Finalmente, han comenzado a surgir recientemente conjuntos de herramientas para Integración Continua (CI). La idea de herramientas CI fue concebida y presentada por Grady Booch en 1991 en su Método Booch.
2007-2008: El belga decepcionado
El consultor belga, gerente de proyectos y practicante de Agile Patrick Debois recibió un nombramiento del Ministerio del Gobierno de Bélgica para ayudar con la migración de centros de datos. En particular, se ocupó de la certificación y verificación de la preparación. Sus responsabilidades requerían que coordinara acciones y estableciera relaciones entre los grupos de desarrollo de software y los equipos de operaciones servidores, bases de datos y redes. Su frustración por la falta de cohesión y las barreras que separaban los métodos de desarrollo y operaciones sembraron en él el descontento. El deseo de mejorar pronto llevó a Debois a la acción.
En 2008, en la conferencia Agile en Toronto, Andrew Shafer propuso moderar una reunión informal especialmente organizada para discutir el tema "Infraestructura Agile". Y solo una persona vino a discutir el tema: Patrick Debois. Su discusión e intercambio de ideas avanzaron el concepto de administración de sistemas bajo Agile. Ese mismo año, Debois y Shafer crearon un grupo moderadamente exitoso de Administradores de Sistemas Agile en Google.
2009: El caso de la colaboració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 técnico Paul Hammond, presentaron hoy una famosa charla «10 despliegues al día: colaboración Dev y Ops en Flickr».
La presentación fue de estilo dramático, Allspaw y Hammond representaron una compleja interacción entre los representantes de Desarrollo y Operaciones durante el despliegue de software, junto con la búsqueda de culpables y acusaciones mutuas en el espíritu de «¡No es mi código, son tus computadoras!» Su presentación confirmó que la única salida razonable es que las actividades de desarrollo y despliegue de software sean fluidas, transparentes y completamente integradas. Con el tiempo, esta presentación se convirtió en legendaria, y ahora se considera históricamente como un hito fundamental cuando en la industria de TI surgió la demanda de una metodología conocida hoy como DevOps.
2010: DevOps en los Estados Unidos de América
Con el creciente número de partidarios, la conferencia DevOpsDays se llevó a cabo por primera vez en los Estados Unidos de América en Mountain View (California) justo después de la conferencia anual Velocity. Avancemos al año 2018: se planificaron más de 30 conferencias DevOpsDays, incluida decenas en los Estados Unidos.
2013: Proyecto ‘Fénix’
Para muchos de nosotros, otro momento notable en la historia de DevOps fue la publicación del libro ‘Proyecto Fénix’ de Gene Kim, Kevin Behr y George Spafford. Esta novela cuenta la historia de un gerente de TI que se encuentra en una situación desesperada: se le ha encomendado salvar un proyecto crítico de desarrollo de comercio electrónico que salió mal. Un misterioso mentor del gerente —un miembro de la junta, apasionado por los métodos de producción esbelta— sugiere al protagonista nuevas formas de pensar sobre TI y desarrollo de aplicaciones, anticipando el concepto de DevOps. Por cierto, ‘Proyecto Fénix’ nos inspiró a escribir el libro ‘Outsource o muere…’ sobre una historia similar en los negocios, donde un vicepresidente de software utiliza DevOps durante el desarrollo de un nuevo producto importante en outsourcing.
DevOps para el futuro
Es más apropiado describir DevOps como un viaje o, quizás, una aspiración, más que como un destino final. DevOps, al igual que la producción esbelta, busca la mejora continua, el aumento de la productividad y la eficiencia e incluso el despliegue continuo. Las herramientas automatizadas para apoyar DevOps continúan evolucionando.
Se han logrado muchas cosas desde la creación de DevOps en la última década, y esperamos ver aún más en 2018 y en el futuro.
Fuente: habr.com
