El entorno: una arquitectura de cuatro capas en dos sitios

Antes de la migración, el equipo de Software Projects operaba una arquitectura única y bien definida en dos regiones de IBM Cloud, dimensionada para la resiliencia: un sitio primario más grande y un sitio secundario más pequeño. Cada sitio seguía el mismo patrón de cuatro capas:

• Balanceo de carga: una pequeña flota de instancias HAProxy que gestionaba por separado el tráfico de producción, desarrollo y tracking.
• Aplicación: servidores web y de tracking, un ejecutor de tareas programadas, un servidor de calidad de código (SonarQube) y un gateway VPN (presente solo en el sitio primario).
• Orquestación de contenedores: clústeres de Docker Swarm autogestionados, operados como clústeres separados de producción y desarrollo en el sitio primario y como un único clúster en el sitio secundario.
• Datos: un par primario/réplica de MySQL junto a un clúster de Cassandra de tres nodos, replicado en ambos sitios.

El plan de migración de DoiT contemplaba un lift-and-shift fiel, 1:1, de esta topología hacia una sola VPC de AWS en us-east-1, manteniendo los mismos despliegues de 24 y 16 nodos, pero distribuyéndolos en varias zonas de disponibilidad dentro de una sola región de AWS, en lugar de dos regiones de IBM Cloud independientes y geográficamente separadas. La siguiente tabla muestra cómo la composición capa por capa se trasladó sin cambios:

Estos números se mantuvieron constantes antes y después del cambio: los mismos 24 y 16 nodos, en las mismas proporciones capa por capa, simplemente reubicados. Esa disciplina fue clave: significó que Software Projects heredó en AWS un entorno que se comportaba de forma idéntica al que su equipo ya conocía, mientras DoiT eliminaba discretamente una capa de complejidad de infraestructura al consolidar dos regiones de centros de datos en una sola región de AWS distribuida en varias zonas de disponibilidad. También dejó bien encaminada la fase Modernize, ya que la hoja de ruta contemplaba retirar los clústeres autogestionados de Docker Swarm en favor de una plataforma de contenedores administrada una vez que el entorno estuviera estable en AWS.

El enfoque: AWS MAP, entregado de principio a fin

DoiT ejecutó el proyecto a lo largo de las tres fases de AWS MAP —cada una sentando la base técnica y financiera para la siguiente—, con el equipo de Forward Deployment Engineering de DoiT a cargo de principio a fin.

1. Assess: construir un presupuesto de migración defendible

Antes de mover cualquier workload, el equipo de Software Projects necesitaba una visión clara, por servicio, de lo que costarían el almacenamiento y el cómputo en AWS. DoiT elaboró un desglose de costos detallado que cubría EBS y EFS —modelando los costos mensuales de almacenamiento, IOPS y rendimiento entre tipos de volumen y clases de almacenamiento— para que Software Projects pudiera proyectar el gasto a corto y mediano plazo de su hoja de ruta de migración. DoiT también trabajó la estrategia de descuentos para el cómputo de bases de datos de Software Projects, comparando DoiT Flexsave (un equivalente a un Compute Savings Plan con descuento y sin compromiso inicial) con los precios de instancias reservadas estándar y convertibles, y explicó los pros y contras de cada opción de cara a una posible migración futura a un servicio de base de datos administrado.

2. Mobilize: resolver la conectividad entre nubes

La conectividad entre IBM Cloud y AWS era la ruta crítica de toda la migración, y no existía una solución lista para usar. DoiT realizó una evaluación estructurada de las opciones —AWS Direct Connect, un circuito dedicado IBM Direct Link, appliances de router virtual y una VPN en malla ligera—, sopesando el costo, la estabilidad y la complejidad de configuración de cada una:

• Evaluó AWS Direct Connect e IBM Direct Link Dedicated (incluidas las restricciones de BGP, rangos de IP y facturación) como opción de circuito dedicado.
• Probó una VPN en malla como alternativa de respaldo rápida y sin costo mientras se evaluaban las opciones de largo plazo.
• Guio a Software Projects en el despliegue y ajuste de un appliance de router virtual del lado de IBM, incluido el comportamiento de enrutamiento de VLAN y la resolución de problemas de capa 2 con el soporte de IBM.
• Ayudó a Software Projects a pasar de IBM Classic Infrastructure a IBM VPC para lograr una red más flexible, y luego levantó una VPN IPSec sitio a sitio entre IBM VPC y una VPC de AWS.
• Diagnosticó y resolvió un solapamiento de subredes y una brecha de enrutamiento entre IBM Classic y AWS, asignando un rango de IP dedicado sin solapamientos y ajustando rutas estáticas: el ajuste que finalmente habilitó el tráfico bidireccional entre los tres entornos.

El resultado fue una ruta de red privada estable y verificada que conecta IBM Classic Infrastructure, IBM VPC y AWS: la base que le permitió al equipo de Software Projects mover workloads a su propio ritmo sin perder la conectividad con los sistemas que seguían corriendo en IBM.

Mantener la producción en buen estado durante la transición

Durante la ventana de migración, DoiT también brindó soporte operativo rápido del lado de AWS. En un caso, una instancia EC2 perdió inesperadamente la conectividad de SSM sin un respaldo SSH disponible. DoiT utilizó diagnósticos de salida de consola para identificar la causa raíz —el volumen raíz se había quedado sin espacio en disco, lo que impedía que el agente de SSM se iniciara— y proporcionó un plan de remediación paso a paso (expansión del volumen y redimensionamiento del sistema de archivos), junto con alarmas proactivas de utilización de disco en CloudWatch y notificaciones de SNS para evitar que se repitiera, con especial atención a proteger los sistemas de producción del mismo modo de falla.

3. Modernize: contenedores y optimización continua de costos

Con la migración completada, el proyecto pasó a la fase Modernize. Los stacks de producción y desarrollo de Software Projects seguían corriendo en clústeres de Docker Swarm autogestionados: funcionales, pero con la carga operativa de administradores y workers parcheados manualmente. DoiT ahora está ayudando al equipo de Software Projects a retirar esos clústeres de Swarm en favor de una plataforma de contenedores administrada en AWS (Amazon EKS), construyendo directamente sobre la base de la VPC consolidada y multi-AZ establecida durante Mobilize, en lugar de rediseñar la arquitectura desde cero.

Como parte de ese mismo esfuerzo de modernización, DoiT mantiene el gasto en la nube bajo control mientras el entorno evoluciona. Con DCI Insights, DoiT revisó la configuración de AWS Detective y GuardDuty de Software Projects y descubrió que los costos de las herramientas de seguridad habían crecido hasta representar una parte significativa del gasto total, debido principalmente a la ingesta de flow logs de alto volumen y no al valor de seguridad entregado. DoiT cuantificó los pros y contras —incluidos qué tipos de hallazgos de alta severidad dependían de qué fuentes de datos— y le dio a Software Projects un conjunto claro de opciones basadas en evidencia para hacer right-sizing de la cobertura de seguridad sin perder las detecciones de mayor valor. Este mismo enfoque disciplinado, con la evidencia por delante, se está trasladando al trabajo de contenedorización: bien dimensionado desde el inicio, en lugar de optimizado después.

La solución: potenciada por DoiT Cloud Intelligence (DCI)

Además del trabajo de ingeniería práctico, Software Projects aprovechó varias capacidades de DoiT Cloud Intelligence (DCI) a lo largo del proyecto, combinando un equipo de entrega experimentado con visibilidad de autoservicio de su propio entorno de AWS:

Las dos últimas capacidades están activas en el día a día: mientras el equipo de Software Projects avanza en su modernización hacia contenedores, DCI AWS Intelligence y DCI Datadog Insights le brindan visibilidad continua del gasto total en la nube y en observabilidad, en lugar de esperar a que la factura mensual revele un problema.

• Estableció la primera ruta de red privada funcional entre IBM Cloud Infrastructure y AWS, después de que los intentos autogestionados previos fallaran en una dirección.
• Migró los 40 servidores —la topología completa de cuatro capas de balanceo de carga, aplicación, orquestación y datos— a AWS con la composición capa por capa sin cambios, de modo que el equipo heredó un entorno familiar desde el primer día.
• Consolidó dos regiones de IBM Cloud geográficamente separadas en una sola VPC de AWS que abarca varias zonas de disponibilidad, simplificando la red y la operación sin sacrificar la resiliencia de un diseño de doble sitio.
• Le dio a Software Projects un modelo de costos granular y defendible para almacenamiento y cómputo antes de la migración, reduciendo las sorpresas presupuestarias durante el traslado.
• Resolvió una interrupción de SSM que afectaba a producción con una causa raíz clara y dejó a Software Projects con monitoreo proactivo para detectar la misma falla más temprano la próxima vez.
• Entregó las tres fases de AWS MAP —Assess, Mobilize y Modernize— en un solo proyecto continuo, conservando el contexto de la migración en lugar de reiniciarlo en cada cambio de fase.
• Dejó al cliente listo para retirar los clústeres autogestionados de Docker Swarm en favor de una plataforma de contenedores administrada, con la postura de seguridad y costos ya ajustada antes de que comience la siguiente fase.
• Le dejó al cliente visibilidad de autoservicio de su propio entorno: DCI Cloud Diagrams para el mapeo de infraestructura, y DCI AWS Intelligence y DCI Datadog Insights para el seguimiento continuo del gasto en la nube y en observabilidad.

El entorno de AWS de Software Projects es ahora la base estable para su próxima fase de modernización. DoiT sigue colaborando con el cliente mientras traslada sus workloads a contenedores, aplicando la misma combinación de entrega técnica y disciplina continua de costos que llevó la migración desde la evaluación inicial hasta un entorno de AWS totalmente conectado y listo para producción.

Software Projects es una organización de servicios de software que opera un entorno mixto de producción y no producción, alojado históricamente en IBM Cloud Infrastructure. Como parte de una estrategia de nube más amplia, la organización contrató a DoiT para migrar sus workloads a AWS bajo el AWS Migration Acceleration Program (MAP), con DoiT a cargo de las tres fases de MAP: Assess, Mobilize y Modernize.