Blog de Amazon Web Services (AWS)
Cómo migrar monolitos en Mainframe a Microservicios de AWS con Blu Age
Por Alexis Henry, Chief Technology Officer en Blu Age
Los monolitos en mainframe han crecido a lo largo de los años con una complejidad abrumadora. A menudo mezclan diferentes lenguajes, estándares 
de codificación, repositorios de datos con varias interfaces, procesos en línea y en batch, y millones de líneas de código.
Con Amazon Web Services (AWS), los clientes puede usar microservicios para usar tecnología ágil, elástica y de pago por uso.
En esta publicación, describimos las soluciones de Blu Age para descomponer un mainframe con características monolíticas a microservicios de AWS, y cómo resolver los desafíos de datos asociados con dicha migración.
Blu Age es un Socio Tecnológico Avanzado del AWS Partner Network (APN). Nuestras soluciones son adecuadas para migrar un monolito de mainframe, para descomponer un mainframe en una solución híbrida, y para migrar incrementalmente algunas partes de sus cargas de trabajo del mainframe a AWS.
Patrones de Migración de Mainframe
La migración de microservicios de un monolito de mainframe puede ser un desafío porque la plataforma de origen y los lenguajes de programación asociados no están orientados a servicios u objetos. Tampoco promueven un fácil intercambio de datos externos, ni llamadas a procedimientos remotos.
Los monolitos de mainframe han acumulado millones de líneas de código con muchos estilos y estándares de programación. Eso significa que el análisis de código automatizado y las capacidades de transformación asociadas son críticas para el éxito, esto permite ajustar rápidamente las diferencias principales entre la arquitectura de mainframe y las plataformas distribuidas.
Para entregar proyectos de migración de mainframe, las soluciones Blu Age permiten tres patrones diferentes mediante el uso de la tecnología Blu Age Analyzer. Según la carga de trabajo o el tamaño y la complejidad del monolito, se pueden combinar uno o varios patrones para cubrir la mayoría de las situaciones.
Blu Age Analyzer ha sido diseñado específicamente para identificar cada patrón y crear una estrategia general para migrar cualquier aplicación monolítica.
Migrar con Servicios Independiente de datos
Este es un patrón favorable donde el servicio extraído y el monolito tienen integración con datos independientes. Los programas se agrupan en un dominio, formando los límites del microservicio. Los límites de dominio se definen alrededor de interfaces de bajo acoplamiento, como transferencia de archivos, colas de mensajes, reportes y consultas de Business Intelligence (BI).
El modelo de datos es estrictamente consistente dentro de cada dominio, dentro del almacén de datos monolítico restante y dentro del almacén de datos del microservicio. Se extrae un microservicio independiente de datos y se mueve a AWS.
Figura 1 – Migración con servicios independientes de datos.
Migrar con Consistencia Eventual de Datos
Este es un patrón donde hay dependencias de datos entre el servicio extraído y el monolito. Los datos se replican en el mainframe y AWS. Esto evitaría latencia o fluctuaciones en la red, lo que sería inmanejable para programas de mainframe en batch con uso intensivo de I/O, o perjudiciales para transacciones backend de alto throughput en línea .
Un servicio con dependencia de datos es extraído y migrado a AWS, y los datos dependientes se replican asincrónicamente en ambos sentidos en tiempo real. Debido a la replicación asincrónica bidireccional, existe una consistencia eventual de los datos. Para la resolución de conflictos, en función del análisis de la carga de trabajo y los tipos de acceso, se pueden adoptar estrategias como “mainframe-as-a-reference” o “Last Write Win”.
Figura 2 – Migración con consistencia eventual de datos.
Agrupar y luego Migrar con Consistencia Estricta de Datos
Cuando hay demasiadas dependencias de escritura o requisitos de transaccionalidad fuertes, la consistencia eventual puede convertirse en un desafío. En este patrón, los grupos de programas y sus dependencias de datos se mueven por completo para preservar una consistencia estricta.
Los programas dependientes de datos son asociados en grupos independientes de datos. Se extrae un grupo independiente de datos y se mueve a microservicios de AWS con un almacén de datos compartido. Eventualmente, los microservicios individuales pueden beneficiarse de una stack de implementación separados, o un almacén de datos independiente.
Figura 3 – Agrupar y luego migrar con consistencia estricta de datos.
Migrando Microservicios con Blu Age Analyzer
Una arquitectura de microservicio descompone las aplicaciones en dominios comerciales con bajo acoplamiento. La idea es que cualquier equipo responsable de un dominio puede cambiar la forma en que se hacen las cosas dentro del dominio sin afectar otros dominios de aplicación con los que interactúa. Al migrar un monolito, uno debe identificar los diversos dominios y límites asociados.
Blu Age Analyzer se basa en los patrones anteriores para definir la descomposición de los microservicios. Posteriormente, Blu Age Velocity automatiza la refactorización de la modernización de las aplicaciones.
Ahora describiremos los pasos tomados con Blu Age Analyzer para identificar dominios de microservicios.
Paso 1: Análisis Vertical
Blu Age Analyzer identifica automáticamente todos los puntos de entrada al sistema y organiza las dependencias en anillos concéntricos. Los microservicios aparecen como árboles locales empezando desde afuera. En esta etapa, todavía hay algunos elementos de acoplamiento que aparecen en las capas internas identificadas por la zona verde en la Figura 4. Esta etapa de análisis está completamente automatizada.
Figura 4 – Análisis vertical de Blu Age Analyzer.
Paso 2: Definición de Dominio de Negocios
Durante este paso, las dependencias de los programas principales son resueltas y los límites de dominio individuales son finalizados. Esto lleva a una colaboración tipo estrella de mar, donde pocos dominios centrales (programas con muy poco código) contienen programas transversales y los dominios satelitales contienen la lógica del negocio. Los dominios satelitales usan dominios centrales y colaboran directamente con otros dominios satelitales.
Figura 5 – Definición de dominio detallada Blu Age Analyzer.
La descomposición del dominio y la detección de límites se realiza mediante el análisis de las relaciones entre el solicitante/solicitado, el tipo de acceso a datos y los formatos de datos. El ejemplo en la Figura 6 muestra para un árbol determinado de programa, las dependencias de datos de acuerdo con sus formatos de datos. Este destaca VSAM (Virtual Storage Access Method) y los tipos de acceso a DB2.
Figura 6 – Tipos de acceso de datos Blu Age Analyzer.
En esta etapa, un usuario de Blu Age Analyzer puede elegir modificar la definición de límites. Por lo general, un usuario puede ajustar un dominio basado en mejoras del negocio u optimizar la composición del API y la sincronización de datos. Esto es común para la definición de microservicios donde los límites se optimizan a través de iteraciones.
Blu Age Analyzer facilita esta tarea mediante la anotación de etiquetas (tags). El esfuerzo de ajuste de límites de dominio es típicamente 1/2 día de trabajo de un profesional por millón de líneas de código.
Paso 3: Definición de Dominios centrales
Los usuarios deben decidir incluir los dominios centrales como librerías dentro de microservicios o como microservicios independientes. Estos dominios centrales generalmente se convierten en librerías, ya que generalmente no hacen I/O y contienen solo programas transversales, que probablemente serían reemplazados por frameworks disponibles cuando estos sean modernizados.
La Figura 7 muestra la descomposición final con conexiones entre dominios con una sola flecha naranja por colaboración de dominio.
Figura 7 – Descomposición final de microservicios de Blu Age Analyzer.
Diseño de Microservicios Blu Age Velocity
Blu Age Analyzer no solo facilita la definición de dominios y microservicios, además calcula e impulsa las opciones de refactorización. Blu Age Velocity luego toma todas estas opciones de transformación como entradas. Ejecuta la refactorización automática del stack completo de software (código, datos, acceso a datos, acceso a dependencias, frameworks) a un stack destino preseleccionado basada en Java, AngularJS, SpringBoot, Spring Statemachine y APIs REST.
Figura 8 – Diseño de microservicios Blu Age Velocity.
El servidor BluSAM actúa como un contenedor de microservicios y tiene la flexibilidad de implementarse en varios servicios de cómputo de AWS. También puede acceder a varios servicios de datos como Amazon Aurora o Amazon ElastiCache. Velocity y BluSAM permiten implementar los patrones de migración de mainframe, así como los patrones de base de datos descritos en esta publicación.
Conozca más acerca de arquitecturas Velocity y BluSAM en AWS en este APN Blog post.
Pros y Contras de Patrones de Bases de Datos
Una decisión clave a tomar al diseñar microservicios es elegir el patrón de la base de datos en función de los requisitos de consistencia de datos. Los sistemas financieros o los sistemas que salvan vidas generalmente requieren la mayor consistencia. Otros sistemas pueden aceptar una consistencia eventual que favorezca el rendimiento, un menor acoplamiento y la eficiencia del negocio.
La siguiente tabla detalla qué modelo de consistencia está asociado según el patrón de base de datos y de migración de servicios.
Figura 9 – Consistencia y soporte de transacciones por patrón de migración.
La consistencia estricta y el soporte de transacciones ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) proporcionan la reversión automática de transacciones en caso de falla. Esto se realiza de forma transparente por la base de datos y los servidores de transacciones de la aplicación.
Por el contrario, la consistencia eventual no puede usar estos recursos de transacción y requiere un código de aplicación adicional o mecanismos para gestionar fallas. Por ejemplo, con la composición del API, el patrón Try-Cancel/Confirm (TCC) o el patrón Saga pueden implementarse para remediar fallas. Con la sincronización de datos, se pueden implementar estrategias de resolución de conflictos y reintento de replicación.
El patrón de Base de Datos Compartida conserva una consistencia estricta y soporte de transacciones. Por lo tanto, es atractivo cuando se pasa de mainframe a AWS en modo híbrido. Esto minimiza la necesidad de cambios manuales de código y aprovecha bien la automatización de la refactorización, que es la razón por la que a menudo reduce los riesgos de usar primero el patrón de base de datos compartida y luego pasar a usar la base de datos por patrón de dominio, si es necesario.
Los patrones de base de datos por dominio requieren límites de dominio explícitos. Por lo general, estos se definen de forma iterativa con una refactorización manual compleja hasta que los límites finalmente sean estables. Por lo general, se prefiere el Patrón de Sincronización de Datos sobre la composición de la API, ya que proporciona un mejor rendimiento, agilidad y acomoda lotes de carga de trabajo de mainframe.
Arquitectura de Replicación de Datos
En muchos casos, se prefieren los patrones de Datos Independientes o Base de Datos Compartidas para mantener una consistencia estricta y permitir que la base de datos administre la gestión de fallas o la recuperación de transacciones. Esto significa que se eligen los patrones «Migrar con servicios independientes de datos» y «Agrupar y luego migrar con consistencia estricta de datos» y ninguna replicación de datos es requerida.
Para los casos en los que se elige el patrón «Migrar con Consistencia Eventual de Datos», el patrón Base de Datos por Dominio no permite que un dominio acceda a datos de otro dominio directamente. Por lo tanto, los usuarios deben mantener sincronizados algunos datos en cada base de datos de dominio.
La Figura 10 muestra el enfoque general para consumir microservicios mientras se sincronizan datos compartidos duplicados. Los microservicios se implementan de forma independiente con su propia base de datos, y los servicios se exponen como API REST para hacer la composición de la API. Por lo general, los usuarios pueden usar AWS API Gateway para consumir servicios REST y hacer la composición
No se expone ninguna API de actualización de datos para realizar la sincronización de datos, y la replicación de datos se logra intrínsecamente usando Change Data Capture (CDC) y Event Propagation.
- Change Data Capture (CDC): un cambio de estado de datos se identifica en la base de datos de origen y desencadena una acción que permite que la arquitectura distribuida sincronice los datos en la secuencia correcta.
- Data Event Propagation: el motor de replicación o el agente de eventos distribuido transporta datos desde el CDC a todas las bases de datos destino. Debe garantizar la entrega de mensajes, escalamiento automático, el registro de mensajes (persistencia) y la secuencia de mensajes.
Figura 10 – Replicación de datos usando Change Data Capture (CDC) y Event Propagation.
Para la replicación de datos de mainframe a AWS, hay varias soluciones de proveedores empaquetadas disponibles para hacer replicación de datos asíncrona en tiempo real basada en CDC. Generalmente, admiten repositorios de datos de mainframe jerárquicos, relacionales, y basados en archivos, y replican datos en almacenes de datos de AWS como Amazon Relational Database Service (Amazon RDS), Amazon Aurora o Amazon Kinesis.
Dependiendo de requisitos específicos, se pueden combinar varias soluciones o componentes para alcanzar el objetivo deseado, tal como Amazon DynamoDB, o para cumplir con los requisitos de calidad de servicio.
Para la replicación de datos de AWS a mainframe, se pueden usar soluciones de proveedor empaquetadas desde diferentes servicios de datos de AWS hacia diversos almacenes de datos legados de mainframe. Además, los servicios nativos de AWS se pueden utilizar para impulsar los CDC, servicios de mensajería como Amazon Simple Queue Service (Amazon SQS), Amazon MQ y Amazon Kinesis para invocaciones asíncronas, y controladores nativos de mainframe para actualizar los almacenes de datos legados.
Para la replicación de datos de AWS a AWS, cuando se implementan al menos dos microservicios en AWS, los servicios gestionados de AWS pueden usarse para aprovechar los triggers y los servicios de mensajería.
Próximos Pasos
Esta publicación se centró en cómo migrar microservicios de un monolito mainframe y cómo gestionar las dependencias de datos, especialmente con la base de datos por patrón de dominio. Para obtener más información sobre microservicios, dominios y contexto específico, consulte los siguientes artículos:
Si desea obtener información sobre una carga de trabajo de mainframe refactorizada a una arquitectura de microservicio en AWS, debe leer Cómo migrar el lote de mainframe a microservicios en la nube con Blu Age y AWS.
Para obtener más información sobre la refactorización automática de código de COBOL a AWS (o de cualquier lenguaje de programación compatible con mainframe), eche un vistazo a Blu Genius for Mainframe to AWS Cloud-Native Transformation.
Para solicitar una demostración de migrar un monolito mainframe con Blu Age Analyzer y Velocity, contáctenos.
El contenido y las opiniones en este blog son del autor externo y AWS no es responsable del contenido o la precisión de esta publicación.
Blu Age – APN Partner Spotlight
Blu Age es un socio de tecnología avanzada de APN. Su tecnología automatiza la transformación de las aplicaciones comerciales legadas en
aplicaciones totalmente digitales con los últimos estándares tecnológicos.
Contacte a Blu Age | Demo de solución | Comprar en el Mercado
* ¿Ya trabajó con Blu Age? Califique a este socio
* Para reseñar un APN Partner, debe ser un cliente de AWS que haya trabajado con ellos directamente en un proyecto.
Revisores técnicos – idioma local
João Aragão Pereira
FSI Solution Architect, Amazon Web Services
Javier Cristancho
Solutions Architect, Amazon Web Services