Mejora del tiempo para obtener valor: proceso y paralelización

Hay un lamento común en la época navideña. Se grita desde lo alto de los tejados y desde debajo de las ramas espinosas de los pinos.

"¡Cuando una luz se apaga, todas se apagan!"

Éste es el grito de alguien que está atrapado con luces conectadas en un circuito en serie. No voy a extenderme en una conferencia sobre por qué sucede esto, pero basta con decir que una sola bombilla quemada es un factor de bloqueo.

Esto no es cierto para aquellos que tienen la suerte de tener luces conectadas en un circuito paralelo. Una bombilla puede fallar mientras las demás siguen encendidas intensamente.

¿Qué tiene esto que ver con el tiempo para obtener valor y con las aplicaciones? Todo. Porque resulta que la TI tradicional lleva a la producción por un circuito en serie, mientras que los modernos desarrollos de aplicaciones van siempre a toda mecha en un circuito paralelo.

Proceso

En un blog reciente , James Urquhart, director de tecnología de Pivotal Global Field, presenta un panorama importante de TI continua que se centra, apropiadamente, en el proceso sobre el producto. Él lo llama el Camino a la Producción.

La idea de un camino hacia la producción en realidad tiene que ver con el proceso y, para la TI tradicional, con la paralelización. Este concepto es fundamental para el desarrollo y las arquitecturas de aplicação modernas. La propia descomposición de las aplicaciones en componentes individuales y enfocados (a veces llamados microservicios) conduce naturalmente al desarrollo paralelo. Esto se debe a que equipos más pequeños trabajan en diferentes componentes al mismo tiempo. Esto, en última instancia, es lo que hace que Agile funcione como mecanismo para lograr mayor velocidad y disminuir el tiempo para obtener valor de las aplicações. No son equipos pequeños. No son aplicaciones más pequeñas. Es la paralelización que se logra aprovechando estos conceptos en el desarrollo y la entrega de aplicações.

El mismo enfoque se aplica al Camino hacia la Producción. Es decir, aquellos componentes de producción (servicios) necesarios para implementar la escala y garantizar la seguridad de las aplicações son parte de un proceso mucho más grande y algunos de ellos pueden desarrollarse y entregarse en paralelo.

Lo que se interpone en el camino es la TI tradicional. TI en serie. Metodologías de desarrollo en cascada que se extendieron al grupo de producción. Construimos redes como canales seriales porque los datos fluyen en serie a través de la red. Desde el enrutador hasta el firewall, el balanceador de carga, el servidor de aplicaciones y la base de datos. Los datos fluyen en una ruta predecible desde un extremo de la red al otro. Y así implementamos y entregamos esos servicios de aplicação de la misma manera: en un proceso predecible y serializado que sigue naturalmente la ruta de datos.

Esto ya no va a funcionar.

En primer lugar, porque ahora hay múltiples rutas de datos . No sólo las rutas de datos que recorren NS y EW, sino también aquellas que se desvían en otras direcciones cardinales. NE a una nube para recuperar un script. SW para recuperar sprites y fuentes web. WSE tomará un mapa y lo integrará en nuestra aplicación.

Pero no es sólo la distribución de rutas de datos lo que hace que hoy en día sea necesaria la paralelización del camino hacia la producción. Es la búsqueda de eficiencia y velocidad, también conocida como optimización.

Paralelización

Para alcanzar la velocidad necesaria para ejecutar las expectativas actuales en materia de valor, es necesario un desarrollo paralelo. No sólo en el desarrollo de aplicaciones, sino también en TI central. Si observamos la amplitud de los servicios de aplicação que utilizan las organizaciones hoy en día , podemos ver múltiples áreas en las que la paralelización puede ayudar a acelerar la implementación.

No es tanto que la TI tradicional esté aislada. Después de todo, el resultado de una arquitectura de microservicios son decenas o cientos de pequeños equipos aislados, cada uno de ellos centrado en un conjunto muy específico de funciones de aplicação . La TI tradicional ya está dividida en silos dentro de silos. El problema es que las prácticas de desarrollo ágiles fomentan el desarrollo paralelo dentro de sus silos, y la TI tradicional todavía sigue los procesos de producción de una manera metódica y serializada.

El problema es la transferencia entre equipos y la forma en la que reflejamos el tráfico de red en nuestro camino hacia la producción. No es un proceso serial y siempre que podamos paralelizar el desarrollo y la entrega de servicios deberíamos hacerlo.

Esto significa estructuras de equipo multifuncionales que fomenten la colaboración más temprano que tarde.

Al paralelizar procesos mediante la adopción de prácticas más ágiles en todas las áreas, las organizaciones pueden lograr mayor velocidad y eficiencia en su camino hacia la producción.

El proceso es el producto

Como alude James, el camino hacia la producción es realmente un proceso. Y los procesos se componen de pasos. Como cualquier ninja del proceso Six-Sigma cinturón negro le dirá, acelerar ese proceso consiste en encontrar y eliminar ineficiencias. En producción, esas ineficiencias aparecen como tiempos de espera (transferencias) entre pasos rígidos y serializados en el proceso de implementación.

Las herramientas pueden ayudar. Pero, en última instancia, la mejora requerirá una mirada larga y profunda a los procesos y una búsqueda de oportunidades para paralelizar la entrega de servicios de aplicação como parte de su camino hacia la producción.

La cultura –específicamente una cultura de colaboración– no es opcional. Tiene un impacto muy real en los comportamientos y las prácticas. La estructura del equipo por sí sola cambia drásticamente la automatización de los procesos de venta, y los equipos tradicionales de función única quedan rezagados frente a sus contrapartes contemporáneas impulsadas por DevOps. Impulsar estructuras de equipo más colaborativas. En esa misma línea, un equipo colaborativo debe estar alineado en cuanto a métricas clave. Las métricas compartidas permiten que NetOps y Security trabajen hacia una implementación continua sin penalizaciones. En la actualidad, casi tres cuartas partes de NetOps se miden en función del TIEMPO DE ACTIVIDAD DE LA RED. La frecuencia de despliegue apenas les preocupa. Se centrarán en mantener la red en funcionamiento porque eso es en lo que tienen que centrarse. Las métricas compartidas le dan a NetOps permiso para centrarse en lo que la empresa necesita: implementaciones más rápidas y frecuentes. 

Por último, se requiere empatía. Todos están en el mismo equipo y, quizá les sorprenda saberlo, valoran las mismas cosas. Es tan probable que NetOps le dé un alto grado de importancia a la automatización de pipelines como DevOps. Recuerde, DevOps tiene diez años de ventaja sobre NetOps en la navegación y superación de obstáculos relacionados con la integración, las herramientas y los conjuntos de habilidades. Los equipos colaborativos pueden ayudar promoviendo la estandarización de herramientas que abarcan desde la entrega hasta la implementación (como Jenkins y GitHub/GitLab).

El camino hacia la producción no es un producto. Es un proceso. Y es un proceso que debe ser colaborativo y realizarse en paralelo siempre que sea posible para mejorar el tiempo necesario para obtener valor y permitir implementaciones exitosas de aplicação .