Desde el inicio de las aplicaciones cliente-servidor (hablamos del siglo pasado, el jurásico de la creación de software), los equipos de desarrollo y los de operaciones y sistemas han sido tan necesarios como incompatibles. Era un gran problema organizativo. Los que escribían código estaban totalmente aislados de los responsables de implementarlo y mantenerlo. No solo eso. Habitualmente los desarrolladores y los administradores de sistemas tenían asignados – y en muchos casos siguen teniendo- diferentes objetivos e incluso directrices departamentales contrapuestas. Muchas veces ni siquiera compartían ubicación. Por todo ello, la comunicación era complicada o simplemente inexistente. Los desarrolladores de software saben de qué hablo: imposibilidad de subir a producción una nueva versión urgente, fallos en el acceso a los entornos, VPNs caídas…
Por otro lado, los responsables de mantener y administrar los sistemas también tienen su visión: programadores que no siguen las políticas de seguridad en los entornos de desarrollo/testing/producción, credenciales prestadas entre componentes del equipo, horarios de deploy no respetados… La siguiente foto es fácil de adivinar: retraso en las entregas, empobrecimiento de la calidad y la consecuencia imperdonable: un cliente insatisfecho.
Así las cosas, llegamos al año 2008 y con las metodologías Agile en pleno despegue, a un belga llamado Patrick Debois se le ocurrió preguntarse… ¿Se podría aplicar Agile a los entornos de operaciones IT? Es más, ¿podríamos integrar desarrollo e IT en un mismo marco de trabajo? Para dar respuesta a esta pregunta, nació DevOps. DevOps unifica ambos departamentos bajo un mismo paraguas Agile. Ahora los dos comparten objetivos, valores y premisas. Todos ganan, pero los grandes beneficiados son el producto final y la satisfacción del cliente. “The war is over”.
En resumen: DevOps es una metodología de desarrollo software que integra los equipos de desarrollo y administración de sistemas y permite que los desarrolladores se centren sólo en desarrollar y puedan desplegar su código en segundos, todas las veces que sean necesarias. En este punto es fácil confundirse con el clásico hombre orquesta, el artista que modifica una función obsoleta del software de facturación, analiza el rendimiento de la base de datos y por la tarde nos monta la wifi en el almacén… Pero, nada más lejos de la realidad.
DevOps es una nueva manera de ver el desarrollo de software y se basa en una serie de buenas prácticas englobadas dentro del denominado desarrollo Continuo, a partir del ciclo de vida estándar en el desarrollo de aplicaciones:
– Integración continua (CI). Utilizando herramientas de gestión de configuración (CM) junto a otras específicas, de pruebas y desarrollo, se puede saber exactamente qué partes del código que se están creando están listas para pasar a producción con la mínima cantidad de errores. Para ello, es vital un intercambio fluido de información entre el equipo de pruebas y el de desarrollo, con el fin de identificar y resolver problemas en el código de forma ágil.
– Entrega continua (CD). Una vez tenemos un código libre de errores, la entrega continua nos permite automatizar la introducción de cambios en el código para subirlo al entorno de preproducción. – Despliegue continuo. Al igual que sucede con la entrega continua, el despliegue continuo permite automatizar el lanzamiento de nuevo código al entorno de producción, minimizando los riesgos que supone. Esto permite publicar cambios en el código varias veces al día sin problemas gracias a tecnologías de contenedor, como Docker y Kubernetes, que posibilitan aislar los entornos manteniendo la coherencia del código entre las diferentes plataformas de puesta en marcha.
Nos queda por comentar dos prácticas, que, si bien son las menos implementadas, no dejan de ser importantes: La supervisión continua y la infraestructura como código.
– Supervisión continua. Permite tener el código supervisado siempre, incluso en producción, incluyendo la infraestructura que lo mantiene. Mediante un bucle, los errores son detectados y notificados al momento, permitiendo que el código dañado vuelva a la fase de desarrollo y empiece de nuevo el ciclo CI/CD.
– Infraestructura como código (IaC). La Infraestructura como código es una práctica muy útil, transversal a las fases de DevOps. Permite automatizar las necesidades de infraestructura para posibilitar el correcto funcionamiento del software. Mediante archivos de definición legibles por máquina, en lugar de configuración de hardware físico, se puede escalar de forma dinámica las necesidades de infraestructura del software publicadas. Un caso típico es la creación dinámica de un nuevo volumen de almacenamiento mediante Docker o Kubernetes, que será eliminado en cuanto deje de ser necesario. Esto no solo proporciona una agilidad en la escalabilidad del hardware nunca vista hasta ahora, también permite a los equipos de IT supervisar las configuraciones de los entornos activos, registrar los cambios y simplificar la reversión de las configuraciones ajustando los costes a las necesidades reales del momento.
Llegados a este punto queda claro que DevOps, lejos de ser una moda, ha llegado para quedarse y merece ser considerado como lo que es: un tratado de paz, colaboración y buenos propósitos entre desarrolladores y administradores de sistemas, para llegar a un bien común. La entrega de un software sin errores en el menor tiempo posible.
