DevOps, más allá de la automatización

El mundo de la tecnología también se mueve por tendencias globales; estas, en la mayoría de los casos, llegan tarde a países latinoamericanos como Colombia. Hasta hace apenas 2 años comenzamos a hablar con seriedad de DevOps, pero hace 10 años ya estaba acuñado el término mundialmente.

En muchas ocasiones la innovación nos llega en una ola que se comporta igual que cualquier moda; algún apasionado comienza a hablar de un nuevo termino como SOA, agilismo, microservicios, contenedores, cloud, etcétera, y pronto este se extiende entre las compañías. En algún punto esto se vuelve la norma y si no estas al día con ello no eres competente y tu compañía está out.

El manejo que se le suele dar a estas tendencias termina por desvirtuar los conceptos que originalmente buscaban solucionar problemas reales.

Lastimosamente el manejo que se le suele dar a estas tendencias termina por desvirtuar los conceptos que originalmente buscaban solucionar problemas reales, dejándolos en simplemente un elemento más de la jerga tecnológica.

Donde sea que vayamos, las empresas de tecnología engrosan su portafolio hablando de cómo usan DevOps y, en las propuestas que se presentan a los clientes, se incluye como un valor agregado o diferenciador del servicio, sin embargo, nos topamos de frente con que de lo único de lo que se habla es del uso de ciertas herramientas y de la automatización, de pipelines, repositorios de código y de artefactos, automatización de pruebas, infraestructura como código, configuración como código, integración continua, despliegue continuo y muchos otros conceptos, que si bien son indispensables para implementar DevOps, no son DevOps en sí mismos, recordemos que “el todo es más que la suma de las partes” Aristóteles.

“Wall of Confusion”

DevOps es un conjunto de prácticas destinadas a reducir el tiempo entre el compromiso de un cambio a un sistema y la puesta a producción de este cambio, al tiempo que garantiza una alta calidad.

Como resultado de esta tergiversación es muy común ver proyectos en los que tras una gran inversión y un gran despliegue de tecnologías tienen como mayor logro ‘un desorden automatizado’, han logrado caer en los mismos problemas un poco más rápido, el “wall of confusion” sigue intacto.

Parafraseando al libro «DevOps: A Software Architect’s Perspective» de los autores Len Bass, Ingo Weber y Liming Zhu, ‘DevOps es un conjunto de prácticas destinadas a reducir el tiempo entre el compromiso de un cambio a un sistema y la puesta a producción de este cambio, al tiempo que garantiza una alta calidad’. Estas prácticas son más que el uso de herramientas, están enfocadas en la cultura que busca salir del modelo de “silos de trabajo”, donde grupos aislados de personas, sin poder de decisión, velan sólo por una parte del proceso y dirigirse hacia los equipos multidisciplinarios, autosuficientes y empoderados que garantizan el proceso de extremo a extremo.

DevOps

Reduce tiempos y errores humanos, garantiza trazabilidad y reproducibilidad, pero sin un cambio cultural, el verdadero valor de DevOps no podrá ser trasladado a los clientes, estaremos acelerando a fondo en una vía con muchas curvas y baches en lugar de hacerlo sobre la autopista, al final veremos que frenar para maniobrar, nos cuesta más de lo que pensamos.

En conclusión, ¿Debemos aplicar Devops por completo o no hacer nada?

La respuesta es obvia, no es cuestión de extremos. DevOps no es un destino, es un camino y este se debe iniciar por algún lado, sin embargo, si como compañía no se quiere hacer este recorrido y asumir todos los retos que esto implica, podríamos empezar por usar mejores términos: podríamos decir que tenemos desarrollo e infraestructura ágil o automatización “end-to-end” y así evitar usar de manera errada este concepto.

Autor: Andrés Lavado – Arquitecto Cloud