La Arquitectura de Nube Híbrida Parte 2: Modernización

Estrategias para modernizar aplicaciones monolíticas o legacy en la nube híbrida

Introducción

Hola a todos, mi nombre es Sai Venom y soy un desarrollador experto en IBM. En esta segunda parte de la serie de arquitectura de nube híbrida, vamos a discutir estrategias para modernizar aplicaciones monolíticas o legacy. En la primera parte de esta serie, hablamos sobre la conectividad en la nube híbrida y utilizamos una aplicación de ejemplo llamada Stock Trader. En esta ocasión, retrocederemos en el tiempo cuando Stock Trader aún era una aplicación monolítica que se ejecutaba en infraestructura local en máquinas virtuales, aunque la arquitectura es en su mayoría la misma y utiliza una arquitectura orientada a servicios (SOA). Básicamente, dentro del monolito, podemos imaginar que se trata de una aplicación basada en Java EE, que consta de una interfaz de usuario (UI) que interactúa con el portafolio, administra diferentes carteras y realiza un seguimiento de los precios de las acciones. Para obtener esos precios, la aplicación se comunica con un servicio que consulta la API REST pública del mercado de inversión. Todos estos datos e información del portafolio se almacenan en una base de datos local, y también hay servicios adicionales, como uno de lealtad que monitorea acciones específicas en su cartera y notifica a los usuarios a través de una cola de mensajes que utilizan servicios de correo electrónico. Así que esa es una descripción general muy simple de la arquitectura y ha funcionado muy bien para esa ficticia compañía Stock Trader.

Problemas con la aplicación monolítica

La compañía ha notado que ciertos usuarios que utilizan esta aplicación están experimentando una mayor latencia, por lo que los arquitectos de Stock Trader decidieron que era hora de deshacerse del monolito y comenzar a aprovechar la nube pública. Pero, ¿cómo pueden lograr eso?

Paso 1: Identificar la parte a separar del monolito

El primer paso en el proceso de descomposición es identificar la parte que queremos separar del monolito. Algunas ideas que podemos considerar son, por ejemplo, no mover el servicio de portafolio a la nube pública porque está demasiado conectado con otros servicios y trasladarlo podría generar problemas de rendimiento para los usuarios. Sin embargo, la mejor parte para separar sería la interfaz de usuario (UI) o el front-end, ya que nos permite colocarlo en múltiples ubicaciones geográficas. Aquí es importante aclarar que la UI no solo es un componente front-end, sino también el backend que realiza llamadas al resto de los servicios para obtener y renderizar los datos. Por lo tanto, creemos que la UI es una excelente opción para comenzar, ya que nos permitirá comenzar de forma más pequeña y prepararnos para una futura descomposición.

Paso 2: Refactorizar

No podemos simplemente mover la parte de la UI del monolito a la nube pública, ya que la comunicación entre estos servicios no funciona bien a través de internet público debido a las llamadas basadas en software que se realizan dentro de la arquitectura SOA y la plataforma Java. Necesitamos aprovechar algo como REST, que funciona mejor sobre internet público. Por lo tanto, lo primero que debemos hacer es crear «código de unión» o «glue code», esencialmente, crear puntos de acceso a los cuales la UI pueda acceder al portafolio, así como exponer puntos finales de API REST para el portafolio y el servicio de lealtad para que la UI pueda acceder a ellos directamente. Esto es lo que llamamos «código de unión» porque nos permite mantener la misma ruta de comunicación entre los servicios, pero habilita su funcionamiento sobre internet público. Así que este es nuestro segundo paso, refactorizar.

Paso 3: Desplegar

Luego de realizar la refactorización, podemos proceder a desplegar la UI en la nube pública. Básicamente, necesitamos exponer un punto de acceso para acceder a ella y, al mismo tiempo, asegurarnos de que la antigua ruta de acceso a la UI desde el monolito en la infraestructura local continúe funcionando correctamente. Esto nos permitirá verificar que el «código de unión» que implementamos no esté causando problemas y, al mismo tiempo, podemos iniciar una prueba con un enfoque gradual. Por ejemplo, podemos dirigir solo el 10% del tráfico de usuarios hacia la UI en la nube pública, mientras que el resto se mantiene en la infraestructura local. Esto nos permitirá detectar cualquier problema en producción y garantizar que la UI en la nube pública esté libre de errores antes de redirigir todo el tráfico de usuarios hacia ella.

Paso 4: Repetir

Una vez que hayamos logrado separar con éxito una parte del monolito y llevarla a la nube pública, podemos comenzar a pensar en las siguientes partes que deseamos separar. Por ejemplo, podríamos optar por escalar el servicio de precios de las acciones aprovechando la escalabilidad de la nube pública. Una forma de hacerlo sería utilizando una plataforma de «serverless» y llevando la función de obtener precios de las acciones a ese entorno. Al seguir estos cuatro pasos (identificar, refactorizar, desplegar y repetir), podemos continuar modernizando nuestras aplicaciones monolíticas y cosechar los beneficios de una arquitectura en la nube híbrida.

Resumen

En resumen, hemos discutido las estrategias para modernizar aplicaciones monolíticas o legacy en la nube híbrida. A través de la descomposición del monolito, la migración a la nube pública y la mejora continua, podemos lograr una arquitectura más flexible, escalable y eficiente. Como siempre, estamos abiertos a recibir comentarios y sugerencias, así que no dudes en dejar un comentario a continuación. En la siguiente parte de esta serie de arquitectura de nube híbrida, hablaremos sobre seguridad, así que asegúrate de suscribirte y estar atento. Si deseas obtener más información sobre lo que hemos discutido hoy, consulta la sección de información relacionada a continuación. ¡Gracias!

Tabla de Resumen

Preguntas Frecuentes (FAQs)

1. ¿Por qué es importante modernizar las aplicaciones monolíticas?

R: Modernizar las aplicaciones monolíticas permite aprovechar las ventajas de la nube híbrida, como la escalabilidad, flexibilidad y eficiencia, lo que se traduce en una mejora en la experiencia del usuario y un mejor rendimiento de la aplicación.

2. ¿Cómo puedo determinar qué parte del monolito debo separar?

R: Una buena opción es identificar la parte que tiene dependencias mínimas con otros servicios y que se beneficia más al ejecutarse en la nube pública, como la interfaz de usuario (UI).

3. ¿Qué es el «código de unión» o «glue code»?

R: El «código de unión» es una capa de código que se crea para permitir la comunicación entre los servicios que se están separando del monolito y los demás servicios, especialmente cuando la comunicación a través del internet público es necesaria.

4. ¿Por qué es importante realizar pruebas en producción?

R: Las pruebas en producción nos permiten detectar problemas y errores que pueden ocurrir en un entorno real. Al dirigir solo un porcentaje del tráfico de usuarios hacia la nueva implementación en la nube pública, podemos verificar su rendimiento y corregir cualquier problema antes de implementarlo por completo.

Conclusión

En conclusión, la modernización de aplicaciones monolíticas en la nube híbrida es un proceso que requiere estrategias adecuadas y un enfoque gradual. Al seguir los pasos de identificar, refactorizar, desplegar y repetir, podemos lograr una transición exitosa y aprovechar los beneficios de una arquitectura más flexible y escalable. No dudes en consultar nuestros artículos relacionados para obtener más información sobre este tema y otros aspectos de la arquitectura en la nube híbrida. Gracias por leer y ¡hasta la próxima!

– Equipo de TodoForti.net

Mila y César

Hola, somos Mila Jiménez y César Sánchez. Dos apasionados de la ciberseguridad con muchos años de experiencia. Hemos trabajado en muchas empresas del mundo TI y ahora nos apetece compartir nuestro conocimiento con cualquiera que lo necesite.

¡Si te gusta nuestro contenido puedes invitarnos a un café AQUÍ!