Explorando DevOps: calidad, rapidez y cultura
Movimientos recientes como las arquitecturas de microservicios o serverless han facilitado la labor a los desarrolladores en la creación de nuevas aplicaciones, dando la falsa sensación de que las operaciones ya no son necesarias en el sistema (el cada vez más frecuente hashtag #NoOps).
La libertad de elección tecnológica, tan importante para la mejora continua de los sistemas, ha hecho que las tecnologías involucradas en la concepción de un proyecto pase de la decena en 2011 a más del triple en 2016. En un contexto como el actual las operaciones no desaparecen, más bien al contrario: la orquestación de herramientas y procesos se vuelve fundamental para afrontar la sobrecarga operacional de la infraestructura.
DevOps es una palabra clave en el mundo actual: todas las empresas quieren hacer DevOps, dicen utilizar tecnologías DevOps o forman equipos DevOps. Linkedin estalla con multitud de ofertas a DevOps y, sin embargo, poca gente sabe realmente lo que implica para la organización.
DevOps es un movimiento que pretende mejorar la entrega de producto focalizándose en las interacciones entre las personas y la información sobre el sistema completo, por encima de los procedimientos o las tecnologías, eliminando así los típicos problemas entre los diferentes roles involucrados en la entrega de producto. Un eslógan bastante descriptivo de la filosofía DevOps es “People over Processes over Tools”.
Con esto se pretende romper con los objetivos disjuntos que tradicionalmente se han asignado a los diferentes roles del ciclo de desarrollo de producto (por ejemplo, el equipo de desarrollo, impulsado por las metodologías ágiles, consigue entregas más rápidas pero el de operaciones, al que se le premia por altos SLAs, busca que el entorno productivo no cambie). Así, con DevOps se persigue un objetivo común en toda la cadena de producto: entregas más rápidas y de calidad.
No hay una sola forma correcta de implementar DevOps, pero sí podríamos decir que no es un rol ni un equipo nuevo, ni tampoco un nuevo conjunto de tecnologías. No estamos haciendo DevOps sólo por automatizar un proceso o por crear un nuevo equipo. De hecho, probablemente, con esta última opción sólo consigamos lo contrario a lo que pretende el movimiento: crear un nuevo cuello de botella, un nuevo silo.
Entre las ventajas de este movimiento se podrían indicar:
- Reducción del time to market
- Mejoras en la calidad del producto
- Mejoras en la comunicación entre equipos
- Expansión de cultura buscando un objetivo común
- Inversión de tiempo en tareas que aporten valor
La tormenta perfecta
A muchos les sonarán los objetivos y las técnicas que se aplican en un contexto DevOps. Y es que esta forma de trabajo nace de la convergencia de varios movimientos y prácticas enfocadas a mejorar la entrega de producto. Entre ellas, se pueden citar el movimiento Lean, el movimiento Agile (de hecho, muchos de los momentos clave en la historia DevOps parten de conferencias Agile), el movimiento de Continuous Delivery o el de Toyota Kata.
La aparición de los libros The Phoenix Project (2013) y DevOps Handbook (2016), escritos por las personas más influyentes del movimiento, han mostrado un camino de implantación DevOps basado en tres vías. La primera (systems thinking) implica pensar en la cadena del producto como un sistema completo, eliminando silos y cuellos de botella independientemente de los roles. La segunda (amplify feedback loops) persigue extraer información del sistema y desplazarla a otros puntos del mismo para mejorar los canales de comunicación entre los diferentes roles.
Con eso se busca la transparencia y la responsabilidad conjunta en el proceso completo, implicando a todos los roles desde el principio del proceso. Por último, la tercera vía (culture of continuous experimentation and learning) se basa en abrazar el cambio, aprender del error y buscar la mejora continua. Esto favorece la innovación y la toma de riesgos para mejorar los procesos.
Qué esperar del movimiento DevOps
Hasta el momento, DevOps parecía un movimiento destinado a las empresas “unicornio”, pero el tiempo indica que, si una compañía quiere ser disruptiva y puntera y entregar de manera más rápida y fiable a sus clientes ha de adoptar modelos que permitan la expansión de una cultura empresarial basada en el feedback positivo y la automatización: fallar rápido y barato, eliminar errores manuales, incrementar la comunicación entre los involucrados en el sistema.
Técnicas como infraestructura como código, integración continua, la automatización de la gestión de la configuración, los despliegues blue-green o la concepción del pipeline de entrega continua del sistema completo han venido para quedarse y será difícil concebir un nuevo producto sin ellas.
La adopción de pipelines como código parece el siguiente paso lógico en la cadena de valor para crear un modelo de responsabilidad conjunta dentro del producto y favorecer el feedback entre los diferentes roles del proceso.
En ese sentido, este año se puede celebrar la aparición de DevOps Express, el esfuerzo de varias de las compañías que diseñan soluciones integradas en un pipeline típico (Atlassian, Cloudbees Jenkins, Chef, Puppet, Sonar, Jfrog Artifactory, etc.) para crear una solución integrada y que siga las mismas buenas prácticas.
La implantación real de DevOps requiere un cambio global en las empresas.
Aún quedan muchos retos por explorar. Este año parece clave para la adopción generalizada del movimiento y para ello es necesario pensar en un cambio global en las empresas: dedicar tiempo específico a requisitos no funcionales o a la innovación, buscar diferentes topologías de equipos que favorezcan el flujo de información en el sistema o la expansión de una cultura de empresa que favorezca la pertenencia.
Para lograr todo eso, es necesario establecer un conjunto de métricas que validen si los cambios introducidos están mejorando los procesos. Ya no sirven sólo los SLAs o las métricas de calidad. Medidores como el Lead Time (tiempo que tarda un commit desde que se define la funcionalidad hasta que llega a producción), MTTR (tiempo medio de recuperación de servicio), MTBF (tiempo medio entre fallos), número de despliegues o tasa de errores en los despliegues van a ser fundamentales si no se quiere malinterpretar el movimiento: la creación de un nuevo rol que automatice los sistemas pronto se convertirá en un nuevo silo más si no va acompañado de un cambio global en la organización. Éste es el momento, tenemos una oportunidad. Abracemos la mejora continua.
