Dentro de la academia de migración y modernización que AWS ofrece a sus partners, donde hemos asistido a varias sesiones que cubren todo el viaje de este proceso: el análisis de los requerimientos de negocio y técnicos de los clientes, el descubrimiento e inventario de la infraestructura, el análisis de las aplicaciones y la definición de la estrategia de migración, la creación de un business case, el diseño y la configuración de estructuras multi-AWS account, el establecimiento de planes de formación y finalmente, la migración y modernización de las cargas de trabajo, culminamos estas sesiones con un GameDay enfocado en Migración y modernización.
Es un desafío interactivo gamificado en equipo que normalmente dura un día diseñado para poner a prueba los conocimientos prácticos en AWS. Es una oportunidad para profesionales técnicos de practicar y explorar nuevos servicios de AWS, patrones de arquitectura, buenas prácticas y cooperación en equipo.
En esta ocasión se trataba de un ejercicio para migrar un sistema de eCommerce al cloud.
Este sistema consistía en una aplicación de dos capas: un webserver corriendo en Ubuntu Linux con Apache, PHP, Wordpress y WooCommerce y una capa de servidor de base de datos en Ubuntu Linux con MySQL.
El primer paso para realizar esta migración a AWS es diseñar correctamente una VPC que nos permita crear una sección lógica aislada.
Usando las subnets públicas y privadas, separamos las partes que deben ser accesibles desde internet (webserver) de las que deben permanecer privadas (base de datos). Usaremos varias zonas de disponibilidad para mejorar la fiabilidad.
El siguiente paso sería migrar la base de datos, para ello nos ayudaremos del servicio AWS Database Migration Service. Mientras usamos el servicio, la base de datos origen sigue funcionando correctamente, minimizando el downtime.
La estrategia de migración usada se denomina re-platform a un servicio gestionado como es Amazon RDS, es una mejor solución que realizar una estrategia de re-host en AWS EC2.
En este caso no fue necesario, porque el motor de la base de datos permanece la misma, pero en caso de ser necesario convertir el esquema de base de datos utilizaríamos la herramienta: AWS Schema Conversion Tool.
Para esta migración usaremos el servicio AWS Application Migration Service (servicio que mejora y sustituye a CloudEndure Migration) ya que nos permite realizar la migración rápidamente, sin pérdida de datos, minimizando el downtime y sin tener que realizar cambios para una estrategia de lift and shift. Instalamos el agente de replicación (Aws Replication Agent) en los servidores a migrar (no hace falta reiniciar) y seguimos los pasos de replicación a través de la consola: replicación, test y cutover.
Una vez el web server se está ejecutando en AWS, no tenemos que actualizar la variable para apuntar a la nueva base de datos y la migración habrá finalizado con éxito.
Una vez que tenemos todo en la nube es mucho más fácil comenzar una estrategia de modernización que en este caso consiste en mover la aplicación a contenedores. Dependiendo del caso de uso se puede usar unos servicios u otros, en este caso optamos por usar el servicio de orquestación de contenedores Amazon Elastic Container Service al ser gestionado por AWS. Podemos elegir ejecutar los contenedores en instancias de EC2 o en modo Fargate que nos provee de capacidades de cómputo serverless. Optamos por esta opción para no tener que gestionar las máquinas EC2.
A continuación, se puede ver un diagrama de la arquitectura de contenedores con ECS.
Para que una aplicación que puede escalar enrute el tráfico correctamente a cada una de sus réplicas, necesitamos un balanceador de carga de capa 7 (HTTP/HTTPS): un Application Load Balancer (ALB). Lo creamos junto con su listener, su target group y un health check.
La imagen de wordpress se puede obtener de la página oficial y seleccionar la última disponible siempre que sea compatible con la carga de trabajo migrada, se puede guardar en Amazon ECR. El contenido de la carpeta /var/www/html/wp-content ahora tiene que estar disponible para cualquier tasks que se este ejecutando, por lo que necesitamos un storage compartido. La solución será crear un Amazon Elastic File System (EFS) para guardar esta información y que esté disponible para cualquier nuevo contenedor que se levante.
Para más detalle sobre esta solución, visitar el blog de AWS, donde se detalla la siguiente arquitectura:
Ya hemos terminado la modernización de nuestra aplicación, pero como la mejora continua nunca acaba, ahora llegaría el paso de ver cómo se puede optimizar la arquitectura para hacerla más segura, con alto rendimiento, más fiable y que sea más eficiente y menos costosa. Para ello nos fijamos en el framework de AWS Well-Architect y sus 6 pilares (el sexto pilar (sostenibilidad) ha sido anunciado en el último re:Invent de Las Vegas 2021).
Por poner unos ejemplos: Configurar CloudWatch para monitorizar los recursos, habilitar un AWS Web Application Firewall (WAF) para proteger tu aplicación web de ataques conocidos, usar CloudFront para entregar los datos de forma rápida y segura a los usuarios, usar S3 para distribuir los contenidos estáticos, realiza un estudio para ver qué máquina es la más optima para su workload y que te permita reducir el coste: ¿es posible usar spot instances?
Aquí un diagrama de una posible solución aplicando varias optimizaciones:
Por cada nueva mejora, la puntuación del equipo iba subiendo, en cierto momento, entra en juego la práctica de chaos monkey que empieza a borrar servicios y hacer que la aplicación no de servicio, perdiendo puntos hasta que no se arregla. Y todo con la presión de las puntuaciones, de las puntuaciones del resto de los equipos y el tiempo que se va acabando.
¡Al final, pudimos realizar varias acciones y quedamos en un nada despreciable tercer puesto!
Recomiendo a todo el mundo que tenga la oportunidad de apuntarse a un AWS GameDay porque se aprende mucho y muy rápido, ya podéis ver toda la cantidad de servicios que se tocan y el evento duró sólo un día. Me faltó, quizás, practicar con el servicio AWS Migration Hub Refactor Spaces, pero es verdad que no da tiempo a todo y hay que dejar algo para el siguiente desafio.
Taller de migración de aplicaciones de AWS
Ejecución de WordPress en Amazon ECS en AWS Fargate con Amazon EFS
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
