Integrar los monolitos con microservicios

Existe la creencia fantasiosa de que se puede tomar un monolito, ponerlo en un contenedor y ¡voilá! Beneficios arquitectónicos modernos de escala y velocidad.

De hecho, una encuesta de KubeKon 2018 sugirió que eso es exactamente lo que está sucediendo para aproximadamente el 55% de los encuestados que indicaron que aprovechan los contenedores "como reemplazo de máquinas virtuales para aplicaciones existentes". Otras encuestas muestran una cantidad significativa de aplicações Java (de clase empresarial) que se ejecutan en contenedores. Una encuesta de Diamanti de 2018 mostró que, si bien la mayoría (54 %) usaba contenedores para aplicaciones nativas de la nube, casi un tercio (31 %) los usaba para modernizar aplicações heredadas.

Las razones aducidas son generalmente operativas: los contenedores se consideran más fáciles de gestionar, a pesar de la explosión de partes móviles que deben gestionarse. Los costos de desempeño y de licencia también suelen ser factores que influyen en la decisión de seguir adelante con los contenedores.

Pero ese movimiento no es tan simple como envolver una aplicación heredada y colocarla en un contenedor.

La realidad es que los monolitos (cliente-servidor tradicionales y aplicaciones web) tienen ciertas características que dificultan su levantamiento y traslado a un contenedor y el aprovechamiento de los beneficios operativos. Los contenedores y los microservicios no son mutuamente incluyentes, pero ambos se inclinan hacia los principios de "diseñado para fallar" sobre los que se basa la disponibilidad de las aplicaciones modernas. Ese principio, si no lo conoces, es que si un contenedor falla simplemente se inicia otro para ocupar su lugar. Todos los contenedores son ganado y uno es tan bueno como el otro.

En arquitecturas de aplicação deliberadamente modernas y sin estado, esto es cierto. En las arquitecturas de aplicação con estado tradicionales, no tanto.

Como puede ver, el cliente-servidor y su sucesor, la aplicación web de tres niveles, generalmente son con estado. Mantienen cierta información sobre la interacción entre un cliente y la aplicación en una sesión. Esa sesión podría guardarse en la memoria de la aplicación o del servidor web, o en una base de datos separada. Independientemente de dónde se almacenen esos datos, es lo que hace que la aplicación tenga estado. Estos datos son relevantes e importantes para el funcionamiento de la aplicación. Incluyen tu carrito de compras, la última página que visitaste y otra información específica de la aplicación.

Puedes imaginar que si el servidor web/aplicación donde se almacena esa información desaparece de repente, interrumpe negativamente la experiencia del cliente. Mi carrito se ha ido. Tengo que navegar de nuevo hasta donde 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 una aplicação. Es la naturaleza sin estado de las aplicaciones y servicios modernos lo que hace posible sustituir sin problemas una instancia por otra cuando algo sale mal. Es la base sobre la que funciona el modelo “construido para fallar”. Si introducimos nuevamente el Estado en esa ecuación, de repente todo se desmorona.

Si bien la aplicación seguirá funcionando, el usuario quedará en el limbo. Su flujo se interrumpe, sus transacciones se transportan al inframundo y nunca más se las vuelve a ver.

Esta cuestión es la que dio lugar a la necesidad de que los servicios de aplicação respeten el estado. Una vez que un cliente se conectaba a una aplicación o servidor web en particular, tenía que conectarse a esa misma aplicación o servidor web durante toda la sesión. Se desarrollaron la persistencia de cookies y otros mecanismos para garantizar que las solicitudes se enrutaran al mismo servidor en cada ocasión. Para preservar el estado.

La realidad es que, a menos que seas una startup desde cero, tienes aplicações tradicionales y modernas ejecutándose en este momento. Si bien las investigaciones varían según el tema, la división de "63 % de aplicaciones heredadas / 37 % de aplicaciones nuevas" se mantiene en gran medida constante a lo largo del tiempo. Lo que significa que es necesario dar soporte tanto a arquitecturas antiguas como modernas al mismo tiempo.

Simplemente mover el monolito a un contenedor no servirá de nada si no se ha abordado la división entre con estado y sin estado.

NIVELES ARQUITECTÓNICOS

La mejor manera (o al menos la más sencilla) de gestionar la migración de monolitos a un entorno en contenedores es asegurarse de poder respetar el estado incluso en la anarquía sin estado de un clúster de contenedores. Esto requiere cierta inteligencia en el borde del cúmulo, en el punto de entrada donde N-S se encuentra con E-O.

Un enfoque de dos niveles admite enfoques operativos tanto tradicionales como modernos, así como la migración de aplicaciones tradicionales con estado a un entorno en contenedores. Al aprovechar F5 Container Ingress Services (CIS), NetOps puede seguir satisfaciendo las necesidades de las aplicações con estado que migran a entornos en contenedores. La conectividad garantiza que los métodos tradicionales de equilibrio de carga que emplean persistencia puedan seguir funcionando y dirigir las solicitudes al contenedor correcto o directamente a un entorno tradicional.

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

Las transiciones toman tiempo

La realidad es que la mayoría de las organizaciones admiten hasta cinco arquitecturas de aplicação claramente diferentes: desde monolitos hasta dispositivos móviles y microservicios. Dar soporte simultáneamente a un número igual pero distinto de modelos operativos y de red seguramente abrumará las operaciones y anulará los beneficios de migrar a arquitecturas y entornos modernos. Un enfoque estratégico de dos niveles permite a las organizaciones aprovechar los beneficios operativos y comerciales de ambos modelos mientras realizan la transición a un entorno mayoritariamente contenerizado.

OPCIÓN DE REFACTORIZACIÓN

Una de las cosas que puede hacer para facilitar esta transición es refactorizar las aplicaciones heredadas para aprovechar las sesiones compartidas. Estas sesiones se llevan a cabo en una ubicación separada del servidor web/aplicación (generalmente algún tipo de base de datos) y cualquier servidor web/aplicación con la identificación de sesión adecuada puede acceder a ellas. Todavía necesitarás realizar un seguimiento del identificador de la sesión, pero eso generalmente se puede lograr a través de una cookie que persiste independientemente del estado del servidor web/aplicación. Si las aplicaciones heredadas aún no usan un modelo de sesión compartida, la refactorización para hacerlo es un proceso bastante sencillo en comparación con cambiar la plataforma de toda la aplicación.

Debido a que estas transiciones toman tiempo (después de todo, hoy en día casi todos operamos en un modelo de múltiples nubes), es importante encontrar y aprovechar las opciones arquitectónicas que maximicen los beneficios sin comprometer las necesidades centrales de los clientes, como la disponibilidad y la seguridad. El uso de un enfoque arquitectónico de dos niveles proporciona ambas cosas sin limitar los esfuerzos de contenerización.