De Heroku a AWS sin caídas, con 14 millones de USD al mes
Migración de Heroku a AWS en 14 semanas sin interrupciones: −35 % de costo de infraestructura, −93 % de tiempo de despliegue y +800 % de frecuencia.
El cliente procesa unos 14 millones de USD al mes en más de 180 000 transacciones, para unos 900 comercios pequeños y medianos de Estados Unidos y Canadá. Toda la plataforma funcionaba como una aplicación monolítica en Ruby on Rails sobre Heroku, y esa arquitectura se había convertido en el principal freno del negocio.
El problema se podía medir. Cada despliegue era un reinicio completo de 38 minutos, permitido solo dos veces por semana dentro de una ventana de mantenimiento. Un despliegue fallido había causado una interrupción de 47 minutos en horas de máxima actividad y unos 62 000 USD en transacciones fallidas. Heroku no permitía escalar los componentes por separado, así que los picos de informes de fin de mes obligaban a escalar toda la aplicación. Los costos habían llegado a 14 200 USD al mes y subían entre un 8 y un 12 % cada mes. Además, un solo error en cualquier parte podía tumbarlo todo: un error de formato en los informes bloqueó una vez la cola de pagos durante 23 minutos, lo que costó dos clientes potenciales del segmento de grandes empresas.
La condición del CTO era absoluta: sin ventana de migración y sin ninguna alteración visible para los comercios. La migración tenía que hacerse por debajo del tráfico real de pagos.
Primero se hizo una evaluación de la infraestructura, por 6000 USD: revisión del código Rails (unas 85 000 líneas), mapa del esquema de 47 tablas (12 de ellas con más de un millón de filas) y trazado de peticiones. El trazado mostró que las consultas de informes consumían el 60 % de la CPU de la base de datos a fin de mes, mientras que la ruta de pago en sí tenía una latencia p99 de 340 ms. Recomendamos el patrón strangler fig (higuera estranguladora): extraer los servicios de uno en uno, mantener el sistema antiguo y el nuevo en paralelo y mover el tráfico gradualmente. El orden de extracción se fijó según el riesgo: notificaciones, informes, onboarding, webhooks y, en último lugar, el núcleo de pagos.
Las semanas 3 y 4 sirvieron para construir la base antes de extraer nada: todos los recursos de AWS definidos en Terraform, CI/CD con GitHub Actions, con análisis de seguridad y despliegues blue-green en EKS, y una plataforma de observabilidad con Datadog instalada desde el principio para detectar en segundos cualquier discrepancia entre el sistema antiguo y el nuevo.
Las extracciones de bajo riesgo ocuparon las semanas 5 a 8. El servicio de notificaciones funcionó en paralelo durante 5 días, con una tasa de discrepancia del 0,00 %, antes del cambio definitivo. Mover los informes a una réplica de lectura redujo la CPU de la base de datos principal del 78 % al 31 % y, como efecto secundario, mejoró la latencia p99 de los pagos de 340 ms a 180 ms. El núcleo de pagos se migró al final, con la máxima cautela: 48 horas de tráfico en sombra (shadow traffic) con 12 000 transacciones y un 0,00 % de discrepancia, y después un traslado progresivo del 1 % al 100 % del tráfico a lo largo de 10 días, con un plan de vuelta atrás probado en cada paso. La semana 14 terminó con runbooks, transferencia de conocimiento y un game day de 3 horas de inyección de fallos.
Medido en los primeros 90 días tras la migración frente a los 90 días anteriores: el tiempo de despliegue bajó de 38 minutos a 2,5 minutos por servicio (−93 %), la frecuencia de despliegue subió de 2 a 18 veces por semana (+800 %), el costo mensual de infraestructura bajó de 14 200 a 9230 USD (−35 %), la latencia p99 de los pagos mejoró de 340 ms a 145 ms (−57 %) y las consultas de informes de fin de mes pasaron de entre 12 y 45 segundos a entre 2 y 8 segundos (−82 %). Tiempo de inactividad no planificado: 70 minutos antes, cero después. Tiempo de inactividad durante la migración: cero.
Con el crecimiento del volumen de la empresa, del 15 % trimestral, los costos de Heroku habrían llegado a 22 000 USD al mes a final de año. La arquitectura en AWS se proyecta en 11 500 USD al mes con el mismo volumen, un ahorro anual creciente de más de 120 000 USD. La migración de 74 000 USD se recupera en 14,8 meses solo con el ahorro en infraestructura, sin contar la eliminación de un riesgo de interrupción de 62 000 USD por incidente.
El cliente mantuvo a un ingeniero DevOps de Gigabit con un contrato continuo de SRE, por 5500 USD al mes. En su hoja de ruta actual figuran el despliegue en varias regiones, un pipeline de detección de fraude en tiempo real y una infraestructura para SOC 2 Tipo II.
Tres empresas nos presentaron una propuesta para esta migración. Dos proponían un «lift and shift» de 12 meses con un fin de semana de migración. Gigabit propuso un enfoque strangler fig de 14 semanas, con la garantía de no tener ninguna interrupción. Entregaron exactamente lo que prometieron: ni un solo comercio notó que la migración había ocurrido. Pasamos de desplegar dos veces por semana a varias veces al día. Solo eso ha cambiado la velocidad a la que podemos lanzar producto.
Nuestros casos de éxito publicados son, en su mayoría, de empresas de Norteamérica. Todos los importes están en dólares estadounidenses (USD). El cliente es anónimo.


