Historia y origen de DevOps

Historia de DevOps: su creación

El origen de DevOps nos lleva al año 2007 cuando un consultor freelance llamado patrick debois devops experimenta los conflictos e inconvenientes de la rivalidad entre los equipos de operaciones y desarrollo en una organización del gobierno belga, para la cual trabajaba.

Un año más tarde en el marco de Agile 2008 conference tiene un encuentro con Andrew Clay Shafer, donde coinciden en lo problemático que es la división en los equipos de trabajos y deciden crear un grupo en Google llamado Agile System Administrators, para dar espacio a que otras personas puedan compartir sus opiniones al respecto.

Hacia 2009 John Allspaw y Paul Hammond dan a conocer “10 deploy per day¨ durante la conferencia O´Relly Velocity 09 y que proponía enfocar esfuerzos en la integración de los departamentos de operaciones y desarrollo. Esta propuesta llama la atención de Debois, quien decide llevarlo a cabo y adoptar el término DevOps (Dev and Ops Cooperation at Flickr).

A partir de allí, el mundo del desarrollo de aplicaciones, software y demás elementos tecnológicos empezó a notar la necesidad de la aplicación de las prácticas de DevOps y el llamado movimiento DevOps empieza a expandirse y popularizarse.

Origen de DevOps: ¿Qué pasaba antes?

Como hemos visto previamente, la metodología de desarrollo DevOps surge principalmente para resolver el conflicto de intereses entre los equipos de desarrollo y el de operaciones tecnológicas y acelerar el ciclo de vida del desarrollo del software.

Antes del origen de DevOps, las organizaciones del mundo IT se basaban en una estructura tradicional, donde desarrolladores y operadores se veían los unos a otros como adversarios, debido a que sus objetivos a alcanzar parecían ser contrarios entre sí.

Por un lado, el equipo de desarrollo debe responder a los cambios del mercado, llevando nuevas funcionalidades a producción de la manera más rápida posible. Mientras que operaciones debe encargarse de ofrecer servicios estables, fiables y seguros al cliente, lo cual dificulta llevar a producción cambios que puedan poner en peligro el entorno.

Entonces el conflicto aparece cuando los equipos implementan medidas para cumplir sus propios objetivos, sin tener en cuenta la repercusión que esto puede causar en los demás. Así, las empresas IT que no utilizaban la metodología DevOps se veían incapaces de hacer cambios en producción en poco tiempo, sino que tardaban semanas e incluso meses; además, al no ser una rutina, los cambios solían resultar en caídas del sistema y otras complicaciones.

Este conflicto de intereses e incapacidad de realizar cambios constantes se traduce en un time to market lento, una calidad de producto cuestionable, un coste humano y económico no deseado y un aumento de la deuda técnica; siendo estas, algunas de las dificultades que se presentaban antes del origen de DevOps.

Time to market lento

En el mundo IT, la competitividad es uno de los factores más importantes y esto requiere agilidad en los procesos de desarrollo y entrega, por lo cual, contar con un time to market lento significa una gran desventaja competitiva para las compañías tecnológicas. Esto puede ocurrir por ejemplo, porque el equipo de desarrollo que desconoce cómo se ejecuta su código, debe cumplir con determinados compromisos en una fecha establecida. Esta situación ocasionará que la parte Dev de la empresa quiera realizar algún cambio que para el equipo Ops suponga un peligro para el sistema.

Sin duda, este conflicto desencadena en una espiral descendente donde cada acción o incluso las no- acciones, hacen que todo empeore continuamente: las personas están cada vez más ocupadas, las tareas toman más tiempo del debido y las comunicaciones se vuelven más lentas. Esto ocasiona que se alarguen los tiempos de entrega y aumenten los conflictos entre equipos de trabajo, impactando negativamente sobre la calidad del producto, nuestro negocio y nuestros clientes.

Coste humano y económico

Encontrarse en una espiral descendente por mucho tiempo, ocasiona que el equipo de trabajo se sienta agotado y desesperado como resultado de trabajar en un sistema problemático que no admite propuestas de cambios y mejoras. Los integrantes del proyecto pueden sentir miedo de actuar correctamente y ser reprendido, fallar o ver peligrar sus puestos de trabajo. Esto da como resultado sujetos incapaces de actuar en una manera que prevenga y evite el problema en un futuro.

Una empresa con conflicto entre sus equipos de trabajo y atrapado en una espiral descendente, también representa un problema a nivel económico, pues se pierde mucho dinero en trabajos no planeados, urgencias o retrabajos. En este punto, la metodología DevOps ( developer operations ) se hace necesaria, pues su propuesta de una integración continua ayuda a reducir esta pérdida y a redirigir el potencial humano hacia tareas que aporten mayor valor en los proyectos.

Deuda técnica:

La deuda técnica refiere a cómo las decisiones que tomamos durante el ciclo de desarrollo de software o de algún proyecto, nos llevan a problemas que con el tiempo son más complicadas de resolver y que reducen las opciones disponibles para poder solucionarlo en un futuro.

¿Cuál es el siguiente paso?

Los conflictos y dificultades que promovieron el origen de Devops y el dev ops meaning le siguen ocurriendo a las empresas y proyectos que no utilizan la metodología DevOps para el desarrollo de software. Son más lentos y menos eficientes que quienes sí implementan las prácticas DevOps.

Por esto, si te interesa seguir aprendiendo sobre esta metodología y utilizarla en tus proyectos para obtener una ventaja competitiva en el mundo tecnológico, no dudes en inscribirte en nuestro DevOps & Cloud Computing Full Stack Bootcamp, donde te formarás en el uso de esta y otras prácticas que mejoran y agilizan el proceso y entrega de tus productos y servicios.