“Muchas empresas existen debido a aplicaciones, lo que significa que el rendimiento de las aplicaciones es la medición más crítica fuera de los ingresos”, dice Chris Farrell, vicepresidente de Software de servicios de valor de automatización en IBM. “Cuando su aplicación es su empresa, la velocidad es tanto un arma como un proxy para la calidad de su aplicación”.

En este mundo de hiperdespliegues, Farrell dice que es fundamental que las organizaciones hagan un cambio en su forma de pensar acerca de lograr una integración continua y una entrega continua (CI/CD). “En lugar de hablar de la cantidad de días entre despliegues, debería hablar de la cantidad de actualizaciones por período de tiempo” dice. “Cuanto más corto sea el período de tiempo, más avanzará en la línea”.

La serie “Rethink & Automate” (Repensar y automatizar) de IBM invita a los líderes a reimaginar los procesos empresariales y de TI comunes abordándolos desde una perspectiva nueva y adoptando la automatización. El proceso típico de DevOps es un conjunto cíclico de ocho pasos: planificación, codificación, creación y pruebas, seguidos de lanzamiento, implementación, operación y monitoreo.  Cuando uno de los ocho pasos se ralentiza, todo el pipeline disminuye.

“Fuera del mundo "digital nacido", mejorar la velocidad puede ser aún más importante para las grandes empresas”, escribe Hans A.T. Dekkers de IBM en “The speed of smarter architecture”, un documento publicado por IBM Institute for Business Value. “Cuando vemos que la vida útil promedio de las empresas en el S&P 500 cae de 60 años (en la década de 1960) a menos de 20 años (hoy), con una tendencia acelerada hacia una rotación aún mayor, estamos viendo los efectos de tener –o no– velocidad”.

Descubra nuevas formas de mejorar su proceso de DevOps de TI en un taller gratuito de innovación en automatización.

Para lograr CI/CD, los desarrolladores deben crear una vez, desplegar en cualquier lugar y administrar la canalización constantemente. Así es como Farrell rediseñaría el ciclo típico utilizando la automatización, señalando que cualquier mejora requiere “un compromiso total con DevOps y el deseo de alcanzar y lograr una entrega continua”.

Pasar del seguimiento a la observabilidad

“Esto puede sorprender a la gente, pero si tuviera que rediseñar el proceso DevOps desde cero, mi primer enfoque sería el último paso: la monitorización”, afirma Farrell. “Hay que deshacerse de las herramientas del espacio de supervisión tradicional y pasar a la observabilidad lo antes posible. Recuerde, cuantas más cargas de trabajo aplique a la observabilidad, más rápida y precisa será la navegación de cualquier miembro de operaciones desde un problema hasta su causa raíz, sin necesidad de involucrar a desarrolladores y otros expertos en la materia”.

En TI, la observabilidad se refiere a herramientas y prácticas de software para agregar, correlacionar y analizar un flujo constante de datos de rendimiento de una aplicación distribuida, junto con el hardware y la red en los que se ejecuta, de modo que pueda solucionar problemas y depurar de manera más eficaz la aplicación y la red. La observabilidad es una evolución natural del monitoreo del rendimiento de las aplicaciones (APM) para abordar mejor la naturaleza cada vez más rápida, distribuida y dinámica de los despliegues de aplicaciones nativas de la nube.

Además del monitoreo, cada paso del proceso de DevOps ya cuenta con muchas herramientas que aceleran, integran y automatizan el proceso. “Las herramientas de monitoreo tradicionales luchan con los procesos acelerados y las pilas de tecnología modernas, específicamente porque la configuración, reconfiguración o redespliegue manual ralentizan las cosas”, dice Farrell. La plataforma de observabilidad ofrece comprensión (visibilidad con contexto) y se adapta a cualquier cambio en tiempo real, lo que significa que siempre está actualizada.

La observabilidad también vincula las aplicaciones y la infraestructura, algo necesario a medida que se difuminan las líneas entre el código de las aplicaciones, la infraestructura basada en código y las pilas de hardware. “Si piensa en la necesidad de velocidad en todo el pipeline, las plataformas deben ser tan flexibles y rápidas como el código de la aplicación en sí”, dice Farrell.

Automatice la observabilidad para obtener más velocidad y resultados

“La necesidad de ir a la observabilidad es absoluta, pero debe automatizarse”, dice Farrell. Una plataforma de observabilidad automatizada con un motor de análisis permite que la propia plataforma ofrezca comprensión, recomendaciones y corrección de problemas. Ya no tiene que dedicar tiempo a diagnosticar problemas; se hace automáticamente.

La automatización en todo el proceso de DevOps de TI proporciona una serie de otros beneficios más allá de la velocidad. La retroalimentación continua significa que los desarrolladores pueden tomar medidas de manera rápida y decisiva para mejorar continuamente. La detección de errores mejorada permite a los desarrolladores remediar antes de que los errores causan los impactos que Farrell describe como “catastróficos”. Y, por último, la integración del sistema mejora la colaboración en equipo, lo que permite a todos los profesionales de TI y DevOps de un equipo cambiar de código, responder a los comentarios y rectificar los problemas sin ralentizar a sus colegas.

Según el informe Accelerate: State of DevOps de DORA 2018 (el enlace se encuentra fuera de ibm.com), las “organizaciones con desempeño de élite” tienen implementaciones de código 46 veces más frecuentes, un tiempo de entrega 2555 veces más rápido desde el compromiso hasta la implementación, una tasa de falla de cambio 7 veces menor, y son 2604 veces más rápidos para recuperarse de incidentes. Se puede ver el beneficio exponencial de implantaciones más frecuentes que conducen a lanzamientos acelerados de nuevo software, y a resoluciones de incidencias miles de veces más rápidas. “Una de mis correlaciones favoritas es la reducción de la tasa de fallas de cambio, incluso a medida que se implementa más rápido”, dice Farrell.

Cuando las organizaciones automatizan los ocho pasos del proceso, pueden esperar una mayor calidad y una mejor satisfacción del cliente. Pero Farrell dice que su beneficio favorito es la velocidad. “Un ejemplo que vi estaba en un banco. Les llevaría aproximadamente de 10 a 12 meses tener una idea de un producto antes de su lanzamiento. Una vez que recibieron sus nuevos procesos de DevOps, ese plazo cambió a dos semanas”, dice. “Ves resultados absolutos y directos del éxito en el mercado”.