Situando DevOps

Este es el primero de una serie de posts acerca de DevOps. La intención que tengo es la de compartir mi visión de DevOps y de cómo me organizo mentalmente para poner en práctica sus principios.

Antes de seguir: Qué es y qué no es DevOps

Antes de continuar me gustaría dejar una cosa clara: DevOps, como Agile o Lean, no es un puesto de trabajo y, desde luego, no es tecnología. Es una mentalidad, son valores y es cultura.

Una sola tarea en tres fases

Los que nos dedicamos a desarrollar software, ya sea porque trabajamos en una empresa de producto o en una empresa de servicios, tenemos que tener una cosa bien clara: nuestro trabajo consiste en entregar valor al usuario final.

Éste es nuestro objetivo y no otro: entregar valor. No es programar. No es hacer código bonito o mantenible. No es hacer specs ni aplicar patrones. Cuando a uno lo que le gusta es programar, escuchar (y decir) esto duele. Pero mientras el código no se exponga en museos el código por sí mismo no vale nada (o al menos nada más que unos esquemas escritos en papel).

Antes de que se ofenda nadie. No estoy diciendo que hacer buen código sea secundario. Sin duda el buen código tiene muchas ventajas. La mayor de todas, que nos permite seguir entregando valor a un ritmo razonable. Pero de esto hablaré en otro artículo.

¿Y cómo hacemos para entregar valor al usuario final en forma de código?

Pues como se ha hecho toda la vida con cualquier producto:

1. Se diseña
2. Se fabrica
3. Se envía al cliente

Fase de diseño

En esta fase es donde se conceptualiza el producto. Se hacen unos bocetos, algún prototipo que otro y cuando se aprueban estos diseños, se envían los “planos” a la cadena de montaje donde, obviamente, se ensamblará todo.

Es la fase en la que diseñamos nuestras interfaces Es donde pensamos qué estructuras de datos vamos a necesitar y cómo se van almacenar. Es donde definimos un lenguaje común que nos permita comunicarnos unos con otros de forma efectiva. También es cuando definimos las especificaciones de nuestro producto.

Ésta es la fase en la que, en última instancia, tiramos líneas de código. Y digo “en última” porque el código es el resultado de todo lo anterior, no el principio. El código es el diseño que enviaremos a nuestra cadena de montaje.

Fase de fabricación

En esta fase se fabrican las piezas que hemos diseñado, se prueban, se ensamblan, y se prueban en conjunto.

Puede que nuestro producto se componga de una sola pieza o que sea un producto más complejo que se componga de miles de piezas diferentes.

Ésta es la fase en la que hacemos el build, y el testing.

Sí. En términos de DevOps, estamos hablando de Integración Continua, junto con alguna tarea más como la de Q&A.

Fase de envío

Ya tenemos nuestro producto montado (salvo que seamos IKEA) y listo para entregar al cliente. Ya sólo queda enviarlo.

Cuando hablamos de software, la entrega se hace con el famoso pase a producción. Origen de pesadillas y/o insomnio de muchos equipos de desarrollo.

Tres fases, un equipo

Hasta hace poco, la práctica más extendida en las empresas era separar la fase de diseño (programación) y la de fabricación y envío (operaciones).

Esto intuitivamente podía tener sentido por dos razones:

1. Estábamos copiando un modelo de producción de productos físicos que funcionaba
2. Se necesitan disciplinas diferentes para estas fases (programación y desarrollo frente a administración de sistemas)

Sin embargo, esto ha producido muchísimos dolores a la hora de entregar el producto (o valor) al usuario final: pases a producción interminables en forma de cuadernos de carga, equipos encargados de poner en producción código que no habían hecho ellos y, lo que es peor, hecho sin tener en cuenta las restricciones de los diferentes entornos (acceso restringido a servicios, máquinas “justitas”, dificultad a la hora de instalar dependencias…)

Es por esto que la primera regla de oro de DevOps es trabajar como un equipo único en toda la cadena de construcción: desde el diseño hasta la entrega.

Esto se consigue con los tan de moda equipos multidisciplinares, que también da para varios artículos, así que no voy a entrar en este tema.

Entonces ¿DevOps es producir más rápido?

Sí y no (típica respuesta de Schrödinger)

En realidad esto que acabo de describir es lo que, según el whitepaper de Docker se conoce como primera vía de docker y que consiste, resumidamente, en entender el sistema como un flujo que va de izquierda a derecha Y que recibe el nombre generalizado de pipeline (sí, el famoso pipeline de tu servicio de integración continua favorito){: .external-link target=”_blank”}.

La velocidad, como ya veremos más adelante, es fundamental en DevOps, pero no es el único requisito. De momento quedémonos con que, como en cualquier cadena de producción, la velocidad siempre es positiva.

En los siguientes artículos de esta serie, profundizaré en conceptos relacionados con esta primera vía. Entre ellos la velocidad.

Más adelante iré introduciendo la segunda vía (o como amplificar los ciclos de feedback){: .external-link target=”_blank”}

Y por último veremos la tercera vía (o cómo todo lo que hacemos en realidad es un pequeño experimento){: .external-link target=”_blank”}.

Conclusiones

• DevOps es cultura, valores y mentalidad
• El objetivo es entregar valor, no hacer código. El código por sí mismo no tiene valor.
• Podemos dividir la entrega de valor en tres fases:
  • Fase de diseño (programación)
  • Fase de fabricación y pruebas (integración continua)
  • Fase entrega (despliegue a producción)
• Tenemos que completar estas tres con un solo equipo
• Esta forma de entender el sistema es lo que se conoce como la primera vía de DevOps según la gente de Docker.