Contenerización. Los problemas de las aplicaciones monolíticas.

 Desde la perspectiva de los administradores de sistemas, estoy asistiendo dentro de una organización una migración de plataforma de aplicaciones desde un entorno "on-premise" a un entorno contenerizado. 

Esta migración se está realizando más para eliminar el sustrato de tecnologías consideradas legacy, como los servidores físicos, como los servidores virtualizados y los clúster donde se alojan. Entiendo que estos movimientos obedecen en el primer caso a la obsolescencia del hardware, o en el segundo a la necesidad de renovar este hardware y software a plataformas más potentes con licencias de productos con mayor estabilidad y nuevas características que mejoran la resiliencia de los clústeres construidos, aunque a costa de no poder reutilizarse hardware por cuestiones de licenciamiento. 

En este proceso no se acomete, que es lo deseable, una revisión del aplicativo que sigue en su modelo monolítico con la división de servicios proveedores de: autenticación de usuarios, persistencia de datos, y consumo de apis genéricas de la organización. En modo alguno se revisa que el servicio pase a un formato sin estado del componente, y que se ejecute peticiones a API de forma asíncrona entre servicios. 

Las aplicaciones escalan en capacidad de procesamiento debido a que los clústeres son de mayor capacidad y esta además se usa de forma elástica, por la naturaleza del servicio de contenedores que establece límites a las aplicaciones desplegadas en sus consumos de memoria y cpu, de forma que se entrega (hasta el limite establecido) capacidad de calculo y memoria al proceso del aplicativo.

Es por ello que en muchos casos se observa un doble fracaso por el éxito de las apps, por un lado tenemos aplicaciones desarrolladas en Php que se comportan bien a nivel de código pero que por el lado de la gestión de las conexiones de bases de datos son ineficientes, deben de cambiar el modelo de explotación del dato. 

Por el lado de las aplicaciones de Java el problema es más complejo, y esto es debido a que el diseño de las mismas implica el establecimiento de un consumo máximo de la memoria HEAP del proceso que establece una memoria mínima dedicada a la aplicación , esto supone de por si un handicap porque ya no existe una asignación dinámica de la memoria, no asi de la cpu. Y que supone que el escalado de la aplicación es bastante dificil ya que esta no libera memoria dinámicamente según el uso sino que se apropia de segmentos de memoria, si o si. Por otro lado los mecanismos de persistencia de sesión, se dejan (al contrario que las aplicaciones basadas en Php) en manos de los servicios que con su manejo de la coordinación de datos entre los diferentes pod impiden un crecimiento horizontal de la aplicación. 

Los desarrolladores tienen que enfocar que el ciclo de vida de una sesión puede ser atendido por n procesos de su aplicación que les llegan peticiones unitarias por cada iteracción del usuario con su aplicativo. Estos procesos deben de conocer, por algún mecanismo, la validez de la sesión pero deben de evitar que los objetos construidos para gestionar la petición que atienden sean permanentes en la medida de lo posible. Por ello, entiendo, que una aplicación basada en lenguaje de script que crea y destruye objetos en memoria de forma dinámica es más integrable que una aplicación que crea objetos en memoria que son mucho más costosos de construir/destruir. Es por ello que el concepto de microservicios es un éxito en aplicaciones contenerizadas porque construir/destruir los mismos no supone un gran coste por ser livianos en sus consumo de recursos. 

Revisando el panorama de desarrollo de las apps más conocidas, por ejemplo: Wordpress; no observo esta conversión al modelo del microservicio. No conozco, y seria deseable, una distro de los componente que gestiona monolíticamente el código de Wordpress desglosado en servicios que podríamos resumir en:

• un componente de autenticación, validación
• un componente de publicación, 
• un componente de consulta de los contenidos, 
• un componente de comentarios, 
• un componente de subida de contenidos estáticos, 

Con este modelo el dar el salto de un WP multisite desde un entorno on-premise monolítico a uno de microservicios, con las ventajas de que si consiguen romper la seguridad de un componente no comprometen la seguridad del resto del código y la seguridad, a mi juicio, seria más consistente. Ya que solo conseguiría, una vez burlado el código, subir al microservicio en cuestión el código que NO le permitiría alterar el buen funcionamiento del portal. Solo podrían, a priori, modificar la API de ese microservicio de forma que pudieran alterar las peticiones con más campos para que se comportara de una u otra manera, pero con WAF (ya fuera un Apache con su modulo de seguridad) inspeccionando las peticiones, eso ya estaría muy controlado. 

En resumen, la mejor solución desde el mundo de los microservicios pueden dar a estas aplicaciones es la modularidad, escalabilidad, seguridad, y aislamiento, así como un proceso de parcheado más fácil ya que afecta solo a los microservicios comprometidos o mejorables.