Tipos de Migración a la nube

Seguimos con algunos contenidos teoricos basicos de Cloud, en este caso vamos a hablar sobre las diferentes estrategias de migración. Pueden revisar la nota de Fundamentos de Cloud Computing – Aprende Multi Cloud(s) (madsblog.net)

Table of Contents

Introducción

Cuando comenzamos a planificar nuestro proceso de migración debemos comenzar por determinar nuestro destino y punto de partida. Nuestro punto de partida puede ser: on-premises, co-hosting, housing o desde un proveedor de nube (migración cloud to cloud). Nuestro destino será la Nube, del proveedor que más nos guste.

Aquí es donde debemos tener en cuenta que nuestro proceso de migración debe ser cuidadosamente evaluado, debe involucrar un proceso de descubrimiento y análisis detallado de nuestra infraestructura fuente.

Recomiendo prestar mucha atención al proceso de Evalución y Descubrimiento, ya que este sentará las bases de nuestro proceso de migración y nos permitirá que sea exitoso.

Involucrar a los equipos

Los procesos de migración normalmente son llevados acabo y son responsabilidad del equipo de infraestructura, pero es muy importante que este proceso involucre tambien:

Los owners tecnicos de las aplicaciones (con esto me refiero al código).
Los owners de negocio de las aplicaciones.
Equipos de liderazgo y roles claves.
Equipos encargados de dependencias o integraciones de las aplicaciones involucradas.

Tipos de Migración

Podemos clasificar las migraciones en los siguientes tipos:

Rehost: lift and shift.
Replatform: lift and optimize.
Refactor: move and improve.
Re-architect: continue to modernize.
Rebuild: remove and replace, tambien llamado rip and replace.
Repurchase.

Rehost: Lift and Shift

Empezamos con el conocido “levantar y mover”. Este tipo de migración involucra mover las cargas de trabajo “as-is” (como están), realizando solo las minimas modificaciones par que las cargas de trabajo puedan funcionar de manera optima en el ambiente de destino.

Este tipo de migración es ideal para setear las foundations a la hora de migrar a la nube. Esto permite que el equipo pueda comenzar a ver algunos de los beneficios de estar en la nube pero manteniendo las mismas herramientas y habilidades que utilizaban en on-prem.

Lift and Shift es muy rapido y es relativamente sencillo, ademas todos los Cloud Providers tiene alguna herramienta Nativa que permite realizar este procedimimiento sin inconvenientes y con una herramienta soportada por el fabricante que es capaz de integrarse con diferentes plataformas de Source como VMWare para VMs o directamente para servidores fisicos. Ejemplos de estas herramientas: GCP Migrate to Virtual Machines o Azure Migrator.

Mantener cargas de trabajo en IaaS en la nube puede ser costoso. Al migrar utilizando el enfoque Lift and Shift, los costos suelen ser elevados porque no aprovechamos al máximo los beneficios que ofrece la nube. Si bien este modelo reduce las responsabilidades para los administradores, ya que el proveedor de la nube se encarga del mantenimiento del hardware, hipervisores, redes, entre otros, no resulta muy eficiente en cuanto al valor de cómputo frente al costo. De hecho, muchas organizaciones que dependen en gran medida de IaaS terminan optando por un Cloud Exit.

Debemos estar atentos y optimizar nuestras cargas de trabajo para la Nube.

Replatform: lift and optimize

En este tipo de migración, toma muchas mas de las ventajas de las competencias nucleo de Cloud: elasticidad, redundancia, optimización de performance y seguridad.

Esta estrategia involucra más trabajo, pero podrá ayudarnos a mejorar el impacto de los costos.

Siguiendo con el ejemplo de migrar una carga de trabajo basada en Máquinas Virtuales desde on-prem a Cloud:

Podríamos implementar Compute Engine Managed Instances en GCP o Azure Scale Sets para agregar escalabilidad y elasticidad a nuestras cargas de trabajo.

Otro ejemplo, sería migrar de un motor de base de datos MySQL corriendo en un Server al servicio de Cloud SQL o Azure Database.

Refactor: move and improve

Con esta estrategia, las cargas de trabajo serán modificadas antes o mientras son migradas a la nube.

Las migraciones de refactorización permiten aprovechar características de la nube, como la escalabilidad y alta disponibilidad. También es posible mejorar la arquitectura para aumentar la portabilidad de la aplicación.

Debemos tener en cuenta que, este tipo de migración toma más tiempo que una migración de rehost, ya que es necesario refactorizar las cargas de trabajo.

Además, la refactorización requiere adquirir nuevas habilidades.

Ejemplo:

Refactorizar Jobs para que ejecuten en Cloud Functions.
Migrar applicación Continerizada de una VM a un PaaS Service como Google Cloud Run o Azure Container Apps.

Re-architect: continue to modernize

Este tipo de migración es comparable con la estrategia de Refactor, pero agregamos un poco de complejidad. En este caso se hace un re-architect para cambiar como funciona el codigo. Esto permite que el codigo esté optimizado para ser ejecutado en Cloud.

Ejemplo:

Refactorización de una aplicación monolitica para correr en AKS o EKS como Microservicios.

Rebuild: remove and replace

En este caso, decomisamos la aplicación on-premises y la rediseñamos completamente desde 0 en la nube.

Este tipo de migraciones permite la generación de una solución Cloud-Native desde el principio ya que será diseñada e implementada en el contexto de nube.

Estas migraciones de reconstrucción pueden tardar más que las de rehost o refactor. No son adecuadas para aplicaciones listas para usar, ya que requieren reescribir la aplicación. Es importante evaluar el tiempo y esfuerzo adicional para rediseñarla.

Este tipo de migración también exige nuevas habilidades y herramientas para configurar y desplegar la app en el nuevo entorno.

Repurchase

En este caso, es cuando se adquiere un servicio SaaS como ambiente de destino.

Desde el punto de vista de los recursos, una migración de recompra suele ser más sencilla que refactorizar, reconstruir o re-arquitectar. Sin embargo, puede ser más costosa y es posible que no se obtenga el mismo nivel de control granular sobre el entorno en la nube.

Por ejemplo:

Si utilizabas el correo electronico o herramientas de colaboración on-premises, pasar a Microsoft 365 es un Repurchase.

Adoption Frameworks

Cada Cloud tiene un Adoption Framework que permite dar un marco formal a la madures que tiene cada organización para migrar a la nube. Les dejo debajo los Adoption Frameworks de los Big 3:

Prerrequisitos comunes a cualquier migración

Evaluación y Descubrimiento (Assess and Discover).
Planeamiento y construcción.
Casos de Prueba y Prueba Piloto.

Evaluación y Descubrimiento (Assess and Discover)

Basicamente, en esta etapa de la migración vamos a realizar un inventario de todos los recursos a migrar y determinaremos los requerimientos y dependencias de cada uno. Debemos ganar un conocimiento Muy Profundo sobre las cargas de trabajo que vamos a migrar.

Aquí tendremos una gran participación de todos los equipos involucrados: lideres tecnicos, app owners, lideres de negocio, networking, etc…

Es importante para detectar Blockers tempranos y setear espectativas a los Stakeholders.

Algunas de las tareas de esta etapa serán:

Generar un inventario.
Catalogar las aplicaciones y dependencias.
Capacitar a los equipos.
Generar PoC en caso que sea necesario.
Calcular TCO.

Así puede verse un inventario resultante de esta etapa:

A partir de esta información debemos poder generar una categorización en cuanto a criticidad / nivel de dificultad de nuestros Workloads:

Planeamiento y construcción

En esta etapa planificaremos y construiremos los simientos de nuestra migración:

Definiciones del proyecto.
Project planning.
Landing Zones.

Algunas de las tareas que realizaremos en este paso incluyen:

Acordar y Definir plan de acción.
Asignar un Timeline (o cronograma de acción).
Elegir la estrategia de migración.
Elegir la/las tools de migración.
Construir nuestras landing zones (en caso que sea necesario, ya que pueden existir previamente).

En esta etapa, tambien debemos tener en cuenta:

Jerarquía de recursos: Diseñar una estructura de recursos adecuada es crucial para la facturación, la seguridad y la gestión de equipos.

Gestión de identidades y accesos (IAM): Se centra en cómo gestionar el acceso a recursos de Google Cloud mediante usuarios, grupos y cuentas de servicio, asegurando control granular y buenas prácticas de seguridad.

Conectividad y redes: Es importante planificar el diseño de red, la transferencia de datos, y ajustar parámetros como la unidad de transmisión máxima (MTU) para optimizar el rendimiento.

Facturación: Los conceptos de jerarquía de recursos y facturación están relacionados. Es fundamental comprender cómo se facturan los recursos.

Gobernanza: Establecer estrategias de control y gestión es vital para mantener la seguridad, cumplimiento y organización de los recursos en la nube.

Seguridad y Compliance: La gestión y seguridad de los sistemas en requieren una comprensión clara de las responsabilidades y amenazas, además de implementar prácticas de detección y monitoreo proactivo.

Casos de Prueba y Prueba Piloto

Para cada una de las migraciones, es recomendable agregar una etapa de Casos de Prueba y Prueba Piloto una vez configurada la herramienta de migración. Estas fases permitirán asegurar la efectividad del proceso, minimizando riesgos y disrupciones.

Casos de Prueba:
- En esta fase, migraremos equipos, servicios o cargas de trabajo que no sean críticos para la producción o que puedan tolerar una posible interrupción sin afectar al negocio.
- El objetivo es ejecutar el proceso completo de migración, desde la planificación hasta la verificación post-migración, sin generar impactos en operaciones productivas.
- Estas pruebas nos permitirán identificar posibles fallos, optimizar tiempos y ajustar configuraciones en un entorno controlado.
Prueba Piloto:
- Una vez validados los Casos de Prueba, avanzamos hacia la Prueba Piloto, donde se migrará un entorno que afecte a un equipo o servicio de menor criticidad, preferiblemente en ambientes de desarrollo, pruebas o staging.
- La selección de la Prueba Piloto debe centrarse en un entorno que refleje condiciones similares a las productivas, pero cuyo impacto sea mínimo en caso de errores.
- El éxito en esta fase será clave para generar confianza antes de ejecutar migraciones más amplias en producción.

Adicionalmente:

Monitoreo y análisis: Es crucial monitorear cada migración a lo largo del proceso para obtener métricas clave como tiempos de ejecución, errores o impactos en el rendimiento. Esto permitirá ajustar futuros procesos y optimizar tiempos.
Plan de reversión: Asegurarse de contar con un plan de contingencia o reversión para minimizar riesgos ante posibles fallos durante la prueba piloto.
Automatización: Si es posible, automatizar parte del proceso de pruebas para reducir la intervención manual y garantizar consistencia en los resultados.