Durante décadas, los equipos de desarrollo y de operaciones de las empresas estaban aislados. Mientras los desarrolladores creaban el software, desde operaciones lo probaban y desplegaban. Pero, en 2009, el consultor de IT Patrick Debois creó el término "DevOps", una fusión entre el desarrollo y las operaciones para mejorar las comunicaciones, establecer mejores prácticas y crear bucles de retroalimentación para que las organizaciones sigan mejorando el proceso general.

DevOps prometía reenfocar y reactivar profundamente a los equipos de software, mientras que los contenedores parecían una nueva e interesante forma de reagrupar los recursos que ya existían. Sin embargo, la aceptación de contenedores se está acelerando y la tecnología que organiza el uso de contenedores, Kubernetes, se describe habitualmente como revolucionaria. ¿DevOps? Casi tres cuartas partes de todas las organizaciones utilizan un plan de DevOps en la actualidad. Sin embargo, sólo el 11% de todos los encuestados en un estudio reciente de Garden están completamente satisfechos con sus configuraciones y flujos de trabajo de desarrollo, y creen que están funcionando tan bien como podrían. También, en un informe del DevOps Institute, más del 50% describió su camino de transformación de DevOps como "muy difícil".

¿Qué es lo que impulsa esta desilusión? ¿Es DevOps una buena idea sobre el papel, pero poco eficaz en la práctica? ¿El proceso de automatización de tareas está perdiendo el tiempo que los equipos podrían utilizar para la innovación creativa?

Una de las causas de los problemas del crecimiento de DevOps es nuestra tendencia a sobreestimar su papel. Subestimamos cuando no entendemos completamente el propósito y las capacidades de algo. Y tiene sentido que lo hagamos con los DevOps: su definición es imprecisa. Hay miles de organizaciones que los implementan, pero no hay dos que definan su papel exactamente igual. Antes de descartarlos, los equipos deben determinar claramente lo que significa para su organización, restablecer sus expectativas y desarrollar un plan de juego realista. Hay tres temas clave que hay que tener en cuenta al definir lo que DevOps pueden hacer.

Cambio cultural sostenido

Los seres humanos tienen una resistencia natural al cambio. Uno de los mayores obstáculos a la hora de implementar un DevOps eficaz es el cambio cultural, que incluye la escasez de habilidades y la escasa o nula automatización. Si bien los líderes pueden expresar su entusiasmo en el lanzamiento de este tipo de iniciativa, es el compromiso sostenido el que impulsará la eficacia a largo plazo. Para el informe Puppet 2021 State of DevOps, las organizaciones informaron sobre el punto en el que se encuentran en su viaje de DevOps: desde una evolución baja o media hasta una muy evolucionada. "Los desafíos relacionados con la cultura son más agudos entre las organizaciones de baja evolución, pero presentan bloqueos persistentes entre las empresas de evolución media. El 18% de los encuestados de alta evolución afirman que no tienen bloqueos culturales", según el informe.

Si los directivos no están comprometidos con una iniciativa de DevOps, los miembros del equipo pueden perder la concentración, lo que lleva a una disminución de la eficacia. Y si eso no funciona, a veces que un competidor nos gane la partida en el mercado es una forma eficaz de hacernos ver que debemos evolucionar para seguir siendo competitivos.

En curso, no en un estado final

Los departamentos a menudo se miden por su progreso en relación con los objetivos anuales. Para algunos, la implementación de un modelo DevOps podría ser uno de ellos. Sin embargo, no es un estado final ni su puesta en marcha significa la adopción del 100% de estrategias integradas y automatizadas. Algunos proyectos se adaptan mejor a un modelo más tradicional. Mantener ambas modalidades -desarrollo DevOps y tradicional- permite a los equipos beneficiarse de ambas.

No hay una línea de llegada. Más bien, DevOps es una herramienta más, al igual que Agile, SecOps y la entrega continua.

Crear por encima del cumplimiento

Otra frustración común es la tarea de conseguir y mantener los requisitos de cumplimiento detallados. Aunque existe una responsabilidad compartida entre el equipo de DevOps (que ejecuta las copias de seguridad) y el equipo de Platform Ops (que permite que se realicen las copias de seguridad), estos últimos son, en definitiva, los responsables del cumplimiento. Sí, DevOps es parte de ese proceso, pero su enfoque principal debe ser la creación.

Las organizaciones pueden alcanzar la productividad que DevOps promete definiendo claramente unas expectativas realistas. Aunque esto ha sido un reto en un entorno de trabajo remoto, tengo la esperanza de que, a medida que nos preparamos para volver a la oficina en cierta capacidad, habrá más oportunidades de colaboración ad hoc que catalizan el entusiasmo por DevOps, tanto entre los desarrolladores como en el liderazgo de la organización.

(*) Danny Allan: Vicepresidente de Estrategia de Producto de Veeam