✨ Por qué todas las migraciones de aplicaciones deberían ser incrementales
Tags: nextjs, webdev, javascript, programming
Published: 2023-11-11 21:00:48

> Las migraciones grandes son inevitables, pero no tienen por qué ser dolorosas ni arriesgadas. Descubre por qué migrar de manera incremental es la solución.

En el año 2023, son pocos los proyectos de software que son verdaderamente nuevos desde cero. En su lugar, las migraciones de sistemas existentes son la nueva norma. Las migraciones mal ejecutadas pueden introducir riesgos sustanciales para el negocio y los plazos en cualquier proyecto de software. Una estrategia de migración incremental puede minimizar esos riesgos al tiempo que adelanta la validación del impacto empresarial.

El producto de Vercel está diseñado para admitir la migración incremental desde el principio. En este artículo, obtendrás una visión general de alto nivel de las estrategias y consideraciones de migración incremental.

## ¿Por qué migrar de manera incremental?
Casi todos los proyectos de software que requieren migraciones deberían apuntar a migraciones incrementales con el fin de:

- Minimizar el riesgo al reducir el alcance de los pasos individuales de la migración.
- Minimizar el riesgo al tener un camino más natural para retroceder en caso de problemas inesperados.
- Permitir la validación de la implementación técnica y el valor empresarial de manera sustancialmente más temprana en el proceso.
- Lograr una migración sin tiempo de inactividad y sin ventanas de mantenimiento.

**Comprender las migraciones ‘big bang’**
Las migraciones ‘big bang’ son migraciones en las que se reemplaza un sistema de una sola vez en un cambio completo. Puede haber pasos intermedios, pero se realizan todos en un período muy corto. Básicamente, eliges una fecha y en esa fecha, todo el uso se traslada del sistema antiguo al nuevo sistema.

![Big Bang](https://miro.medium.com/v2/resize:fit:828/format:webp/1*rGIP-a9ITmE_LFXTNGE8Mw.png)

Problemas con las migraciones ‘big bang’ pueden incluir:

- Puedes pasar por todo el proceso solo para descubrir que hay problemas de producto que son muy costosos de solucionar tan tarde en el programa.
- Los ensayos son inherentemente difíciles de ejecutar, lo que dificulta evaluar de antemano si una migración tendrá éxito.
- Puedes llegar a un punto de no retorno en el que una migración debe completarse incluso si se notan problemas importantes mientras está en curso.
- Puede ser necesario poner fuera de línea el sistema antiguo mientras se realiza la migración, lo que lleva a la pérdida de negocio. Estas ventanas de mantenimiento a menudo se prolongan en duración a medida que se descubren problemas solo durante la ejecución de la migración.

**¿Qué es una migración incremental?**

![Legacy sistem](https://miro.medium.com/v2/resize:fit:828/format:webp/1*J3_mfioxTTCXJQenxRj2ng.png)

Una estrategia de migración incremental implica la transición gradual a un sistema de software nuevo o significativamente actualizado. Durante este proceso, tanto los sistemas antiguos como los nuevos se ejecutan simultáneamente, y las características o usuarios se trasladan en fases en lugar de hacerlo todo de una vez.

Existen dos tipos principales de migraciones incrementales:

**1. Vertical: Incrementos por características**

![All features on legacy system](https://miro.medium.com/v2/resize:fit:828/format:webp/1*x9IWksTyBzSZjnxzjyhlWA.png)

En esta estrategia, se cambian subconjuntos de la funcionalidad del sistema al nuevo sistema. Piensa en esto como migrar una característica a la vez, donde ambos sistemas operan en paralelo y la funcionalidad se dirige al sistema nuevo o antiguo según si la característica respectiva ha sido migrada o no.

**2. Horizontal: Incrementos por usuario**

![Migration increments](https://miro.medium.com/v2/resize:fit:828/format:webp/1*uzpQPcTAnwcru9P0mN6afA.png)

En las migraciones horizontales, aunque “los usuarios” son comúnmente la unidad principal que se traslada, se pueden usar otras entidades en su lugar. La elección ideal sería una entidad que se pueda dividir o “fragmentar” fácilmente dentro de un sistema, garantizando una interacción mínima entre estos fragmentos separados.

No sería raro ver estrategias de migración incremental verticales y horizontales combinadas en migraciones complejas. En ese caso, verías una migración por usuario en una base por característica.

## Compromisos de las migraciones incrementales
El principal compromiso de las migraciones incrementales es la introducción de un esfuerzo adicional para implementar la interoperabilidad entre el sistema nuevo y el antiguo. Esto debe sopesarse frente a la reducción del riesgo y la mayor rapidez en la validación del valor empresarial.

Esto es particularmente desafiante si los sistemas deben acceder a los datos de cada uno. En el caso de una migración incremental horizontal, la elección correcta de la unidad de incremento es la decisión más crucial para minimizar las dependencias de datos. Las entidades comunes donde esto es cierto son un “usuario” o una “organización”.

## Migraciones de frontend
Las migraciones de frontend son un caso especial de migración en el que se migra una capa de frontend mientras el backend permanece estable. Las migraciones de frontend suelen ser más fáciles de ejecutar porque los datos con estado siguen siendo gestionados por el mismo “sistema de registro”, y solo se actualiza la representación y el procesamiento de los datos del backend.

Si bien el término “frontend” a veces evoca expectativas de interfaces de usuario y modalidades similares, el principio de la migración en capas se puede extender profundamente en sistemas más grandes: por ejemplo, incluso si se intercambian sistemas enteros, incluyendo sus bases de datos principales, puede ser útil mantener la capa de almacén de datos estable y alimentar datos desde sistemas antiguos y nuevos de manera concurrente.

![Frontend migration](https://miro.medium.com/v2/resize:fit:828/format:webp/1*sbPqNr5qBa9kecWVB-UHQA.png)

No cambiar las capas de análisis al mismo tiempo que las aplicaciones tiene el beneficio adicional de mantener un sistema confiable para juzgar el rendimiento del nuevo sistema.

![New fronted](https://miro.medium.com/v2/resize:fit:828/format:webp/1*a3alEY15bqRaXtaAOeLk8A.png)

## Migración de monolítica a arquitectura componible
Un caso especial de migración de frontend es aquel en el que el sistema antiguo no se descompuso adecuadamente en backend y frontend. Si el objetivo es cambiar a un nuevo frontend, puede ser posible introducir una API en el sistema antiguo de manera que un nuevo frontend se pueda introducir mientras se mantiene el sistema existente como backend.

Lo anterior es común cuando las empresas optan por sistemas monolíticos que acoplan el frontend y el backend en un solo sistema. A medida que estas empresas desean tener más control sobre la interfaz de usuario que presentan a sus usuarios, a menudo introducen frontends separados que tratan al monolito anterior como un servicio de API.

**Migración de un frontend web**
El elemento clave para la migración incremental de frontends web es el proxy inverso. Los proxies inversos permiten a un servidor web servir contenido desde múltiples servidores web diferentes bajo su dominio principal.

![Incoming request](https://miro.medium.com/v2/resize:fit:828/format:webp/1*AU-tdNe_rQDTNRievbmX_Q.png)

**Paso 1: Introducir un proxy inverso sin cambios en la funcionalidad**
El primer paso de cualquier migración a una nueva infraestructura de servicio es introducir un proxy inverso que redirige todas las solicitudes a la infraestructura heredada. El proxy inverso puede:

- Estar ubicado junto al nuevo frontend (recomendado).
- Estar en el frontend antiguo.
- Estar en un sistema dedicado introducido específicamente para la migración.

Se recomienda colocar el proxy inverso junto al nuevo frontend porque permite exponer la nueva infraestructura al tráfico de producción sin cambios esperados en el comportamiento.

Las aplicaciones de Vercel vienen con funcionalidad de proxy inverso incorporada para ayudar a implementar estas migraciones. Es importante destacar que el proxy inverso se puede programar a través de Edge Middleware, lo que facilita la implementación de los incrementos de migración y los adaptadores de solicitudes entre sistemas nuevos y heredados.

Cuando se completa esta etapa, la nueva infraestructura está formalmente en producción, pero toda la lógica real la proporciona el sistema heredado. Esperamos que no haya cambios en el comportamiento después del paso 1, por lo que es fácil verificar que esta etapa de la migración fue exitosa.

**Paso 2: Comienza a migrar partes del tráfico**
Al comienzo del paso 2, el nuevo sistema atiende todo el tráfico, pero no ejecuta la lógica de la aplicación real. Ahora es posible configurar el nuevo sistema para tomar parte del tráfico mientras sigue enrutando todo el otro tráfico al sistema heredado.

Por ejemplo, en una tienda en línea, uno podría comenzar a servir un subconjunto de las páginas de detalles de productos desde el nuevo sistema, mientras que todo lo demás se enruta. Estos incrementos en la funcionalidad se pueden validar paso a paso.

Con el tiempo, un porcentaje cada vez mayor de las páginas son servidas por el nuevo sistema, hasta que eventualmente el 100% del tráfico sea gestionado directamente por el nuevo sistema. En esta etapa, el proxy inverso al sistema heredado puede ser apagado y la migración en términos de efectos visibles para el usuario está completa.

**Migraciones de tráfico**
Las migraciones de tráfico son un caso especial de migración incremental horizontal.

Actualmente, Vercel se encuentra en medio de una importante migración incremental de su sistema principal de servicio. El equipo ha elegido una estrategia de migración incremental en combinación con lanzamientos oscuros (dark launches). Su objetivo para el nuevo sistema es tener compatibilidad bug-for-bug con el sistema heredado mientras mejora sustancialmente la latencia y el uso de la CPU.

Un lanzamiento oscuro es la introducción de un sistema secundario mientras que un sistema existente continúa sirviendo el tráfico orientado al usuario. En nuestra fase de lanzamiento oscuro, enviamos tráfico tanto al sistema antiguo como al nuevo y comparamos los resultados para validar que se comporten exactamente de la misma manera.

Naturalmente, un lanzamiento oscuro utiliza recursos adicionales (ya que tanto los sistemas antiguos como los nuevos están involucrados en el mismo tráfico, efectivamente duplicando las necesidades de procesamiento). Por lo tanto, es recomendable ejecutar solo un subconjunto del tráfico a través del camino del lanzamiento oscuro.

En Vercel, nuestro plan de implementación incremental se ve así:

- Lanzamiento oscuro para X% del tráfico.
- Observar diferencias en las respuestas entre el sistema antiguo y el nuevo.
- Si es necesario, corregir el comportamiento del nuevo sistema.
- Validar que el nuevo sistema, de hecho, mejora la latencia y el uso de la CPU.
- Una vez que el lanzamiento oscuro se comporta de manera suficientemente similar al nuevo sistema y se alcanzan los objetivos del nuevo sistema, cambiar el mismo X% del tráfico al nuevo sistema.
- Repetir hasta que el 100% del tráfico esté migrado.
Hasta la fecha, hemos completado con éxito esta migración y ahora estamos sirviendo el 100% del tráfico en el nuevo sistema.

## Resumen
Las migraciones incrementales pueden parecer como un alcance adicional que uno podría desear evitar, pero las organizaciones maduras se dan cuenta de que generalmente valen el esfuerzo. Las migraciones incrementales minimizan el riesgo, mejoran el tiempo para validar el valor empresarial de un cambio y eliminan el tiempo de inactividad planificado.

Las migraciones de frontend son un caso especial de migraciones en las que los sistemas de registro se mantienen iguales mientras se reemplaza el frontend. Las migraciones a Vercel a menudo son de este tipo. Nuestra plataforma proporciona herramientas especializadas para respaldar estas migraciones a través de enrutamiento inverso y una gestión detallada de solicitudes en Edge Middleware.