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 principal de mayor tamaño y un sitio secundario más pequeño. Cada sitio seguía el mismo patrón de cuatro capas:
- Balanceo de carga: un pequeño grupo 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 principal).
- Orquestación de contenedores: clústeres de Docker Swarm autogestionados, operados como clústeres separados de producción y desarrollo en el sitio principal y un único clúster en el sitio secundario.
- Datos: un par primario/réplica de MySQL junto a un clúster Cassandra de tres nodos, replicados 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: se mantenían los mismos 24 y 16 nodos, pero distribuidos en varias zonas de disponibilidad dentro de una única 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:
|
| Balanceo de carga (HAProxy) | 5 | 5 |
| Aplicación y herramientas (web, tracking, tareas programadas, calidad de código, gateway VPN) | 6 | 2 |
| Orquestación de contenedores (Docker Swarm: clústeres de producción + desarrollo) | 8 | 4 |
| Datos (MySQL primario/réplica + clúster Cassandra de 3 nodos) | 5 | 5 |
| Total de nodos | 24 | 16 |
Estas cifras se mantuvieron constantes a ambos lados del cutover: 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 exactamente igual que el 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ó el terreno preparado para la fase Modernize, ya que la hoja de ruta contemplaba retirar los clústeres autogestionados de Docker Swarm y reemplazarlos por 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, en las que cada fase construía la base técnica y financiera de la siguiente, con el equipo de Forward Deployment Engineering de DoiT a cargo de la entrega de principio a fin.
|
| Enfoque | Modelado de costos y preparación para la migración | Conectividad entre nubes y cutover | Contenedorización y FinOps continuo |
| Estado | Completada | Completada | En curso |
1. Assess: construir un presupuesto de migración sólido
Antes de mover cualquier workload, el equipo de Software Projects necesitaba una visión clara, servicio 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 según los tipos de volumen y las 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 con descuento a un Compute Savings Plan, sin compromiso inicial) con los precios de instancias reservadas estándar y convertibles, y explicó las ventajas y desventajas de cada opción de cara a una posible migración futura a un servicio de bases 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 llevó a cabo una evaluación estructurada de las opciones —AWS Direct Connect, un circuito dedicado de IBM Direct Link, appliances de router virtual y una VPN mesh 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.
- Puso a prueba una capa de VPN mesh como alternativa rápida y sin costo mientras se evaluaban las opciones de largo plazo.
- Acompañó 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 montó una VPN IPSec site-to-site 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 y sin solapamientos y ajustando las rutas estáticas: la corrección que finalmente desbloqueó el tráfico bidireccional entre los tres entornos.
El resultado fue una ruta de red privada estable y verificada que conectaba IBM Classic Infrastructure, IBM VPC y AWS: la base que permitió al equipo de Software Projects mover workloads a su propio ritmo sin perder la conectividad con los sistemas que aún corrían en IBM.
Mantener la producción saludable 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 con SSM y no había SSH como alternativa. DoiT usó los diagnósticos de la 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 arrancara— y entregó 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 por SNS para evitar que se repitiera, con especial atención a proteger los sistemas de producción del mismo tipo de falla.
3. Modernize: contenedores y optimización continua de costos
Con la migración completada, el proyecto avanzó a la fase Modernize. Los stacks de producción y desarrollo de Software Projects seguían corriendo en clústeres autogestionados de Docker Swarm: funcionales, pero con la carga operativa de administrar manualmente los parches de managers y workers. DoiT ahora ayuda al equipo de Software Projects a retirar esos clústeres de Swarm y reemplazarlos por una plataforma de contenedores administrada en AWS (Amazon EKS), construyendo directamente sobre la base consolidada de la VPC multi-AZ establecida durante Mobilize, en lugar de rediseñar la arquitectura desde cero.
Como parte de ese mismo impulso 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, impulsados principalmente por la ingesta de flow logs de alto volumen y no por el valor de seguridad entregado. DoiT cuantificó las ventajas y desventajas —incluido 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, basado en evidencia, para hacer right-sizing de la cobertura de seguridad sin perder las detecciones de mayor valor. Este mismo enfoque disciplinado y basado en evidencia se traslada ahora al trabajo de contenedorización: bien dimensionado desde el inicio, en lugar de optimizado después.
La solución: con la tecnología de DoiT Cloud Intelligence (DCI)
Además del trabajo de ingeniería en terreno, 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 sobre su propio entorno de AWS:

|
| Forward Deployment Engineering | El equipo de DoiT que trabajó en terreno y entregó de principio a fin las fases Assess, Mobilize y Modernize, desde el diseño de red y el cutover hasta la optimización continua |
| DCI Insights | Presentó recomendaciones de optimización de costos, incluidas las opciones de right-sizing de AWS Detective y GuardDuty utilizadas durante Modernize |
| DCI Cloud Diagrams | Mapeó y visualizó la infraestructura de AWS: la misma topología de cuatro capas y dos sitios que se muestra en la comparación de arquitectura anterior de este caso de estudio |
| DCI Datadog Insights | El cliente lo usa hoy de forma continua para hacer seguimiento del gasto en observabilidad y monitoreo a medida que el entorno crece |
| DCI AWS Intelligence | El cliente lo usa hoy de forma continua para hacer seguimiento del gasto total en AWS en todo el entorno consolidado |
Las dos últimas capacidades están activas día a día: a medida que el equipo de Software Projects avanza hacia los 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 una factura mensual revele un problema.