Migrar un backend en producción a otro cloud sin downtime: la verdadera apuesta es el diseño

El artículo describe la migración de un backend en producción de un cloud a otro, sin interrupciones y con tráfico real. La decisión se basó en la necesidad de autoscaling y spot instances más económicas, y en problemas recurrentes de permisos.\n\nEl traslado físico se realizó en dos días, pero el tiempo invertido en diseñar la nueva arquitectura fue de un mes. La lección principal: no copiar el estado de una máquina a otra; cada instancia debe configurarse desde cero con un archivo de configuración simple.\n\nEl proceso de migración incluyó tres intentos fallidos de copiar la configuración del “máquina origen”. El fallo se debió a que la configuración original se guardaba en un directorio distinto cuando no se pasaba un flag de configuración aislada. Finalmente, la solución fue instalar cada nodo nuevo sin copiar estado, lo que funcionó de inmediato.\n\nSe realizaron pruebas de carga real en lugar de suposiciones. A bajas cargas el CPU rondaba el 22 %, pero en cargas moderadas subía al 92 %. Esto llevó a reducir la capacidad segura a la mitad, evidenciando que el límite real era la CPU y no la memoria. También se detectó un bug donde una conexión fallida bloqueaba otra distinta bajo concurrencia.\n\nEn cuanto al balanceo de tráfico, se optó por un passthrough sencillo en lugar de una capa de enrutamiento compleja, porque el servicio ya gestionaba su propia encriptación. El despliegue se hizo en dos pasos reversibles: primero se añadió el nuevo punto de entrada junto al antiguo, y una vez confirmado su funcionamiento, se retiró el camino original.\n\nEl diseño de la política de escalado se dejó manual al principio, con la intención de evitar una política automática basada en hipótesis. Se planificó construir una política automatizada después de obtener datos de uso real.\n\nLa revisión de permisos fue exhaustiva: se eliminaron permisos amplios no necesarios y se agregaron restricciones explícitas a las acciones sensibles. Este análisis descubrió una brecha real cuando un recurso faltaba una etiqueta necesaria para una regla de seguridad, lo que habría bloqueado una acción legítima.\n\nEn síntesis, la migración se completó sin downtime, pero el verdadero trabajo fue diseñar una arquitectura limpia, probarla bajo carga real y asegurar permisos mínimos. La experiencia demuestra que la planificación y el diseño son los verdaderos retos de una migración de infraestructura.