Nube AWS y DevOps: serverless, CI/CD y costos

Antes de migrar nada hacemos un inventario con acceso de solo lectura a lo que tienes: qué corre, de qué depende, qué falla y qué cuesta. Con eso se decide qué se migra, en qué orden y qué no conviene mover. La migración se ejecuta por etapas; cada etapa tiene una ventana de corte acordada por escrito, un plan de reversa probado y un criterio de aborto. No prometemos que nadie lo note; prometemos que, si algo sale mal, se vuelve al estado anterior.

¿Cómo saben si mi infraestructura está lista para migrar a AWS?

Con un inventario, no con una suposición:

1. Qué corre. Aplicaciones, bases de datos, tareas programadas, archivos compartidos, integraciones con terceros.
2. De qué depende cada cosa. Qué aplicación habla con qué base, qué proceso corre de noche, qué usuario tiene qué acceso. Lo que no está documentado se descubre observando el sistema, no preguntando.
3. Qué falla y qué duele. Caídas, respaldos que nadie ha probado, un servidor que nadie quiere tocar.
4. Qué cuesta hoy. Hardware, licencias, electricidad, horas de mantenimiento, y qué costaría en AWS según la calculadora pública de AWS (https://calculator.aws/) con las cargas reales medidas.

El resultado es un plan por escrito: qué se migra primero, qué se migra después, qué se rediseña como serverless en lugar de copiarse tal cual, y qué se queda donde está.

¿La migración interrumpe la operación?

Se migra por etapas para que la interrupción sea acotada y conocida de antemano. Cada etapa tiene:

• Ventana de corte acordada. Un día y una hora en que esa carga cambia de lugar, elegidos con quien opera el proceso (fuera de cierre de mes, fuera del turno más cargado).
• Validaciones intermedias. Antes del corte, la carga corre en AWS en paralelo o con datos de prueba, y se comprueba con los usuarios que importan.
• Plan de reversa probado. Cómo volver al estado anterior, cuánto tarda y quién lo ejecuta. Se ensaya antes del corte, no se improvisa durante.
• Criterio de aborto. Qué señal (un error, un tiempo de respuesta, un reporte que no cuadra) obliga a revertir, decidido antes para no discutirlo a las dos de la mañana.

Ejemplo de orden típico: primero las cargas con menos dependencias y más dolor (una base de reportes, los respaldos, un sitio público); después las aplicaciones internas; al final lo que todo el mundo usa todo el día, con el plan de reversa ya ensayado en las etapas anteriores.

¿Qué es un plan de reversa y por qué importa más que una garantía?

Un plan de reversa es el procedimiento, por escrito y probado, para devolver una carga a donde estaba si la etapa falla: datos, DNS, accesos y quién hace qué. Una garantía de «cero interrupciones» no se puede sostener; un plan de reversa sí se puede ejecutar. Por eso es lo que se entrega.

¿Cuándo no conviene migrar a AWS?

Si la carga es estable, ya está dimensionada y el costo local sigue siendo menor que el estimado en AWS, lo decimos en el inventario. También cuando una aplicación vieja no se puede mover sin reescribirla y nadie la va a reescribir: ahí conviene aislarla, respaldarla bien y migrar lo demás a su alrededor.