Caminos de modernización para una aplicación monolítica de .NET Framework heredada en AWS

Las organizaciones apuntan a ofrecer soluciones tecnológicas óptimas en función de las necesidades de sus clientes. Si bien pueden estar en cualquier etapa de su viaje de adopción a la nube, las empresas a menudo terminan administrando y creando aplicaciones monolíticas. Sin embargo, hay muchos desafíos para esta solución. La estructura interna de una aplicación monolítica dificulta a los desarrolladores el mantenimiento del código. Esto crea una curva de aprendizaje pronunciada para los nuevos desarrolladores y aumenta los costos. Los monolitos requieren que varios equipos coordinen una sola versión grande, lo que aumenta la carga de trabajo referente a colaboración y transferencia de conocimientos. A medida que una empresa crece, una aplicación monolítica puede tener dificultades para satisfacer las demandas propias de usuarios en expansión. Para abordar estas inquietudes, los clientes deben evaluar si están preparados para modernizar sus aplicaciones en la nube de AWS a fin de satisfacer sus necesidades empresariales y técnicas.

Analizaremos un enfoque para modernizar una aplicación monolítica de tres niveles (patrón MVC): un nivel web, un nivel de aplicación que utiliza .NET Framework y un nivel de datos con una base de datos relacional de Microsoft SQL (MSSQL) Server. Hay tres vías principales de modernización para las aplicaciones de.NET: realojamiento, cambio de plataforma y refactorización. Recomendamos seguir esta matriz de decisiones para evaluar y decidir su ruta de migración, en función de sus requisitos específicos. Para este blog, nos centraremos en una estrategia de replataforma y refactorización para diseñar microservicios poco acoplados, empaquetados como contenedores livianos y respaldados por una base de datos especialmente diseñada.

Su viaje hacia la modernización

Los resultados del enfoque de modernización de su organización le brindan la capacidad de escalar de manera óptima según las demandas de sus clientes. Vamos a sumergirnos en un enfoque guiado que logra sus objetivos de una arquitectura moderna y, al mismo tiempo, aborda la escalabilidad, la facilidad de mantenimiento, los ciclos de implementación rápidos y la optimización de costos.

Esto implica cuatro pasos:

Dividir el monolito
Prepare su aplicación en contenedores
Refactorizar a .NET 6
Migre a un motor de base de datos especialmente diseñado y de menor costo.

1. Dividir el monolito

La migración a la nube de Amazon Web Services (AWS) tiene muchas ventajas. Estas pueden incluir una mayor velocidad de comercialización y agilidad empresarial, nuevas oportunidades de ingresos y ahorro de costos. Para aprovechar al máximo, debe modernizar continuamente las aplicaciones de su organización mediante la refactorización de sus aplicaciones monolíticas en microservicios.

La descomposición de una aplicación monolítica en microservicios presenta desafíos técnicos que requieren una comprensión sólida de la base de código existente y el contexto de los dominios empresariales. Varios patrones son útiles para transformar gradualmente una aplicación monolítica en microservicios y otros diseños distribuidos. Sin embargo, el proceso de refactorización de la base de código es manual, arriesgado y consume tiempo.

Para ayudar a los desarrolladores a acelerar la transformación, AWS presentó AWS Microservice Extractor for .NET. Esto ayuda a dividir las aplicaciones de arquitectura y refactorización en proyectos de código más pequeños. Aquí puede leer cómo AWS Microservice Extractor for .NET ayudó a nuestro socio, Kloia, a acelerar el proceso de modernización de sus clientes y a descomponer un monolito.

El siguiente camino de modernización consiste en contenedorizar su aplicación.

2. Contenerizar

¿Por qué debería cambiarse a contenedores? Los contenedores ofrecen una forma de ayudarlo a crear, probar, implementar y volver a implementar aplicaciones en varios entornos. Específicamente, Docker Containers le proporciona una forma confiable de reunir los componentes de su aplicación y empaquetarlos en un solo artefacto de construcción. Esto es importante porque las aplicaciones modernas suelen estar compuestas por una variedad de elementos además del código, como dependencias, binarios o bibliotecas del sistema. Mover las aplicaciones heredadas de.NET Framework a contenedores ayuda a optimizar la utilización del sistema operativo y lograr tiempos de ejecución consistentes.

Para acelerar este proceso, coloque estas aplicaciones en contenedores de Windows con AWS App2Container (A2C). A2C es una herramienta de línea de comandos para modernizar aplicaciones de.NET y Java en aplicaciones contenerizadas. A2C analiza y crea un inventario de todas las aplicaciones que se ejecutan en máquinas virtuales, en las instalaciones o en la nube. Seleccione la aplicación que desea incluir en contenedores y A2C empaqueta el artefacto de la aplicación y las dependencias identificadas en imágenes de contenedor. Aquí hay un artículo paso a paso y un taller a su propio ritmo para comenzar a usar A2C.

Una vez que la aplicación esté en contenedores, puede optar por autogestionamiento mediante Amazon EC2 para alojar Docker con contenedores de Windows. También puede usar Amazon Elastic Container Service (ECS) o Amazon Elastic Kubernetes Service (Amazon EKS). Se trata de servicios de orquestación de contenedores totalmente gestionados que le permiten centrarse en crear y administrar aplicaciones en lugar de en su infraestructura subyacente. Lea Amazon ECS frente a Amazon EKS: comprensión de los servicios de contenedores de AWS.

En la siguiente sección, analizaremos dos aspectos principales para optimizar los costos en nuestro escenario de modernización:

Costos de licencia de ejecutar cargas de trabajo en servidores Windows.
Costo de las licencias de SQL Server.

3. Refactorizar a .NET 6

Para abordar los costos de licencias de Windows, considere la posibilidad de cambiar a un entorno Linux mediante la adopción de .NET Core y el uso de Dockerfile para un contenedor de Linux. Clientes como GoDataFeed se benefician al migrar aplicaciones de .NET Framework a .NET 6 la cual es más reciente y en cuanto a su ejecución en AWS. El equipo de.NET ha mejorado significativamente el rendimiento con .NET 6, incluida la mejora del rendimiento de socket del 30 al 40% en Linux. Han añadido optimizaciones específicas de ARM64 en las bibliotecas de.NET, que permiten a los clientes ejecutar en AWS Graviton.

También puede optar por cambiar a una opción sin servidor con AWS Lambda (que admite el tiempo de ejecución de.NET 6) o ejecutar sus contenedores en ECS con Fargate, un motor de procesamiento sin servidor que se paga por uso. AWS Fargate con procesadores AWS Graviton2 puede reducir los costos hasta un 20% y aumentar el rendimiento hasta un 40% en comparación con las instancias basadas en Intel x86. Si necesita control total sobre la máquina virtual (VM) subyacente de una aplicación, el sistema operativo, el almacenamiento y la aplicación de parches, ejecute aplicaciones de.NET 6 en instancias Linux de Amazon EC2 las cuales están equipadas con procesadores Intel y AMD de última generación.

Para ayudar a los clientes a migrar su aplicación a .NET 6 más rápido, AWS agregó compatibilidad con .NET 6 a Porting Assistant for .NET. Porting Assistant es una herramienta de análisis que analiza las aplicaciones de .NET Framework (más de 3.5) para generar una evaluación de compatibilidad de .NET Core o .NET 6 de destino. Esto le ayuda a priorizar las aplicaciones para la portabilidad en función del esfuerzo requerido. Identifica las API y los paquetes incompatibles de sus aplicaciones de.NET Framework y encuentra reemplazos conocidos. Puede consultar un vídeo de demostración que explica este proceso.

4. Migración de SQL Server a un motor de base de datos de menor costo

AWS recomienda que cree aplicaciones distribuidas, altamente escalables y basadas en casos de uso que se adapten a sus necesidades específicas. Desde la perspectiva de la base de datos, AWS ofrece más de 15 motores especialmente diseñados para admitir diversos modelos de datos. Además, las arquitecturas de microservicios emplean un acoplamiento flexible, por lo que cada microservicio individual puede almacenar y recuperar información de su propio almacén de datos de forma independiente. Al implementar el patrón de base de datos por servicio, puede elegir los almacenes de datos más óptimos (bases de datos relacionales o no relacionales) para sus requisitos empresariales y de aplicaciones.

Para el propósito de este blog, nos centraremos en una base de datos relacional alternativa para SQL Server. Para abordar los costos de licencias de SQL Server, los clientes pueden considerar la posibilidad de cambiar a un motor de base de datos relacional de código abierto. Amazon Relational Database Service (Amazon RDS) admite MySQL, MariaDB y PostgreSQL. Nos centraremos en PostgreSQL con una ruta de migración bien definida. Amazon RDS admite dos tipos de bases de datos Postgres: Amazon RDS for PostgreSQL y Amazon Aurora PostgreSQL compatible Edition. Para ayudarle a elegir, lea ¿Es Amazon RDS para PostgreSQL o Amazon Aurora PostgreSQL una mejor opción para mí?

Una vez que se haya decidido por el sabor de Amazon RDS, la siguiente pregunta sería «¿cuál es la estrategia de migración adecuada para mí?» Considera lo siguiente:

Convertir tu esquema
Migrar los datos
Refactorizar su aplicación

Conversión de esquemas

AWS Schema Conversion Tool (SCT) es una herramienta gratuita que puede ayudarle a convertir su base de datos existente de un motor a otro. AWS SCT admite varias bases de datos como origen, incluidas Microsoft SQL Server, Oracle y MySQL. Puede elegir entre motores de bases de datos como destino, tales como Amazon Aurora PostgreSQL Compatible Edition, o configurar un Data Lake con Amazon S3. AWS SCT proporciona una interfaz gráfica de usuario que se conecta directamente a las bases de datos de origen y destino para obtener los objetos de esquema actuales. Mientras esté conectado, puede generar un informe de evaluación de la migración de la base de datos para obtener un resumen de alto nivel del esfuerzo de conversión y los elementos de acción.

Migración de datos

Cuando finalice la migración del esquema, puede mover los datos de la base de datos origen a la base de datos destino. Según los requisitos de disponibilidad de la aplicación, puede ejecutar un trabajo de extracción sencillo que realice una copia única de los datos origen en la nueva base de datos. O bien, puede utilizar una herramienta que copie los datos actuales y siga replicando todos los cambios hasta que esté listo para pasar a la nueva base de datos. Una de estas herramientas es AWS Database Migration Service (AWS DMS), que le ayuda a migrar bases de datos relacionales, data warehouses, bases de datos NoSQL y otros tipos de almacenes de datos.

Con AWS DMS, puede realizar migraciones únicas y replicar los cambios en curso para mantener sincronizados los orígenes y los destinos. Cuando las bases de datos de origen y destino están sincronizadas, puede desconectar la base de datos y mover sus operaciones a la base de datos de destino. Lea Microsoft SQL Server To Amazon Aurora with Post GreSQL Compatibility para obtener un manual de estrategias o utilice este taller autoguiado para migrar a una base de datos compatible con PostgreSQL mediante SCT y DMS.

Refactorización de aplicaciones

Cada motor de base de datos tiene sus diferencias y matices, y pasar a un nuevo motor de base de datos como PostgreSQL desde MSSQL Server requerirá una refactorización del código. Una vez completada la migración inicial de la base de datos, la reescritura manual del código de la aplicación, el cambio de los controladores de base de datos y la verificación de que el comportamiento de la aplicación no ha cambiado requieren un esfuerzo. Esto implica un riesgo potencial de errores al realizar cambios importantes en el código de la aplicación.

AWS creó Babelfish for Aurora PostgreSQL para simplificar la migración de aplicaciones de SQL Server a una edición compatible con Amazon Aurora PostgreSQL. Babelfish for Aurora PostgreSQL es una nueva capacidad de Amazon Aurora PostgreSQL compatible Edition que permite a Aurora comprender los comandos de las aplicaciones escritas para Microsoft SQL Server. Con Babelfish, Aurora PostgreSQL ahora entiende T-SQL, el dialecto SQL propietario de Microsoft SQL Server. Admite el mismo protocolo de comunicaciones, por lo que las aplicaciones que se escribieron originalmente para SQL Server ahora pueden funcionar con Aurora. Lea acerca de cómo migrar de SQL Server a Babelfish for Aurora PostgreSQL. Asegúrese de ejecutar la herramienta Babelfish Compass para determinar si la aplicación contiene alguna función de SQL que Babelfish no admite actualmente.

La figura 1 muestra el estado del antes y el después de la aplicación según la ruta de modernización descrita en este blog. La capa de aplicaciones consiste en microservicios que se ejecutan en clústeres de Amazon ECS Fargate (o funciones de AWS Lambda) y la capa de datos se ejecuta en Amazon Aurora (variante PostgreSQL).

Figura 1. Rearquitectura modernizada basada en microservicios

Conclusión

En esta publicación, hemos mostrado una ruta de migración de una aplicación monolítica de .NET Framework a una solución moderna basada en microservicios en AWS. Hablamos de las herramientas de AWS para dividir el monolito en microservicios y convertir la aplicación en contenedores. También discutimos las estrategias de optimización de costos mediante el cambio a sistemas basados en Linux y el uso de motores de bases de datos de código abierto. Si desea obtener más información sobre las estrategias de modernización, lea esta guía prescriptiva.

Este artículo fue traducido del Blog de AWS en Inglés

Acerca de los autores

Ramakant Joshi es un arquitecto de soluciones senior en AWS y se especializa en los dominios de analytics y serverless. Tiene más de 20 años de experiencia en desarrollo y arquitectura de software y le apasiona ayudar a los clientes a modernizar su arquitectura en la nube.

Revisores

Luciano Bernardes actualmente trabaja como Sr Solutions Architect en AWS, especializándose en cargas de trabajo de Microsoft. Con 15 años de experiencia en el mercado, se ha desempeñado principalmente en consultoría técnica especializada en Microsoft, con clientes de diversos verticales, con demandas enfocadas en infraestructura on-premise y en la nube. Como SA, trabaja en estrecha colaboración con clientes y socios consultores en LATAM, para apoyarlos en la toma de decisiones y revisar la arquitectura de las cargas de trabajo de Microsoft en la nube de AWS.

Victor Jiménez es un arquitecto senior de soluciones de socios principales de AWS con sede en México. Cuenta con experiencia de 15 años en cargas de trabajo de Windows Server principalmente en roles de infraestructura, provisionamiento y automatización. Ha adquirido experiencia en los últimos 4 años en tecnologías en la nube. En AWS, lleva a cabo tareas de apoyo con los socios estratégicos para guiar a los clientes en la adopción de su viaje a la nube y modernización aprovechando las herramientas y servicios optimizados para su negocio.

Blog de Amazon Web Services (AWS)