¿Y si diseñara su proceso de DevOps de TI para una nueva empresa? ¿Qué automatizaría para hacer mejores predicciones y acelerar la entrega de aplicaciones?
Ver todos los capítulos
"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 servicios de valor de automatización en IBM. "Cuando su aplicación es su negocio, la velocidad es un arma y un proxy para la calidad de su aplicación."
En este mundo de hiperimplementación, Farrell dice que es fundamental que las organizaciones "cambien el guion" en la forma en que piensan en lograr la integración continua y la entrega continua (CI/CD). "En lugar de hablar sobre el número de días entre implementaciones, debe hablar sobre el número de actualizaciones por período de tiempo", dice. "Cuanto más corto sea el período de tiempo, más avanzarás en la línea".
La serie de IBM "Reimaginar y automatizar" invita a los líderes a reimaginar los procesos comunes de negocio y de TI enfocá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 monitorización. Cuando uno de los ocho pasos se ralentiza, toda la canalización se ralentiza.
“Fuera del mundo 'nacido digital', mejorar la velocidad puede ser aún más crítico para las grandes empresas establecidas", escribe Hans AT Dekkers de IBM en "La velocidad de una arquitectura más inteligente", un artículo publicado por el 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 carecer de, velocidad."
Descubra nuevas formas de mejorar su proceso de DevOps de TI en un taller gratuito de innovación de automatización.
Para lograr la CI/CD, los desarrolladores deben construir una vez, implementar en cualquier lugar y gestionar la canalización constantemente. Así es como Farrell rediseñaría el ciclo típico mediante la automatización, observando que cualquier mejora requiere "un compromiso completo con DevOps y un deseo de alcanzar y lograr la entrega continua".
Pasar de la monitorización a la observabilidad
"Esto puede sorprender a la gente, pero si rediseñara el proceso de DevOps desde cero, mi primer enfoque sería el último: la monitorización", dice Farrell. "Debe deshacerse de las herramientas del espacio de monitorizació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 las 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 de la monitorización del rendimiento de las aplicaciones (APM) para abordar mejor la naturaleza cada vez más rápida, distribuida y dinámica de las implementaciones de aplicaciones nativas de la nube.
Fuera de la monitorización, cada paso del proceso de DevOps ya tiene muchas herramientas que aceleran, integran y automatizan el proceso. "Las herramientas de monitorización tradicionales luchan con canalizaciones aceleradas y pilas tecnológicas modernas, específicamente porque la configuración manual, la reconfiguración y/o la reimplementación ralentizan las cosas", dice Farrell. La plataforma de observabilidad ofrece comprensión (visibilidad con contexto) y se ajusta 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 toda la canalización, las plataformas deben ser tan flexibles y rápidas como el propio código de la aplicación", dice Farrell.
Automatice la observabilidad para obtener más velocidad y resultados
"La necesidad de 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 otras ventajas más allá de la velocidad. El feedback continuo significa que los desarrolladores pueden actuar de forma rápida y decisiva para una mejora continua. Una mejor detección de errores permite a los desarrolladores corregirlos antes de que provoquen lo que Farrell describe como efectos "catastróficos". Y, por último, la integración de sistemas mejora la colaboración en equipo, permitiendo a todos los profesionales de TI y DevOps de un equipo cambiar el código, responder a los comentarios y rectificar los problemas sin ralentizar a sus compañeros.
También llamado "velocidad de entrega de software", un término para la velocidad de desarrollo y actualizaciones (y lo que las organizaciones deben centrarse en mejorar su proceso de DevOps)
El tiempo que tarda un programa informático (o cualquier actualización) en empezar a generar capital
Con qué eficacia puede responder una empresa (y sus aplicaciones asociadas) a los cambios en el entorno empresarial
Según el informe Accelerate: State of DevOps de DORA 2018 (enlace externo a ibm.com), las "organizaciones de élite" implementan el código 46 veces más a menudo, tardan 2555 veces menos desde que se confirma el código hasta que se implementa, tienen una tasa de fallos en los cambios 7 veces menor y se recuperan 2604 veces más rápido de los 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 fallos del cambio, incluso cuando 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. "Vi un ejemplo en un banco. Tardaría aproximadamente entre 10 y 12 meses en tener una idea de un producto antes de publicarse. Una vez que obtuvieron sus nuevos procesos de DevOps, ese período de tiempo cambió a dos semanas", dice. "Ve resultados absolutos y directos del éxito en el mercado".