DevOps: Todo es cuestión de colaboración

A pesar de todas las metodologías que tenemos en TI, entregar un sistema a producción todavía es un acontecimiento de cuidado. Los desarrolladores se ponen nerviosos porque tienen la presión de entregar funcionalidad nueva lo antes posible. Por el otro lado, el equipo de operaciones, cuya responsabilidad es mantener los sistemas operando en producción se opone a los cambios porque sabe que estos pueden traer inestabilidad y tirar los sistemas. Así que cuando hay problemas, comienza la asignación de culpas: “es un problema de desarrollo”; “no, es un problema de operaciones.” ... esta escena se repite con frecuencia en la mayoría de las organizaciones.

El problema es amplificado por dos tendencias en la industria: el desarrollo ágil y el cómputo en la nube. Por naturaleza, el desarrollo ágil acoge el cambio y fomenta liberaciones pequeñas y frecuentes a producción. Esta mayor frecuencia agrega presión al equipo de operaciones, convirtiéndolo en un cuello de botella. Lo curioso es que aun cuando el desarrollo ágil fomenta la colaboración entre los interesados, la mayoría de los equipos ágiles no colaboran con el personal de operaciones. Los equipos de integración y pruebas, que tradicionalmente han funcionado como intermediarios entre desarrollo y operaciones, también están sintiendo la presión.

A su vez, el cómputo en la nube ha obligado a los equipos de operaciones a cambiar la forma en que administran la infraestructura. Las labores manuales ya no son posibles cuando estás lidiando con miles de máquinas. Si se va a estar liberando frecuentemente a producción, se requieren herramientas para soportarlo.

La virtualización facilita y acelera la creación de ambientes, y la nube elimina el problema de los recursos de cómputo. Lo que hace las cosas distintas es la capacidad de administrar la infraestructura y la gestión de configuración por medio de código. La infraestructura como código es el resultado de la infraestructura y plataformas como servicio (IaaS, Paas). La gestión de configuración por medio de código permite describir el estado deseado de la infraestructura por medio de lenguajes de dominio específico —utilizando herramientas como Chef y Puppet. Estos conceptos habilitan a los equipos de operaciones para automatizar gran parte de su trabajo —no solo el aprovisionamiento inicial de infraestructura, sino todo el ciclo de vida. Esto ha dado origen al concepto de “infraestructura ágil”.

Como resultado de estos factores ha surgido el concepto de DevOps, que busca eliminar las barreras entre desarrollo y operaciones. Algunos consideran que es una continuación del desarrollo ágil, ya que a fin de cuentas el software no genera valor si no está en producción.

En el contexto de DevOps, el equipo de operaciones es un miembro valioso del proceso de construcción de software. Esto permite que los requerimientos no funcionales tales como desempeño, estabilidad o respaldo sean discutidos al mismo tiempo que los requerimientos funcionales. Una vez que se logre un acuerdo, los equipos de desarrollo y operaciones colaboran para lograrlos desde un inicio, y no hasta que el sistema ya está “terminado”.

Cuando algo es dificil, hazlo con mayor frecuencia; la práctica hace al maestro. Conforme practiquemos más la liberación a producción, lo haremos mejor. Gracias a herramientas de automatización, los equipos de operaciones pueden liberar pequeños cambios de forma rápida y con mayor frecuencia. Liberar frecuentemente a distintos ambientes (desarrollo, pruebas, preproducción, producción) y utilizando el mismo conjunto de modelos de gestión de la configuración, nos ayuda a generar resultados predecibles y repetibles.

Bajo esta visión, parte de los entregables de un sistema de software, debe ser el proceso automatizado para liberar dicho software a distintos ambientes —incluyendo producción, por supuesto. Todos los cambios a un ambiente deben seguir el mismo proceso, independientemente de si lo que se está cambiando es código, infraestructura, o datos. Este concepto es lo que se conoce como el “deployment pipeline” y es la base de la entrega continua (continuous delivery).

Al igual que cualquier otro cambio, DevOps es un camino de descubrimiento, las personas y los procesos no se pueden cambiar de la noche a la mañana. Un patrón común en la adopción de DevOps es que los cambios organizacionales van de la mano de la introducción de nuevas herramientas. Una herramienta por sí sola no cambiará nada, lo primero que se necesita es un cambio en comportamiento, que a su vez genera un cambio de cultura. Es por ello que la adopción de DevOps requiere un fuerte apoyo del equipo directivo.

Muchos de los casos de éxito iniciales de DevOps se originaron en startups o empresas nativas de internet como Facebook o Amazon. Habrá quienes puedan pensar que DevOps solo es factible en empresas de este tipo, ya que en corporativos tradicionales regidos por modelos como CMMI e ITIL no habría lugar para DevOps. En realidad, las empresas tradicionales son las que tienen mayor necesidad de colaboración, y DevOps es a fin de cuentas tan solo una etiqueta para invitarnos a mejorar la colaboración. Es perfectamente posible adoptar prácticas de DevOps en contextos de ITIL y CMMI, y de hecho es recomendable ya que brinda una alineación natural entre TI y el negocio.