Integración de monolitos con microservicios

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Existe la creencia fantasiosa de que se puede coger un monolito, meterlo en un contenedor y, ¡voilà!, obtener las ventajas de escalabilidad y velocidad de una arquitectura moderna.

De hecho, una encuesta de KubeCon de 2018 indicó que eso es exactamente lo que ocurre con cerca del 55 % de los encuestados, quienes afirmaron que utilizan contenedores «como sustitutos de las máquinas virtuales para las aplicaciones existentes». Otras encuestas muestran que una cantidad significativa de aplicaciones Java de nivel empresarial se ejecutan en contenedores. Una encuesta de Diamanti de 2018 reveló que, aunque la mayoría (54 %) utilizaba contenedores para aplicaciones nativas de la nube, casi un tercio (31 %) los empleaba para modernizar aplicaciones heredadas.

Los motivos citados suelen ser de carácter operativo; los contenedores se consideran más fáciles de gestionar, pese al enorme aumento del número de componentes que deben administrarse. El rendimiento y los costes de las licencias también suelen influir en la decisión de adoptar contenedores.

Pero ese cambio no es tan sencillo como empaquetar una aplicación heredada y colocarla en un contenedor.

La realidad es que los monolitos —las aplicaciones web y cliente-servidor tradicionales— presentan ciertas características que dificultan su migración directa a un contenedor y el aprovechamiento de las ventajas operativas. Los contenedores y los microservicios no van necesariamente de la mano, pero ambos se rigen por los principios de «diseñado para fallar» en los que se basa la disponibilidad de las aplicaciones modernas. Por si no está familiarizado con este principio, consiste en que, si un contenedor falla, basta con iniciar otro que lo sustituya. Todos los contenedores son ganado y cualquiera sirve igual que otro.

En las arquitecturas de aplicaciones sin estado diseñadas expresamente para ser modernas, eso es cierto. En las arquitecturas tradicionales de aplicaciones con estado, no tanto.

Como ve, las aplicaciones cliente-servidor y sus sucesoras, las aplicaciones web de tres niveles, suelen tener estado. Conservan en una sesión determinada información sobre la interacción entre un cliente y la aplicación. Esa sesión puede almacenarse en la memoria del servidor web o de aplicaciones, o bien en una base de datos independiente. Independientemente de dónde se almacenen esos datos, son los que hacen que la aplicación tenga estado. Estos datos son relevantes e importantes para el funcionamiento de la aplicación. Contienen su carrito de la compra, la última página que visitó y otra información específica de la aplicación.

Como puedes imaginar, si el servidor web o de la aplicación donde se almacena esa información desaparece de repente, la experiencia del cliente se ve afectada negativamente. Mi carrito ha desaparecido. Tengo que volver al punto en el que estaba. Básicamente, tengo que empezar de nuevo.

Este comportamiento es diametralmente opuesto a los principios arquitectónicos modernos, que eliminan el funcionamiento con estado de las aplicaciones. La naturaleza sin estado de las aplicaciones y los servicios modernos permite sustituir sin problemas una instancia por otra cuando algo falla. Es la base sobre la que funciona el principio de «diseñado para fallar». Si se vuelve a introducir el estado en esa ecuación, de repente todo se viene abajo.

Aunque la aplicación seguirá funcionando, el usuario queda en el limbo. Su flujo se interrumpe y sus transacciones desaparecen en el vacío para no volver a verse jamás.

Este problema dio lugar a la necesidad de que los servicios de aplicaciones respetaran el estado. Una vez que un cliente se conectaba a una aplicación o servidor web concreto, tenía que seguir conectándose al mismo durante toda la sesión. Se desarrollaron la persistencia mediante cookies y otros mecanismos para garantizar que las solicitudes se dirigieran siempre al mismo servidor. Para conservar el estado.

La realidad es que, a menos que se trate de una startup de nueva creación, ahora mismo tiene en funcionamiento tanto aplicaciones tradicionales como modernas. Aunque los estudios sobre el tema varían, el reparto «63 % de aplicaciones heredadas / 37 % de aplicaciones nuevas» se mantiene bastante estable a lo largo del tiempo. Esto significa que debe admitir simultáneamente arquitecturas heredadas y modernas.

Trasladar sin más el monolito a un contenedor no servirá de nada si no se ha abordado la separación entre los componentes con estado y sin estado.

ESTRATIFICACIÓN ARQUITECTÓNICA

La mejor manera —o, al menos, la más sencilla— de gestionar la migración de monolitos a un entorno de contenedores es garantizar que se pueda seguir respetando el estado incluso en la anarquía sin estado de un clúster de contenedores. Para ello, se necesita cierta inteligencia en el extremo del clúster, en el punto de entrada donde el tráfico N-S se cruza con el E-W.

Un enfoque de dos niveles permite adoptar modelos operativos tanto tradicionales como modernos, así como migrar aplicaciones tradicionales con estado a un entorno de contenedores. Al aprovechar F5 Container Ingress Services (CIS), los equipos de NetOps pueden seguir atendiendo las necesidades de las aplicaciones con estado durante su migración a entornos de contenedores. Esta conectividad garantiza que los métodos tradicionales de equilibrio de carga que emplean persistencia puedan seguir funcionando y dirigir las solicitudes al contenedor adecuado o directamente a un entorno tradicional.

Mientras tanto, BIG-IP puede dirigir simultáneamente las solicitudes de aplicaciones y API modernas a un controlador de entrada dentro del clúster de contenedores para distribuirlas entre tantos contenedores sin estado como sea necesario.

Las transiciones llevan tiempo

La realidad es que la mayoría de las organizaciones mantienen hasta cinco arquitecturas de aplicaciones claramente diferenciadas, desde aplicaciones monolíticas y móviles hasta microservicios. Mantener simultáneamente un número similar, pero diferenciado, de modelos de red y operativos acabará sin duda por desbordar a los equipos de operaciones y anular las ventajas de adoptar arquitecturas y entornos modernos. Un enfoque estratégico de dos niveles permite a las organizaciones aprovechar las ventajas operativas y empresariales de ambos modelos durante la transición hacia un entorno mayoritariamente basado en contenedores.

OPCIÓN DE REFACTORIZACIÓN

Una de las medidas que puede adoptar para facilitar esta transición es refactorizar las aplicaciones heredadas para aprovechar las sesiones compartidas. Estas sesiones se almacenan en una ubicación independiente del servidor web o de aplicaciones —normalmente, algún tipo de base de datos— y cualquier servidor web o de aplicaciones puede acceder a ellas con el identificador de sesión adecuado. Aun así, tendrá que realizar un seguimiento del identificador de sesión, pero por lo general esto puede hacerse mediante una cookie que persiste independientemente del estado del servidor web o de aplicaciones. Si las aplicaciones heredadas aún no utilizan un modelo de sesiones compartidas, refactorizarlas para que lo hagan es un proceso relativamente sencillo en comparación con migrar toda la aplicación a otra plataforma.

Dado que estas transiciones llevan tiempo —al fin y al cabo, hoy en día casi todos seguimos operando con un modelo multinube—, es importante identificar y aprovechar opciones arquitectónicas que maximicen las ventajas sin comprometer necesidades esenciales de los clientes, como la disponibilidad y la seguridad. Un enfoque arquitectónico de dos niveles ofrece ambas cosas sin limitar los esfuerzos de contenerización.

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