Migración Segura a la Nube: 8 Pasos Esenciales para una Transición Fluida

Elige un Arquitecto de Migración de Referencia(s)

La migración a la nube involucra numerosas decisiones técnicas y planes, así que debes designar un solo especialista o un equipo de expertos para liderar el esfuerzo. Ya sea que vayas con uno o más miembros del personal, el rol de un arquitecto de migración es:

• Evaluar servicios para ver si encajan mejor en hosting on-premise o cloud.
• Crear una línea de tiempo para la migración y la hoja de ruta cloud.
• Diseñar estrategias óptimas para mover datos y apps.
• Identificar y supervisar refactoring de apps necesario.
• Determinar prioridades de migración.
• Definir la toolchain requerida.

El arquitecto dedicado también debe proporcionar una imagen completa de tu TI. Este proceso implica responder las siguientes preguntas:

• ¿Qué apps tienes, y quién las usa (y con qué frecuencia)?
• ¿Qué tan críticas para el negocio son las apps que buscas migrar?
• ¿Qué recursos consumen los programas, y dependen de otras apps?
• ¿Qué SLAs, medidas de continuidad de negocio y cumplimiento están actualmente en vigor?
• ¿Hay problemas de rendimiento afectando operaciones actuales?

Dependiendo del análisis, el arquitecto de migración debería evaluar si tu fuerza laboral actual tiene el know-how necesario para:

• Realizar la migración.
• Operar en el entorno cloud.

Nunca inicies la transición a la nube a menos que estés seguro de que tu equipo puede prosperar en el nuevo entorno.

El equipo dedicado de migración también debería determinar el coste total de propiedad (TCO) para ilustrar el ROI de la migración cloud. La evaluación TCO para migración cloud incluye factores como:

• El coste total de la migración.
• Costes cloud post-migración (principalmente precio de ancho de banda y redes).
• Coste de formación del personal.
• Mantenimiento regular post-migración.
• Coste de potencial tiempo de inactividad.
• Costes de espacio, refrigeración y electricidad (para nube privada on-premise).

Establece Objetivos y KPIs de Migración

El siguiente paso es establecer el objetivo(s) principal(es) de la migración. Algunos objetivos comunes de alto nivel son:

• Modernizar una app legacy.
• Acelerar un servicio particular.
• Mejorar capacidades operacionales.
• Aumentar resiliencia del sistema.
• Mejorar experiencia de usuario.
• Lograr mejor escalabilidad de servicio.
• Reducir costes de operación.
• Mejorar seguridad de datos.

Además del objetivo general, el equipo debería definir Indicadores Clave de Rendimiento (KPIs) de migración cloud. Estas métricas medirán cómo una app o servicio migrado rinde contra expectativas. No hay límite al número de KPIs que tu equipo puede rastrear, pero todas las métricas caen bajo una de dos categorías:

• KPIs que sigues durante el proceso de migración.
• KPIs post-migración.

Aquí están los KPIs más comunes que un negocio puede rastrear durante el proceso de migración:

• Duración de la migración (tanto en conjunto como por app).
• Disponibilidad de servicios críticos.
• Longitud de tiempo de inactividad de servicios y centros de datos.
• Degradación de servicio debido a tiempo de inactividad.
• Número de tickets de servicio generados.
• Coste de migración.

Veamos algunos KPIs post-migración que tu equipo puede rastrear:

• KPIs de infraestructura (uso CPU, huella de memoria de servicio, rendimiento de disco, balanceo de carga, latencia, throughput de red, etc.).
• Métricas de rendimiento de app (tasas de error, número de timeouts, tiempo de respuesta promedio (ART), tiempo de respuesta pico (PRT), uptime, disponibilidad, etc.).
• KPIs de experiencia de usuario (número de picos de peticiones, errores de código de estado HTTP, excepciones lanzadas y loggeadas, lag, tiempos de respuesta, etc.).
• Métricas de impacto empresarial (duración del proceso de checkout, tasas de suscripción y cancelación, tasas de engagement, etc.).
• KPIs de costes (facturación mensual, costes de personal, herramientas de terceros, costes de consultoría, etc.).

Necesitas establecer un valor baseline para cada KPI antes de decidir qué rastrear. El baselining es el proceso de medir el estado actual (pre-migración) de una app y servicio. Estos KPIs te permiten determinar si el rendimiento post-migración es aceptable o no.

Realiza Evaluación de Datos y Apps

La evaluación de datos es un paso vital de esta checklist de migración cloud ya que mover datos es típicamente la parte más complicada de adoptar la nube. Evaluar cuidadosamente datos permite a tu equipo evaluar:

• Niveles de riesgo de datos.
• Volumen y tipo de datos que planeas migrar.
• Resiliencia general de datos.
• Requisitos legales de privacidad de datos (si los hay).
• Amenazas más significativas a la integridad de datos.
• Potenciales escenarios de brecha o fuga de datos post-migración.

Dónde residen tus datos puede impactar el rendimiento de una app y servicio. Mover datos a la nube cuando los métodos de acceso a datos aún operan on-premise puede afectar significativamente el rendimiento. Lo mismo ocurre si la base de datos sigue on-premise pero el servicio que la accede reside en la nube.

Además de evaluar datos, tus apps on-premise deberían recibir el mismo trato. Antes de migrar, el equipo debería crear un inventario de todas las apps on-premise y sus servidores. También deberías evaluar cualquier máquina virtual actual y contabilizar dependencias de apps potenciales.

Como resultado, puedes determinar qué apps requieren refactoring antes de moverlas a la nube. El equipo también puede empezar a priorizar qué apps migrar primero.

Evalúa Opciones de Migración Cloud

El siguiente paso de la checklist de migración cloud es evaluar qué apps requieren qué tipo de integración con la nube. Tienes dos opciones:

• Integración cloud superficial (a.k.a. lift-and-shift): Cuando haces lift and shift de una app, haces pocos o ningún cambio al código y configuras la app en la nube más o menos en su forma actual. Migrar una app sin cambios se conoce como rehosting; hacer alteraciones menores al mover una app a la nube es refactoring.
• Integración cloud profunda: A diferencia de su contraparte superficial, la integración cloud profunda requiere que modifiques la app para aprovechar características cloud. Los cambios pueden variar desde ajustes relativamente simples (como configurar auto-scaling y balanceo de carga dinámico) hasta actualizaciones avanzadas (como habilitar computación serverless) que hacen la app una solución cloud-native.

La integración cloud superficial es una opción significativamente más rápida que refactorizar porciones mayores de una app. En general, apps críticas para la misión típicamente valen el esfuerzo de integraciones profundas. Apps y servicios menos vitales pueden arreglárselas con el enfoque superficial ya que puedes refactorizarlas con el tiempo después de migrar a la nube.

Las empresas también a menudo deciden retirar o retener apps al evaluar qué servicio requiere qué tipo de integración:

• Retirar es el proceso de identificar una app u obsoleta que no tiene valor si se sube a la nube.
• Retener es la decisión de mantener una app on-premise, típicamente por una preocupación de seguridad o cumplimiento.

Elige el Modelo de Despliegue Cloud Adecuado

Elegir un modelo de despliegue cloud adecuado es vital para una migración cloud exitosa. Diferentes modelos encajan diferentes casos de uso, y las cinco opciones que puedes elegir son:

• Nube pública (entorno multi-tenant que proporciona acceso a recursos de cómputo a través de Internet o conexión directa dedicada).
• Nube privada (sistema single-tenant en el que una empresa ejecuta recursos cloud dentro de su propio centro de datos).
• Nube híbrida (mezcla de sistemas on-premise, nubes públicas y privadas en la que cargas de trabajo se mueven entre entornos vía automatización y orquestación).
• Multi-cloud (mezcla de dos o más entornos IaaS de nube pública).
• Nube comunitaria (infraestructura compartida entre varias empresas con necesidades o preocupaciones compartidas).

Qué modelo de despliegue debes usar depende principalmente de las necesidades y objetivos únicos de tu negocio. Aquí hay algunos indicadores:

• La nube pública proporciona un entorno escalable con modelo pay-per-usage. Aunque altamente escalable, la nube pública puede no ser ideal para cargas sensibles.
• Una nube privada es perfecta para una empresa con presupuesto para ejecutar un entorno cloud on-premise personalizado para sus cargas críticas.
• Una nube híbrida te permite ejecutar cargas sensibles on-premise mientras también aprovechas escalabilidad de nube pública durante picos de demanda.
• Aunque altamente beneficioso cuando se hace bien, hay algunos desafíos de nube híbrida que necesitas conocer antes de diseñar una arquitectura híbrida.
• Multi-cloud es una excelente opción para firms preocupadas por vendor lock-in o empresas que buscan mezclar y combinar servicios de múltiples proveedores.

Elige un Proveedor de Servicios Cloud

A menos que optaras por configurar una nube privada on-premise, el siguiente elemento en la checklist de migración cloud debería ser encontrar un proveedor cloud. Aunque la mayoría de vendedores ofrecen servicios similares, no todos son iguales. Algunas consideraciones clave al elegir un proveedor cloud son:

• Precios.
• Selección de servicios.
• Disponibilidad en regiones específicas.
• Garantías de uptime.
• Familiaridad de tu equipo interno con la pila tecnológica del proveedor.
• Requisitos de cumplimiento específicos de la industria (ej. mantener datos de usuarios en ubicación de origen según CCPA o GDPR).
• Soporte post-migración y servicios TI gestionados.

Recuerda que los proveedores de servicios más populares no siempre son el mejor encaje. Vendedores prominentes apuntan a cubrir un amplio set de necesidades, así que no siempre encajan bien con una empresa en un vertical específico.

Por ejemplo, una empresa que opera en salud podría estar mejor asociándose con un proveedor nicho que entienda y soporte mejor el cumplimiento con HIPAA.

Realiza Refactoring Necesario

Una vez sabes qué despliegue cloud necesitas y con quién asociarte, tu equipo debería empezar a hacer los cambios necesarios a apps y servicios antes de migrarlos a la nube.

El objetivo es hacer que el software funcione tan efectiva y eficientemente en la nube como sea posible. Por ejemplo, tu equipo puede refactorizar una app para:

• Trabajar con un número variable de instancias en ejecución para permitir escalado casi instantáneo.
• Aprovechar capacidades cloud dinámicas (como la habilidad de asignar y desasignar recursos según necesidades actuales).
• Crear una arquitectura más orientada a servicios para mover rápidamente servicios individuales a la nube (tanto esta vez como en el futuro).

Ahora también es el momento correcto para repensar gobernanza y seguridad. Probablemente necesitarás ajustar tu estrategia de gobernanza para depender menos de seguridad y control internos, y más de servicios cloud del proveedor. En términos de seguridad cloud, necesitas:

• Evaluar si la migración puede resultar en nuevas vulnerabilidades.
• Entender cómo tu equipo interno trabajará con el proveedor para mantener activos cloud seguros.
• Ajustar (y potencialmente mejorar) tus medidas y prácticas de seguridad actuales.
• Decidir si puedes beneficiarte de herramientas de seguridad adicionales que el proveedor ofrece.
• Configurar mecanismos de failover y recuperación ante desastres.

Migra Metódicamente y Cambia Tráfico desde Operaciones On-Prem

Aunque puedes migrar todo a la nube de una vez, este enfoque puede ser desafiante y arriesgado. En su lugar, deberías migrar apps y servicios uno por uno, empezando con apps menos críticas y avanzando lentamente hacia las cruciales.

Así es como debería verse este enfoque de migración:

• Prioriza apps que tu equipo puede mover con la menor cantidad de riesgo a operaciones. Buenas opciones son apps que requieren solo rehosting o usan recursos mínimos (como almacenamiento o cómputo bajos).
• Luego, empieza a mover apps que tienen alto valor para tu negocio pero presentan riesgo relativamente bajo durante migración.
• Finalmente, deja las cargas críticas y disruptivas para las etapas finales de migración. Nunca empieces a mover estas apps a menos que las de pasos previos estén funcionando óptimamente.
• Usa una prueba manual o automatizada (o ambas) para verificar si la migración fue exitosa o no.

Dependiendo de la arquitectura de tus apps y datastores, puedes cambiar tráfico desde la solución on-premise a la nube de dos formas:

• Todo de una vez: El equipo cambia todo el tráfico on-premise tan pronto como la app empieza a correr en la nube.
• Poco a poco: Mueves unos pocos clientes al nuevo entorno una vez que el equipo configura la app cloud-based. Si todo funciona como se espera, continúas cambiando clientes a la nube con el tiempo hasta que todos los usuarios finales dependan de la nueva app.

Usa Nuestra Checklist de Migración Cloud para Migrar con Confianza

Aunque moverse a la nube es a menudo una decisión obvia, muchos negocios luchan o tienen éxito limitado al mover apps a la nube. Apegarse a la checklist de migración cloud arriba asegura que evitas todos los obstáculos comunes, así que puedes empezar a planificar tu adopción cloud sin miedo a errores costosos.