Introducción

Recuerdo que en un viaje con mi socio Sebastián volviendo de un AWSome Day en Barcelona (antes de que el AWS Summit llegase a la capital), veníamos charlando con unos amigos del sector sobre una colaboración con ellos como resultado de sus necesidades para el día a día y de que estaban en mitad de un proceso de migración de su infraestructura.

Para ellos dicho proceso estaba siendo muy duro, y nunca se nos olvidará la frase que nos dijeron: “Vosotros vivís continuamente en el infierno”, haciendo referencia a que nosotros realizábamos eso de manera continua en el día a día con un cliente detrás de otro :D.

En cierta manera era cierto,  ya que llevábamos y llevamos muchos años haciendo migraciones con la carga de trabajo, el estrés y la responsabilidad que conlleva, ¡nos va la marcha!.

Hablando de esto, en el siguiente artículo voy a contaros algunas de las cosas que tenemos en cuenta y hacemos para que las migraciones salgan bien y el infierno que nos decían, se parezca más a un buen concierto de rock que a una mala cárcel.

El artículo es un poco largo, por lo que si lo prefieres, aquí tienes enlaces a las diferentes secciones:

• Rollback
• Tipos de migración
• Propósito de la migración
• Plazos
• Costes
• Downtime
• Diseño y requisitos
• Ejecución
• Post-migración

Rollback

Si hacemos todo muy bien seguramente completaremos la migración, pero hay que pensar que pueden surgir inconvenientes no contemplados o algún problema que impida completar la migración o requiera dar marcha atrás.

Por ello, en la medida de lo posible, tendremos que tener opciones de rollback siempre que sea posible en tiempos razonables.

Normalmente las migraciones conllevan cambios de DNS y deberíamos garantizar que el rollback es inmediato al menos hasta que este cambio se acometa. Tras él, idealmente deberíamos tener una opción de rollback por ejemplo con una replicación inversa, pero en muchos casos no es posible o resulta demasiado complejo/costoso y es mejor recuperar hacia adelante solventando los inconvenientes que surjan.

En cualquier caso, todo los equipos involucrados en la migración deben tener claro las opciones que tenemos en este sentido y cómo se deben ejecutar.

Tipos de migración

Las migraciones pueden ser de diferentes tipos o incluso mixtas, pero podemos hablar fundamentalmente de:

• Migración tecnológica: normalmente se hace dentro del mismo proveedor de infraestructura y se da cuando sustituimos una tecnología por otra, por ejemplo porque pasamos de usar un tipo de base de datos a otro.
• Migración de servicio: no es un cambio de tecnología como tal, pero realizamos un proceso de upgrade usando para ello nueva infraestructura o incluso pasamos de servicios gestionados por nosotros a servicios gestionados por el proveedor cloud.
• Migración de proveedor: en este caso nos llevamos nuestra tecnología de un proveedor de infraestructura a otro de manera completa.

En nuestro caso, lo habitual es trabajar sobre todo en las dos últimas opciones. En el primer caso damos soporte y preparamos las infraestructuras o sistemas necesarios, pero el trabajo de migración suele acometerlo el equipo de desarrollo de nuestro cliente.

Propósito de la migración

Una de las cosas a tener clara en el proceso de migración es el fin que se persigue con ella, esto permite que todo el equipo esté alineado y sepa por qué y para qué se hace.

En este sentido, podemos estar hablando de que hacemos la migración principalmente por alguno o varios de estos motivos:

• Motivos de compliance (ejemplo cumplir con normativa de mercados regulados).
• Acuerdos de negocio o decisiones de la organización.
• Mejora técnica en lo que se refiere a escalabilidad y resiliencia.
• Ahorro de costes.

Plazos

En STR, cuando la migración depende prácticamente de nosotros, no fijamos fecha de migración hasta que tenemos todo listo. Al fin y al cabo el presupuesto para nuestro cliente suele ser cerrado, y salvo que haya un evento concreto que marque una necesidad (un lanzamiento, una campaña, etc.), lo hacemos así.

Lo de no realizar estimaciones mola mucho, pero en estos procesos siempre se requieren fechas dada la cantidad de equipos que pueden estar involucrados en una migración de cierto tamaño. Por ello, una de las cosas más importantes es la definición realista de plazos que muchas veces va ligado también al tema de costes.

La única recomendación en este caso es ser realista con los plazos, teniendo en cuenta todas las partes implicadas en el proceso de migración para evitar llegar a la fecha con estrés o sobretrabajo brutal.

Estas situaciones nos han pasado y pasarán a todos, a veces por una mala planificación u otras veces porque surgen cambios importantes y hay que dar una solución. Sin embargo, debemos evitarlo especialmente si este tipo de procesos es nuestro día a día y no algo puntual, ya que si no, viviremos auténticos momentos de tensión, agotamiento o estrés. 

En estos casos es especialmente importante tener en cuenta la desviación que puede surgir cuando parte de las acciones a realizar dependen de terceros como es el caso de comunicaciones vía VPN por ejemplo.

Costes

A la hora de plantear una migración de este tipo debemos tener en cuenta que se generarán unos costes considerables derivados de:

• Infraestructura duplicada temporalmente y costes derivados de movimiento de datos entre infraestructuras.
• Costes propios de la ejecución del proyecto:
  • Dedicación completa de los equipos dedicados a la migración.
  • Dedicación parcial de otros equipos de los que se puede requerir cambios, ajustes o disponibilidad.
• Costes generados por la pérdida de transacciones/ventas durante el tiempo de downtime de la migración y errores posteriores.

Downtime

En estos años, nos hemos encontrado muy pocas empresas que hayan tenido la creencia de que pueden hacer una parada de servicio planificada sin problema, ya que la mayoría piensa que su servicio nunca puede parar. Esto suele ser totalmente falso, salvo que seas un hospital, una torre de control aérea o cosas similares.

En casos en los que no hay un cambio de proveedor, muchas veces es viable realizar migraciones sin prácticamente downtime, pero en las migraciones de proveedores es muy complejo llegar a ello. Por esa razón, la recomendación casi siempre es hacer las migraciones con downtime. En la mayoría de los casos es absurdo plantear el sobrecoste de una migración de sistemas sin downtime, salvo que nuestra tecnología permita de manera nativa funcionar distribuida especialmente en lo que a bases de datos y datos de usuario se refiere.

La razón para esto es que es preferible una parada de servicio planificada y comunicada que facilite y asegure el éxito, que una parada de servicio no contemplada con incidencia de por medio. Por supuesto, siempre se debe optimizar el proceso para que el tiempo de indisponibilidad sea el menor posible.

Si realmente estás en el caso de que no te puedes permitir hacer una parada de servicio, tendrás que desarrollar tecnología específica para la migración, hacer uso de proxies, asumir degradación de latencia para comunicar las dos plataformas temporalmente, etc.

Diseño y requisitos

Un buen diseño y planificación facilitará en gran medida la ejecución del proceso de migración.

Para realizar una migración, lo primero que debemos hacer es diseñar la arquitectura a la cual vamos a migrar y para ello debemos conocer previamente:

• Tecnologías y arquitectura software del nuevo sistema.
• Arquitectura y/o plataforma origen desde la que vamos a migrar.
• Requisitos de disponibilidad y escalabilidad requeridos.
• Tiempos máximos de parada permitidos en el proceso de migración.

Con toda esa información diseñaremos:

• La nueva arquitectura e infraestructura que deberá ser desplegada.
• Los procesos de migración y sincronización de datos.
• El proceso de migración real así como todo lo que sea necesario desarrollar (scripts, aplicaciones, infraestructura como código, etc.) para facilitar la migración

Es importante que en este proceso realicemos al menos un checklist de los siguientes puntos:

• Tener conocimiento de todos los orígenes de datos a migrar, ya sean ficheros, bases de datos, cachés, etc. para evaluar y establecer los sistemas de replicación incremental o incluso en tiempo real a la nueva plataforma.
• Requisitos de seguridad mínimos establecidos en la organización y aplicables al proyecto en cuestión para poder establecer aquellos que tengan implicaciones de arquitectura o de networking desde el momento inicial a ser posible.
• Sistemas de comunicación especiales tales como VPN, peering o cualquier otro similar teniendo en cuenta que aquí puede haber 

Tan importante como la parte técnica es la comunicación, por lo que igualmente será necesario conocer todos los actores que estarán involucrados en el proceso de migración para poder agilizar cualquier cuestión cuando sea necesario. Idealmente alguien con visión global deberá coordinar todo para facilitar estas comunicaciones.

Ejecución

Para los entornos productivos realizamos siempre migraciones en tres fases:

• Fase 1: despliegue y configuración de la infraestructura y servicios, monitorización/observabilidad y configuración de backups.
• Fase 2: pruebas de migración real con datos existentes en un momento dado realizando todos los ajustes necesarios.
• Fase 3: migración real con datos con replicación continua (durante este tiempo no se puede hacer uso de la plataforma ya que los datos ya son reales y están preparados para la migración final)

En los entornos no productivos realizamos el mismo proceso, pero en muchas ocasiones no es necesario la carga de datos múltiples veces y se hace un proceso más evolutivo. Estos entornos siempre van antes y permite detectar errores de configuraciones, conectividad, etc.

Una vez tenemos todo preparado y tenemos que ejecutar la migración real siempre digo lo mismo: hay que funcionar en modo robot. ¿Qué quiere decir esto? Sencillo, todo debe estar pensado y preparado con anterioridad. En la migración real no es el momento de ponerse a pensar (salvo que surjan incidencias o inconvenientes no detectados ni previstos con anterioridad), lo que se traduce en:

• Tener muy bien probadas todas las parte del proceso de migración que sean posibles en la fase 2.
• Disponer de automatización, scripts, guíaburros o cualquier otra cosa que permita ejecutar el proceso ya probado sin necesidad de pensar, programar, etc.
• Dependiendo de la complejidad de la migración y de la cantidad de personas implicadas, tener definido por ejemplo en una hoja de cálculo todas las tareas a realizar, el orden y la persona responsable de ello.
• Realizar pruebas antes de realizar el cambio de DNS final o el proceso equivalente que haga que el servicio esté disponible para todos los usuarios del mismo.

Por supuesto, tras la migración real, igual que se ha debido realizar en la fase anterior,  se deben realizar pruebas exhaustivas teniendo en cuenta que ya estamos en un entorno real. Para esta parte, el haber configurado previamente una buena monitorización y sistemas de observabilidad así como disponer de tests automatizados nos ayudará en esta labor.

Una recomendación para el momento después inicial, especialmente si se trata de una plataforma cloud dinámica, es sobredimensionar la plataforma inicialmente para luego ir reduciéndola y ajustando a las necesidades reales. Esto nos permite evitar sorpresas como por ejemplo una base de datos demasiado pequeña en un momento ya de por sí crítico.

Post-migración

Debemos tener en cuenta que la migración no acaba cuando el servicio está corriendo en la nueva plataforma, normalmente debemos contar al menos con que durante las primeras horas o días podrán surgir incidencias o inconvenientes que será necesario atender con la prioridad requerida.

Esto será especialmente importante en el siguiente día o momento pico, si los hubiera, de actividad previsto ya que será cuando realmente se podrá ver el comportamiento de la nueva plataforma o sistema.

Encantados de ayudarte si necesitas o quieres migrar tus sistemas y necesitas ayuda ;)