Una vez migradas las aplicaciones, la modernización transforma sistemas legacy en arquitecturas cloud-native. El SAP-C02 evalúa el conocimiento de patrones como Strangler Fig, containerización progresiva y la transición a serverless y event-driven.
Contenido
La modernización no es un evento único — es un continuum. Los patrones permiten modernizar incrementalmente reduciendo el riesgo vs un "Big Bang rewrite".
Incremental
Modernizar componente por componente. El sistema legacy y el nuevo coexisten durante la transición. Menor riesgo, más tiempo.
Strangler Fig, Branch by Abstraction
Parallel Run
El sistema legacy y el nuevo corren en paralelo procesando el mismo tráfico. Verificación de resultados antes de cutover completo.
Shadow deployments, Traffic splitting
Expand-Contract
Añadir nueva funcionalidad en paralelo (expand), migrar consumers al nuevo sistema, eliminar el antiguo (contract). Para cambios de schema o API.
Migración de API v1 → v2 con compatibilidad
El Strangler Fig Pattern migra un monolito extrayendo funcionalidades una por una hacia microservicios independientes, sin reescribir todo desde cero. Un proxy/API Gateway enruta el tráfico al monolito o al nuevo microservicio según la ruta.
Identificar la funcionalidad a extraer
Seleccionar un bounded context con límites claros (ej: módulo de pagos). Debe ser independiente del resto del monolito.
Desplegar el nuevo microservicio en paralelo
Crear el microservicio en ECS/Lambda/EKS. Inicialmente sin tráfico de producción.
Configurar el proxy/API Gateway
API Gateway o ALB enruta /api/payments/* al nuevo microservicio, el resto al monolito.
Migrar el tráfico gradualmente
Canary deployment: 10% → 50% → 100%. Rollback inmediato si hay errores.
Eliminar el código del monolito
Una vez el microservicio maneja 100% del tráfico, eliminar la funcionalidad del monolito.
AWS Refactor Spaces (Migration Hub)
AWS Refactor Spaces facilita el Strangler Fig creando automáticamente el proxy routing entre el monolito y los nuevos microservicios. Gestiona el routing incremental sin necesidad de configurar manualmente API Gateway.
Ruta de containerización
Lift & Shift a contenedor
Empaquetar la app existente en Docker sin cambios. Misma configuración, más portabilidad. Primero rehost, luego optimizar.
Containerizar + managed DB
App en ECS Fargate + migrar de DB en EC2 a RDS. Replatform con contenedores.
Microservicios en contenedores
Refactor completo: cada microservicio en su propio contenedor con CI/CD independiente.
Herramientas de containerización en AWS
La modernización serverless reemplaza componentes que corren en servidores permanentes con servicios event-driven que escalan a cero. No todo puede o debe hacerse serverless — se aplica selectivamente.
| Componente legacy | Equivalente serverless | Beneficio |
|---|---|---|
| Cron jobs en EC2 (scripts nocturnos) | EventBridge Scheduler + Lambda | Sin instancias idle durante 23h |
| API en EC2 + ALB | API Gateway + Lambda | Escala a 0, paga por request |
| Cola de mensajes con workers en EC2 | SQS + Lambda | Sin workers permanentes, escala automática |
| Batch processing en EC2 | AWS Batch o Step Functions + Lambda | Sin cluster permanente, paga por trabajo |
| WebSockets con servidor EC2 | API Gateway WebSocket + Lambda + DynamoDB | Sin servidor de estado permanente |
| ETL batch diario en script Python | Glue Streaming o Step Functions + Lambda | Serverless ETL, escala automática |
Cuándo serverless NO es apropiado
Lambda tiene límite de 15 min de ejecución y 10 GB de memoria. Para jobs de larga duración (horas) o alto cómputo → ECS/EKS o AWS Batch. Para cargas con latencia de cold start crítica → instancias EC2 con warm pool o Provisioned Concurrency en Lambda.
De síncrono a asíncrono
Antes (síncrono)
API llama a 5 servicios en secuencia. Si uno falla, toda la operación falla. Latencia acumulada. Acoplamiento fuerte.
Después (asíncrono con SQS/SNS)
API publica evento a SNS. 5 servicios consumen de sus propias SQS queues. Aislamiento de fallos, retry independiente, sin acoplamiento.
Patrones CQRS y Event Sourcing
| Situación | Estrategia de modernización | Herramienta |
|---|---|---|
| DB Oracle en EC2 — alto costo de licencias | Migrar a Aurora PostgreSQL (Babelfish para compatibilidad SQL Server) | AWS SCT + DMS |
| MySQL/PostgreSQL on-premises | Migrar a Aurora (misma engine, más performance y HA) | DMS con minimal downtime |
| MongoDB en EC2 | Migrar a Amazon DocumentDB | mongodump / mongorestore o DMS |
| Tabla DynamoDB con hot partition | Rediseñar partition key, añadir sufijo aleatorio (write sharding) | Revisión de diseño de datos |
| Base de datos relacional con queries analíticos lentos | Segregar: OLTP en RDS, OLAP en Redshift con DMS o Kinesis | Redshift + DMS / Firehose |
| DB on-premises con compliance que exige latencia < 1ms | Retain (no migrar) o AWS Local Zones + Outposts | AWS Outposts |
CodeCommit
Repositorio Git gestionado. Integrado con IAM para control de acceso granular.
CodeBuild
Build serverless: compila, ejecuta tests, genera artefactos. Paga por minuto de build.
CodeDeploy
Despliegue automático en EC2, ECS, Lambda y on-premises. Blue/Green y Canary deployment nativo.
CodePipeline
Orquestador del pipeline CI/CD. Integra Source → Build → Test → Deploy automáticamente.
Blue/Green Deployment — cero downtime
Blue/Green crea un entorno idéntico (green) con la nueva versión mientras blue sigue sirviendo tráfico. Cuando green está validado, el tráfico se cambia instantáneamente. En ECS con CodeDeploy: ALB tiene dos target groups, CodeDeploy cambia el routing. Rollback inmediato cambiando el routing de vuelta a blue.
Trampa: "Modernizar siempre significa pasar a microservicios"
Realidad: Modernización puede ser tan simple como mover de una DB en EC2 a RDS (Replatform), o containerizar el monolito sin dividirlo. Los microservicios son el extremo del espectro — no siempre es la meta correcta.
Trampa: "Strangler Fig requiere reescribir toda la aplicación"
Realidad: Todo lo contrario. Strangler Fig es un patrón INCREMENTAL — extrae una funcionalidad a la vez sin tocar el resto del monolito. El monolito sigue funcionando durante toda la transición.
Trampa: "Blue/Green deployment y Canary son lo mismo"
Realidad: Diferentes. Blue/Green cambia el 100% del tráfico de una vez (después de validar green). Canary lleva un porcentaje pequeño (5-10%) de tráfico a la nueva versión gradualmente antes de hacer el cambio completo.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa tiene un monolito Java que se despliega en 4 instancias EC2 detrás de un ALB. Quieren modernizarlo gradualmente hacia microservicios sin interrumpir el servicio. El módulo de notificaciones es el primero a extraer. ¿Cuál es el enfoque correcto?
Inicia sesión para llevar tu progreso.