Comentando el libro: DevOps y el camino de baldosas amarillas

En esta ocasión comentamos el libro: DevOps y el camino de baldosas amarillas de José Juan Mora Pérez.

Lo bueno de ser el CEO (hiperactivo) de una empresa es que puedes elegir (aunque no siempre) el tema y nivel de profundidad al que te quieres dedicar en distintas épocas de tu vida.

En esta época me he enredado personalmente a acompañar algunas empresas en la adopción de metodologías ágiles. Aunque siendo más preciso, y sin posiblemente ellos saberlo, es una transformación de la organización hacia una estrategia más digital.

Encima de una mesa en un cliente vi el libro DevOps y el camino de baldosas amarillas y a poco hábil que seas, has de leer los libros que lean tus clientes. 😉

Me ha durado poco, un par de días, por lo que puedo decir que se lee con facilidad. Para mi gusto el autor se ha mojado poco a modo “esto es un marco y usa el sentido común”. 😉

Dice cosas interesantes:

Es mejor comprender el comportamiento de un sistema y entender cómo puede fallar, que gastar tiempo y dinero en intentar solucionar los problemas duplicando y repitiendo. Los fallos son intrínsecos de los sistemas complejos: la única forma de mitigarlos es con el conocimiento.

Es habitual que el proceso de evangelización DevOps dentro de la compañía se inicie desde el área de desarrollo, ya que culturalmente suelen ser menos reacios a adoptar nuevas formas de trabajo.

Las organizaciones con sistemas estancados adquieren la cultura de adoptar sus procesos al sistema y no al contrario. Este enfoque condiciona la estrategia de negocio en función del rendimiento del sistema.

Mucha gente confunde DevOps con Agile. La principal diferencia es que DevOps no es una metodología, mientras que la cultura ágil se basa en distintos tipos de metodología (dale tiempo que ya verás la cantidad de certificaciones y frameworks de escalado aparecen. 🙂

IT ha evolucionado de una manera exponencial, lo que ha supuesto un desfase entre la creación de normas y la aparición de nuevas tecnologías. Este desfase genera problemas a la hora de aplicar a negocio aquellas tecnologías que acaban de aparecer en el mercado.

Las tres vías DevOps son:

  • Entender el sistema como un todo (evitando fronteras).
  • Incrementar el feedback.
  • Experimentación / aprendizaje continuo.

Es un error pensar que DevOps tiene como objetivo solucionar los problemas de tecnología. Tiene que resolver los de negocio. Esto se hace patente viendo el perfil buscado de experto en DevOps como un catálogo de conocimientos en productos y técnicas y no en habilidades.

DevOps es una caja de herramientas varias y se pueden meter en esa caja (aquí es donde digo que se moja poco 😉 ): automatizar, gestionar las configuraciones, despliegue automático, gestión de logs, gestión de rendimiento, gestión de la capacidad, escuchar, hablar y compartir.

El principal problema que podemos encontrar en el proceso de automatización es que focalicemos todo el esfuerzo en el proceso en sí y no tengamos en cuenta la relación con el resto de elementos y procesos del sistema.

Se suele malinterpretar el concepto de rendimiento: proporción entre el producto o el resultado obtenido y los medios utilizados. Se suele confundir velocidad con rendimiento.

Tiene que haber un equilibrio entre calidad y tiempo de entrega.

Comenta la agresividad que se respira en muchos departamentos. Mi pregunta es: ¿y quién consiente esto?

Uno de los puntos más destacados del libro es acerca de la comunicación.

Propone no cambiar la estructura del departamento de IT para la implantación de DevOps (esto me ha sonado conservador 😉 ). También recomienda no montar un equipo de DevOps (aunque yo si recomendaría una task-force para que alguien tenga la responsabilidad de empujar, pese al día a día).

Termina hablando de cómo Dorothy llevaba unos zapatos mágicos y golpeándolos 3 veces podrá haber vuelto a Kansas. No vale absolutamente de nada tener la herramienta más potente del mercado, cuando no tenemos conocimiento suficiente para usarla.

Tenemos que agradecer al autor el esfuerzo de escribir el libro y seguro que muchos responsables de tecnología lo encontrarán como lectura inspiradora.

Cómpralo en Amazon

He de decir que se podría ampliar la visión del libro:

  • En amplitud: porque para mi operación no es sólo operación en tecnología. 😉
  • En profundidad: porque no describe un modelo (aun advirtiendo que es sólo eso) de cómo puede funcionar en una organización con DevOps (incluyendo herramientas).

Por eso trato de complementar (en pocas palabras, más o menos): 🙂

Una empresa del pasado puede funcionar así:

    • Las áreas de negocio (marketing, comercial, estrategia digital) se pueden creer muy listas y definir un nuevo producto pensando en qué es lo que sus clientes pueden demandar.

 

    • Hacen una definición vaga de lo que desean y se lo pasan a tecnología para que haga una evaluación del coste/impacto. Con un poco de suerte se definen una experiencia de usuario. Con poco tiempo, poca información y, muchas veces, con poco conocimiento técnico (por la externalización masiva) tienen que dar un precio y fecha, cosa que incluso a veces ya viene condicionado. El fallo no se contempla como una opción.
 
    • Los usuarios de negocio están alejados de los desarrolladores (no tienen tiempo o involucración suficiente) y pasan meses hasta que se entrega una primera versión. Normalmente es poco satisfactoria y, por la presión de la entrega, con muchos errores, donde la calidad se ha dejado de lado. Pasan semanas hasta que hay una entrega estable y medianamente satisfactoria, con un sobrecoste por el esfuerzo y el tiempo perdido en salir de mercado.
 
    • De arquitectura e infraestructura de sistemas “se ha pasado” casi hasta el momento final. Por lo que están cabreados y con falta de visión del impacto y tiempo para adquirir el conocimiento en las nuevas tecnologías.
 
    • Los equipos de desarrollo no tienen muy claro cuál es el objetivo y valor de negocio de muchas cosas que hacen. Tampoco tienen en cuenta que lo que hagan tiene que dejar herramientas para que el equipo de sistemas o las áreas de negocio sepan qué ha pasado ante un fallo.
 
  • Entregada la solución, hay una labor de formación a soporte, operaciones de negocio (como middle office) y comercial (las verdaderas operaciones a nivel de negocio).

Por tanto, se tardan meses desde que se conceptualiza algo y se obtiene feedback de cliente. Y, ¿cómo puede funcionar una empresa del futuro? Vamos a intentar pasar al extremo contrario e imaginemos qué tendría que pasar para que todos los días se pusiera en marcha nueva funcionalidad a los departamentos de negocio. ¿Cómo se enterarían? Imaginad un Web. ¿Cómo capitalizarían el conocimiento de las incidencias tan rápidamente, etc.?

    • Primero, negocio debería invitar a gente ajena a la organización a definir producto. Hay expertos externos, profesores de escuelas de negocio, etc. que ven muchas cosas distintas. Además, con conocimientos sistemáticos de definición de productos (inception).
 
    • Esta visión se debería contrastar con clientes finales para no pensar por ellos.
 
    • Se debería comunicar la visión interna y crear un equipo común entre negocio, tecnología, operaciones, etc. Desde el principio se debería permitir el fallo: falla rápido, falla barato.
 
    • A priori no se sabrá ni el coste final ni el alcance concreto, aunque se podrá tener un marco.
 
    • Hay que trabajar con gente competente, motivada y cualificada donde el día a día demuestra su implicación y calidad. No hay que medir después porque luce cada día.
 
    • Aquí ya compras empieza a sufrir porque, ¿ahora ¿a quién aprieta en precio?
 
    • Se debería definir una lista sobre las prioridades de los elementos por valor a negocio.
 
    • Desarrollo y negocio debe tener una comunicación continua para definir, probar, validar y pivotar.

 

    • Se debería documentar el comportamiento como parte del entregable (guía de usuario), casos de prueba automáticos de regresión (para garantizar los escenarios) y mecanismos de comunicación (FAQ y tablón o similar) para que el área de operación sepa cuál es la nueva funcionalidad que se va a poner en marcha, qué aspecto tiene, cómo venderla y cómo actuar si un cliente llama por teléfono. Quedaría feo que los usuarios supieran más que los operadores.
 
  • Desarrollo y otras áreas de sistemas (infraestructuras / comunicaciones / operación) tienen que trabajar todavía más cerca para definir los criterios de calidad del software, mecanismo de pruebas (TDD / funcionales), homogeneidad de logs, mecanismos de monitorización y alarmas, entornos y pases entre ellos. Todavía más compleja es la gestión de la configuración e integración del código en elementos con múltiples dependencias (como microservicios).

Por tanto, la comunicación es la pieza más importante, pero tenemos que mojarnos en soluciones artísticas (comunicación) y tecnológicas de referencia y de facto al tipo (sólo pongo algunos enlaces a cosas que tenemos):

Organización del Desarrollo:

Integración continua:

Construcción de entornos / virtualización:

Monitorizar aplicaciones en tiempo real:

Calidad de software

Creedme que lo que veo más fácil es cambiar a tecnología (aunque también hay mucho Cio-Saurio 🙂 ) porque el cambio más grande está en aceptar este nuevo “ritmo” y compromiso por negocio.