La moda del DevOps y el peligro del hombre orquesta

Desde hace un par de años, el concepto de DevOps se ha puesto de moda… diría que, en los últimos meses, todavía más con anuncios como la reestructuración de Microsoft o el giro de estrategia de CA Technologies, que apuestan fuertemente por este paradigma.  En realidad, no hay nada de nuevo en este concepto DevOps, que para muchos nos es más que la colaboración de los departamentos de desarrollo y operaciones.

Para entender bien su significado e implicaciones, nos remitiremos a situaciones cotidianas: ¿En cuántas ocasiones, a la hora de lanzar un nuevo site, el equipo de sistemas va a poner el proyecto en producción, algo falla y tiene que acudir a los desarrolladores? Muchas. ¿Y qué responden éstos? Que en su máquina funciona… algo, por otro lado, que no resulta complicado considerando que no es lo mismo ejecutar código localmente en una sola máquina que liberarlo por completo.

Por otro lado, con mucha frecuencia son Sistemas los que frenan a Desarrollo. ¿Por qué? Porque los primeros buscan el rendimiento y la estabilidad y minimizarán cualquier riesgo adicional (que aportan los nuevos desarrollos) con tal de seguir aportando valor al negocio.

Para resolver este tipo de situaciones surge DevOps, que persigue eliminar los departamentos estancos en que históricamente han convivido Desarrollo y Sistemas. Sobre el papel, y aunque hay que tener cuidado de no perder foco y terminar creando un tercer silo (el de DevOps), todo suena muy bien. Imaginen, el bautizado como “desarrollo ágil”, que destierra al desarrollo en cascada –sobre todo con la llegada de entornos cloud, que requieren ciclos de desarrollo y puesta en producción mucho más cortos-, sacando partido de la colaboración y anteponiendo las personas a los procesos.

Un nuevo modelo que resuelve la nueva problemática del desarrollo de software, que ya no reside tanto en la creación como en garantizar que el software resultante funcione de inmediato en diversos sistemas operativos y plataformas. Precisamente por eso, tanto el testing como el despliegue se ejecutan ahora con mucha más frecuencia, aunque para que eso suceda es imprescindible que los desarrolladores se comuniquen regularmente con el equipo de operaciones y que éstos vuelquen sus conocimientos del entorno de producción al diseño de entornos de pruebas y puesta en marcha.

Los resultados hablan por sí solos: hay organizaciones que aseguran que mediante este modelo son capaces de desplegar código hasta 30 veces más rápido que sus competidores y, además, con un porcentaje de errores hasta un 50% menor. Así lo pone de manifiesto el último informe 2014 State of DevOps.

Demasiadas gorras para una sola cabeza

SinDominio_Navaja_SuizaEn un mundo ideal, la colaboración resuelve todos nuestros problemas, pero no es el caso. ¿Qué sucede en las grandes compañías? Que los roles están mucho más definidos y, con ellos, los silos que antes mencionábamos. Este es el motivo por el que resulta tan complicado poner en marcha una estrategia DevOps en este tipo de organizaciones.

Una posible receta para llevarla a buen término sería fijarse en el modelo de las más pequeñas, esto es, aumentar la responsabilidad de los desarrolladores que habrán de ponerse más gorras y, por supuesto, minimizar las capas de gestión. ¿Qué termina sucediendo? Que en lugar de primar la colaboración entre Desarrollo y Sistemas lo que se hace es crear desarrolladores-hombres orquesta, con demasiadas gorras sobre su cabeza para ser realmente eficientes. Ya saben… quien mucho abarca, poco aprieta.

Desde el punto de vista empresarial, más aún en España, los números les salen a los jefazos pues una persona asume el trabajo de tres por el mismo dinero. No hace falta ser ingeniero para ver los ahorros de esta política, pero sí para identificar sus repercusiones y es que, en último extremo, el empleado termina por ponerse cada vez menos la gorra de desarrollador o, en el mejor de los casos, de medio lado.

Una cosa es que se lleve a la práctica la filosofía que resumía hace unos años Werner Vogels, CTO de Amazon, con el “Tú lo construyes, tú lo pones en marcha”, y otra muy distinta es que termines sólo ante el peligro, pervirtiendo un modelo ideal en el que el hecho de que Sistemas y Desarrollo colaboraran mejoraba tanto la tecnología como la atención al cliente.

Esto nos lleva, inevitablemente, a que se haya creado un puesto concreto de DevOps. En redes sociales como LinkedIn las menciones de DevOps como habilidad se han ido incrementando exponencialmente y no debiera. Es una falacia pensar que hay una categoría específica de DevOps cuando, en realidad, las tres principales cualidades de este puesto deberían ser coding y scripting, reingeniería de procesos y comunicación y colaboración (predisposición de trabajar en equipo poniéndose diferentes sombreros). No se dejen engañar: la colaboración no es un puesto.

var dd_offset_from_content = 40;var dd_top_offset_from_content = 0;var dd_override_start_anchor_id = «»;var dd_override_top_offset = «»;

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *