Lectura del libro "The DevOps Handbook"

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.

Portada del libro

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 ahonda 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 un desarrollo de software cada vez más ágil, fiable y seguro. Pasando del miedo a tocar una especie de bomba, a la seguridad de un entorno extremadamente robusto y amigable. Así como una herramienta para el aprendizaje y la experimentación.

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

Una cadena de valor es sencillo verlo en las partes de una fábrica. En DevOps, una cadena de valor tecnológica consiste en convertir una hipótesis de negocio en un servicio tecnológico que entrega valor real al cliente.

Esquema de la cadena de valor en DevOps
Fuente: winwire.com

Existe en muchas empresas un enfrentamiento tradicional de objetivos entre Desarrollo que pretende entregar nuevo software, y Operaciones que quiere tener los entornos lo más estable y seguros posible. 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.

El objetivo es reducir al mínimo 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 con un flujo del trabajo de desarrollo muy automatizado, con una información inmediata de lo que está ocurriendo con nuestro código y con un entorno robusto donde poder extraer información y experimentar, aprendiendo así con los mínimos riesgos posibles.

La meta es disponer de un flujo muy eficiente para el desarrollo, testing, despliegue y feedback inmediato de las operaciones en producción, permitiendo corregir o mejorar gracias al nuevo conocimiento adquirido de la observación en producción. Modificaciones que se hacen en el corto plazo gracias a que el desarrollo es reciente, pues el flujo de trabajo será de días o semanas, 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 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 fácil de detectar problemas, y rápido de arreglar en caso de que las cosas no vayan del todo bien. Los costes de los errores son más asumibles gracias a la velocidad de resolución y sobre todo a los aprendizajes y medidas tomadas de cara al futuro.

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