De un VPS a AWS en dos pasos: primero migrar, después modernizar
- Sector
- Farmacéutica
- Duración
- 2 días el rehost · 1 semana la modernización
- Rol
- Propuesta, diseño y ejecución
01El punto de partida
La aplicación, la base MySQL y Redis para sesiones y caché compartían un VPS, y los archivos de los usuarios estaban en su disco. Un fallo se llevaba todo, y había que salir de ahí con poco tiempo.
02Con qué no se podía negociar
- Había poco tiempo: la migración no podía esperar a la modernización.
- Un contenedor se reemplaza en cualquier momento: no puede guardar nada en su disco.
- Toda la infraestructura queda escrita como código.
03La decisión
Dos pasos en lugar de uno. Primero, rehost: la misma aplicación en una instancia de AWS, sin cambios, para cumplir la fecha. Después, sin el reloj encima, replatform: contenedores, MySQL y Redis administrados, y los archivos en almacenamiento de objetos. Todo lo que tenía estado salió del servidor, que es lo que permite reemplazar un contenedor sin perder nada. Hacer las dos cosas juntas era un solo corte, con dos cambios grandes a la vez y sin forma de saber cuál rompió qué.
04El trade-off
- Lo que se cedió
- Se migró dos veces: dos cortes y dos verificaciones de datos. Y por un tiempo, AWS corrió la misma máquina única que el VPS, con los mismos riesgos.
- Por qué valió la pena
- El primer paso sacó la fecha del medio y el segundo se hizo con calma. Separar la migración del cambio de arquitectura permite saber, si algo falla, cuál de las dos fue.
05El resultado
La aplicación ya no depende de una máquina: los contenedores se reemplazan sin perder nada, porque la base, las sesiones y los archivos viven afuera. Desplegar es publicar una imagen nueva, y la infraestructura está escrita como código.
¿Tienes algo parecido por delante? Cuéntame el caso y te respondo, casi siempre dentro de las 24 horas.
Hablemos