The Devops Handbook (1/4)

Autores: Gene Kim, Jez Humble, Patrick Debois, & John Willis

Estuve leyendo durante varias semanas el libro The DevOps Handbook. Considero que debería ser uno de los libros de cabecera de cualquiera que trabaje en el mundo del desarrollo de software, ya sea front, back, junior, senior, arquitecto o apagafuegos. Especialmente este último. Cualquier organización IT que le suene bien el término "value-driven" debería tomar muy en cuenta los principios DevOps.

Como se define en la wikipedia, DevOps es un conjunto de prácticas que combina el desarrollo del software y a las operaciones de IT para su despliegue y puesta en marcha. El libro entra a fondo en los detalles fundacionales que trataré de explicar en siguientes posts.

Para empezar, no es un perfil, ni es el nuevo título para un rol de operaciones, se trata de construir (de forma iterativa) una arquitectura de trabajo para que el desarrollo de software sea cada vez más ágil, fiable y seguro. Pasando del miedo a mover una especie de bomba en cada despliegue, a la seguridad de un entorno extremadamente robusto y amigable. Así como disponer de herramientas que facilitan el aprendizaje y la experimentación de todo lo que pasa en nuestro sistema.

En resumen implementar un pipeline de trabajo utilizando la automatización del trabajo repetitivo y eliminación de procesos que aportan muy poco, desde el desarrollo hasta producción, a través de testing continuo y monitorización. Participando en este pipeline todos los actores implicados en el proceso.

Una analogía que podemos ver en este vídeo de youtube.

DevOps se ha basado en los Principios Lean, la Teoría de las Limitaciones, el Sistema de Producción de Toyota, entre otras fuentes relativas al aprendizaje, ingeniería de resiliencia, seguridad psicológica en el trabajo, etc.

Una cadena de valor (término fundamental en DevOps) es sencillo de ver en los procesos una fábrica. En DevOps, una cadena de valor (tecnológica) consiste en convertir una hipótesis de negocio en un sistema tecnológico que entrega valor real al cliente de forma sistemática.

Fuente: winwire.com

Existe en muchas empresas un enfrentamiento tradicional de objetivos entre Desarrollo que pretende entregar nuevo software (valor), y Operaciones que quiere tener los entornos lo más estables y seguros posible (mantener). Existe así una frontera de facto entre lo que ocurre en desarrollo y lo que ocurre en producción, donde ni unos ni otros disponen de la visión completa de ese valor que se pretende entregar. Sin un buen alineamiento de incentivos y metas, cada equipo se centrará en sus propias metas.

Objetivo

El objetivo principal es reducir el tiempo de entrega de valor desde que se decide hasta que ya está a disposición del cliente, también llamado “lead time”. Esto se consigue orquestando un flujo del trabajo de desarrollo eficiente y muy automatizado, con una información inmediata de lo que está ocurriendo con nuestro código y disponiendo de un entorno robusto donde poder extraer fácilmente información y resultados de experimentación, aprendiendo así con los mínimos riesgos posibles.

La meta es conseguir un flujo altamente eficiente para el desarrollo: testing, despliegue y feedback inmediato del nuevo despliegue, permitiendo corregir o mejorar gracias al nuevo conocimiento adquirido de la observación en producción. Entendible rápidamente gracias a que el lead time es a corto plazo y no de meses o años. Un código escrito hace meses y que se despliega hoy es mucho más difícil de corregir las intenciones que uno reciente.

Una compañía con una implementación DevOps fuerte tendrá un equipo técnico de alto rendimiento, más satisfechos con su trabajo, con menos miedos ya que el entorno es más robusto y es más fácil de detectar problemas, y será rápido de arreglar en caso de que las cosas no vayan del todo bien. Los costes de los errores son mucho más asumibles gracias a una alta velocidad de resolución y un entorno más amigable para recolectar información y aprendizajes.

Estructura del libro

El libro se divide en 3 caminos (the three ways) que hay que recorrer:

• Primer camino: Principio de Flow
  Acelerar la entrega de valor al cliente.
• Segundo camino: Principio de Feedback
  Nos permite crear sistemas de trabajo cada vez más seguros.
• Tercer camino: Principio de Aprendizaje Continuo y Experimentación
  Fomentar una cultura de alta confianza y un enfoque científico para la mejora de los procesos.