Cómo acelerar la obtención de valor: procesos y paralelización

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Hay un lamento habitual en Navidad. Se oye desde lo alto de los tejados y bajo las ramas espinosas de los pinos.

«Cuando se apaga una luz, ¡se apagan todas!»

Este es el grito de alguien que tiene unas luces conectadas en un circuito en serie. No me extenderé explicando por qué ocurre esto; basta con decir que una sola bombilla fundida impide que las demás funcionen.

Esto no les ocurre a quienes tienen la suerte de contar con luces conectadas en un circuito en paralelo. Una bombilla puede fundirse mientras las demás siguen brillando intensamente.

¿Qué tiene que ver esto con el tiempo de obtención de valor y las aplicaciones? Todo. Porque, como resulta evidente, la TI tradicional avanza hacia la producción en un circuito en serie, mientras que el desarrollo de aplicaciones modernas funciona a pleno rendimiento las veinticuatro horas en uno en paralelo.

Proceso

En una entrada reciente del blog, el director de tecnología de campo global de Pivotal, James Urquhart, presenta una importante visión de las TI continuas que, acertadamente, se centra en el proceso por encima del producto. La denomina «Camino a producción».

La idea de una ruta hacia producción gira realmente en torno al proceso y, en el caso de las TI tradicionales, a la paralelización. Este concepto es fundamental para el desarrollo y las arquitecturas de aplicaciones modernas. La propia descomposición de las aplicaciones en componentes individuales y específicos (a veces denominados microservicios) conduce de forma natural al desarrollo en paralelo. Esto se debe a que equipos más pequeños trabajan simultáneamente en distintos componentes. En última instancia, esto es lo que hace que Agile funcione como mecanismo para aumentar la velocidad y reducir el tiempo de obtención de valor de las aplicaciones. No se trata de equipos más pequeños. No se trata de aplicaciones más pequeñas. Se trata de la paralelización que se consigue al aprovechar estos conceptos en el desarrollo y la entrega de aplicaciones.

El mismo enfoque se aplica a la ruta hacia producción. Es decir, los componentes (servicios) de producción necesarios para implementar la escalabilidad y garantizar la seguridad de las aplicaciones forman parte de un proceso mucho más amplio, y algunos de ellos pueden desarrollarse y entregarse en paralelo.

Lo que se interpone en el camino son las TI tradicionales. Las TI secuenciales. Las metodologías de desarrollo en cascada que acabaron extendiéndose al entorno de producción. Construimos las redes como canales secuenciales porque los datos fluyen de forma secuencial a través de ellas: del router al cortafuegos, al balanceador de carga, al servidor de aplicaciones y a la base de datos. Los datos siguen una ruta predecible de un extremo de la red al otro. Por eso, implementamos y entregamos esos servicios de aplicaciones del mismo modo: mediante un proceso predecible y secuencial que sigue de forma natural la ruta de los datos.

Eso ya no va a funcionar.

En primer lugar, porque ahora hay múltiples rutas de datos. No solo las rutas de datos que van de norte a sur y de este a oeste, sino también las que se desvían hacia otros puntos cardinales. Hacia el noreste, a una nube para obtener un script. Hacia el suroeste, para obtener sprites y fuentes web. Hacia el oeste-sureste, para obtener un mapa e integrarlo en nuestra aplicación.

Pero no es solo la distribución de las rutas de datos lo que hace necesaria hoy en día la paralelización del proceso de puesta en producción. También lo es la búsqueda de eficiencia y velocidad, es decir, la optimización.

Paralelización

Para alcanzar la velocidad necesaria para cumplir las expectativas actuales en cuanto al tiempo de obtención de valor, es necesario desarrollar en paralelo. No solo en el desarrollo de aplicaciones, sino también en los sistemas informáticos centrales. Si observamos la amplitud de los servicios de aplicaciones que utilizan actualmente las organizaciones, podemos identificar varias áreas en las que la paralelización puede ayudar a acelerar la implementación.

No es tanto que las TI tradicionales estén organizadas en silos. Al fin y al cabo, una arquitectura de microservicios da lugar a decenas o cientos de pequeños equipos aislados, cada uno centrado en un conjunto muy específico de funciones de la aplicación. Las TI tradicionales ya son silos dentro de otros silos. El problema es que las prácticas de desarrollo ágil fomentan el desarrollo en paralelo dentro de sus silos, mientras que las TI tradicionales siguen encadenando los procesos de producción de forma metódica y secuencial.

Lo problemático es el traspaso entre equipos y la forma en que replicamos el tráfico de red durante el proceso de puesta en producción. No es un proceso secuencial y, siempre que podamos, debemos desarrollar y entregar los servicios en paralelo.

Eso implica estructuras de equipos multidisciplinares que fomenten la colaboración desde el principio.

Al paralelizar los procesos mediante la adopción de prácticas más ágiles en todos los ámbitos, las organizaciones pueden lograr una mayor rapidez y eficiencia en su camino hacia la producción.

El proceso es el producto

Como señala James, el camino hacia la producción es, en realidad, un proceso. Y los procesos se componen de pasos. Como le dirá cualquier ninja de los procesos con cinturón negro en Six Sigma, acelerar ese proceso consiste en detectar y eliminar ineficiencias. En producción, esas ineficiencias se manifiestan como tiempos de espera (traspasos) entre pasos rígidos y secuenciales del proceso de despliegue.

Las herramientas pueden ayudar. Pero, en última instancia, para mejorar será necesario examinar los procesos detenidamente y buscar oportunidades para ejecutar en paralelo la entrega de servicios de aplicaciones como parte de su ruta hacia la producción.

La cultura —en concreto, 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 del pipeline, y los equipos tradicionales dedicados a una única función se quedan atrás frente a sus homólogos actuales, orientados a DevOps. Impulse estructuras de equipo más colaborativas. En esa misma línea, un equipo colaborativo debe estar alineado en torno a métricas clave. Las métricas compartidas permiten que NetOps y Seguridad trabajen para lograr el despliegue continuo sin penalizaciones. En la actualidad, casi tres cuartas partes de los equipos de NetOps se evalúan en función del TIEMPO DE ACTIVIDAD DE LA RED. La frecuencia de despliegue apenas cuenta para ellos. Se centrarán en mantener la red operativa porque eso es en lo que deben centrarse. Las métricas compartidas permiten a NetOps centrarse en lo que necesita la empresa: despliegues más rápidos y frecuentes.

Por último, se necesita empatía. Todos formáis parte del mismo equipo y, aunque os sorprenda, valoráis las mismas cosas. Es tan probable que NetOps conceda una gran importancia a la automatización de los pipelines como DevOps. Recordad que DevOps lleva diez años de ventaja a NetOps a la hora de sortear y superar obstáculos relacionados con la integración, las herramientas y las competencias. Los equipos colaborativos pueden ayudar promoviendo la estandarización de herramientas que abarquen desde la entrega hasta el despliegue (como Jenkins y GitHub/GitLab).

El camino hacia la producción no es un producto, sino un proceso. Y es un proceso que debe ser colaborativo y llevarse a cabo en paralelo siempre que sea posible para acelerar la obtención de valor y garantizar el éxito de los despliegues de aplicaciones.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie