Detección del entorno de Windows
Con las tecnologías disponibles en la actualidad, por ejemplo AWS Application Migration Service, trasladar Windows Server, Linux y otros sistemas operativos basados en x86 y sus cargas de trabajo a AWS es bastante sencillo. Sin embargo, lograr que esas cargas de trabajo funcionen de manera correcta y hacerlo a escala presenta un conjunto de desafíos diversos. El objetivo de esta sección es identificar las consideraciones que pueden permitirle migrar las cargas de trabajo de Microsoft de manera rápida, segura y fluida.
Evaluación
Si bien puede “forzar” migraciones más pequeñas (como las que implican 100 servidores) con un mínimo de planificación y automatización, no puede mover 500 o más servidores con esta metodología. Las consideraciones siguientes son las principales que contribuyen a que una migración a gran escala sea correcta. Puede utilizar la evaluación del nivel de preparación para la migración (MRA) para identificar las áreas de consideración en las que quieren centrarse.
Arquitectura empresarial
Cuanta más deuda tecnológica haya en el entorno, más difícil será migrar. Las organizaciones que cuentan con programas de arquitectura empresarial en buen estado se esfuerzan por limitar su entorno a las versiones actuales y recientes de software y sistemas (a menudo denominadas versiones N y N -1 de las versiones principales). Esto no solo reduce la cantidad de escenarios que hay que tener en cuenta, sino que también aprovecha los avances de las versiones más recientes. Por ejemplo, es cada vez más difícil automatizar Windows Server 2012, Windows Server 2008 y las versiones anteriores de Windows Server en el entorno de Windows Server que las versiones más actuales. También es más difícil conceder licencias de las versiones antiguas y no compatibles.
Administración de la estandarización y la configuración
La estandarización del entorno es otro factor que se debe tener en cuenta. Se considera que las organizaciones que tienen entornos creados y mantenidos a mano se parecen más a las mascotas. Cada sistema es único y hay muchas más combinaciones de configuración posibles que si se hubieran creado con imágenes estandarizadas, infraestructura como código (IaC) o procesos de integración continua y entrega continua (CI/CD).
Por ejemplo, se recomienda volver a crear un servidor web típico mediante IaC o CI/CD durante la migración, en lugar de migrar de manera manual el servidor individual. También se recomienda almacenar todos los datos persistentes en un almacén de datos, como una base de datos, un recurso compartido de archivos o un repositorio. Si los sistemas no se vuelven a crear con IaC o CI/CD, al menos deberían utilizar herramientas de administración de la configuración (como Puppet, Chef o Ansible) para estandarizar los servidores de los que disponen.
Datos buenos
Los datos buenos también son un factor clave para que las migraciones sean correctas. Los datos precisos sobre los servidores actuales y sus metadatos son esenciales para la automatización y la planificación. La falta de datos buenos aumenta la dificultad a la hora de planificar una migración. Algunos ejemplos de datos buenos son un inventario preciso de los servidores, las aplicaciones de los servidores, el software de los servidores con sus versiones, la cantidad de CPU, la cantidad de memoria y la cantidad de discos. Le recomendamos capturar todos los datos que necesiten los planificadores de oleadas para la planificación o los datos que vayan a utilizar como parte de la automatización del proceso de migración.
Automatización
La automatización es esencial para las migraciones a escala. Entre algunos ejemplos de automatización se incluyen la instalación del agente, la actualización de las versiones de software de las utilidades necesarias para la automatización, como .NET o PowerShell, la carga o actualización del software para AWS como AWS Systems Manager Agent (SSM Agent), el agente de Amazon CloudWatch u otro software de copia de seguridad o administración necesario para ejecutarse en AWS.
Planificación detallada
Desarrollar y administrar un plan detallado también es esencial para las migraciones a escala. Debe contar con un plan bien definido para migrar 50 servidores a la semana durante varias semanas. Un plan eficaz incluye lo siguiente:
-
Utilice la planificación de oleadas para organizar los servidores en oleadas según las dependencias y prioridades.
-
Utilice la planificación semanal (antes de la transición) para comunicarse con los equipos de aplicaciones e identificar la red, el DNS, el firewall y otros detalles que deben abordarse durante la transición.
-
Utilice una planificación detallada, hora a hora (en torno a la transición real) para describir el periodo de mantenimiento de la transición.
-
Utilice los criterios de aprobación o rechazo para describir en qué circunstancias se considerará que se hizo la transición de una aplicación a AWS o se debe hacer una conmutación por recuperación a la ubicación de origen.
-
Utilice las actividades de limpieza como actividades de seguimiento que se deben completar. Estas actividades se pueden hacer fuera del periodo de mantenimiento de la transición o una vez finalizada la hiperatención. Entre las actividades de limpieza se incluyen la verificación de las copias de seguridad y varios agentes, la eliminación del agente de Application Migration Service de un servidor o la eliminación del servidor de origen y los recursos asociados.
Movilización
Durante la fase de movilización, es importante detectar el mayor número posible de complejidades y variaciones de la organización para poder tenerlas en cuenta a la hora de planificar la migración. Lo ideal es que pueda evitar tener que lidiar con este tipo de complejidades y variaciones durante el periodo de mantenimiento de la transición y evitar posibles conmutaciones por recuperación.
Los desafíos de las migraciones a escala
Los errores de migración se producen cuando se hizo la transición de una o varias aplicaciones a sus entornos nuevos y no se pueden cumplir los requisitos funcionales o de rendimiento durante el periodo de mantenimiento de la migración. Esto hace que la aplicación o las aplicaciones hagan una conmutación por recuperación a su ubicación original. Además, todas las demás aplicaciones que dependen de esa aplicación o aplicaciones también deben hacer una conmutación por recuperación. Las migraciones con errores suelen afectar no solo a la ola actual sino también a las futuras, ya que las aplicaciones se deben volver a programar.
Dependencias sensibles a la latencia
Uno de los motivos principales de las migraciones con errores son las dependencias sensibles a la latencia. Si no se identifican las dependencias sensibles a la latencia, se pueden producir problemas de rendimiento que provocan tiempos de respuesta o de transacción inaceptables.
Por ejemplo, una aplicación suele trasladar sus servidores de bases de datos y aplicaciones a la nube al mismo tiempo, ya que se comunican entre sí con frecuencia y necesitan el tiempo de respuesta inferior a un milisegundo del que disponen cuando ambas se encuentran en el mismo centro de datos. Es probable que mover solo la base de datos a la nube genere muchos segundos de latencia en esas transacciones, lo que tendrá un impacto significativo en el rendimiento de la aplicación. Esto también se aplica a las aplicaciones que dependen en gran medida unas de otras y que deben estar en el mismo centro de datos para funcionar de manera adecuada.
Por lo tanto, comprender y abordar las dependencias de las aplicaciones es de suma importancia al planificar las migraciones. Las aplicaciones y los servicios que dependen unos de otros se deben identificar para poder migrarlos juntos.
Servicios compartidos de TI
Una vez que una carga de trabajo está en la nube, necesita una variedad de servicios para funcionar y mantenerse de manera adecuada y segura. Esto incluye una zona de aterrizaje, un perímetro de red y seguridad, autenticación, revisiones, escáneres de seguridad, herramientas de administración de servicios de TI, copias de seguridad, hosts bastiones y otros recursos. Sin estos servicios, es posible que las cargas de trabajo no funcionen de manera adecuada y se vean obligadas hacer una conmutación por recuperación a su ubicación original.
Actualizaciones de configuración
En la mayoría de los casos, debe hacer varios cambios de configuración para que una carga de trabajo funcione de manera adecuada después de trasladarla a la nube. Estos cambios de configuración suelen estar asociados a las dependencias siguientes de la carga de trabajo:
-
Reglas de firewall
-
Listas de permitidos
-
Registros de DNS
-
Cadenas de conexión
Si no hace las actualizaciones de configuración adecuadas, es posible que la carga de trabajo, sus usuarios y sus sistemas dependientes no se comuniquen entre sí. Podría ser posible resolver estos problemas en el periodo de interrupción, pero los cambios en este momento pueden tardar mucho tiempo o requerir registros de cambios que no se pueden gestionar a tiempo.
Pruebas funcionales de las aplicaciones
Otro desafío para las migraciones a escala es la necesidad de hacer pruebas funcionales de las aplicaciones. Esto es muy importante, ya que numerosas organizaciones confían en los equipos de aplicaciones para identificar las dependencias sensibles a la latencia, los servicios compartidos de TI o las actualizaciones de configuración necesarias. Lo ideal es que un equipo de aplicaciones proporcione un plan de pruebas escrito o automatizado que pueda ejecutar durante el periodo de mantenimiento temporal de la transición para validar que la aplicación es totalmente funcional y tiene un rendimiento aceptable. Para reducir al mínimo el periodo de mantenimiento de la transición, la prueba se debe poder completar en 30 minutos.
Herramientas para detectar la dependencia de las aplicaciones
Determinar las dependencias entre las aplicaciones es fundamental para que las migraciones sean correctas, para detectar las dependencias sensibles a la latencia y para detectar los elementos de configuración de la conectividad. Existen varias herramientas disponibles en el marketplace para detectar las dependencias, como AWS Application Discovery Service
Al elegir una herramienta para la detección de dependencias de aplicaciones, tenga en cuenta lo siguiente:
-
Duración: le recomendamos ejecutar las herramientas de detección durante el tiempo suficiente para capturar los eventos específicos de la aplicación, como los picos conocidos, los eventos de fin de mes y otros eventos. El mínimo recomendado es 30 días.
-
Activo (basado en agentes): las herramientas de detección de dependencias activas suelen estar incrustadas en el kernel del sistema operativo y capturan todas las transacciones. Sin embargo, este suele ser el método más caro y tardado.
-
Pasivo (sin agente): las herramientas pasivas de detección de dependencias son mucho más baratas y rápidas de implementar, pero corren el riesgo de perder algunas conexiones que se utilizan en menor medida.
-
Conocimientos institucionales: si bien las herramientas de detección de aplicaciones proporcionan información más detallada y precisa, la mayoría de las organizaciones confían en sus equipos de aplicaciones y en sus conocimientos institucionales para detectar las dependencias entre las aplicaciones. Los equipos de aplicaciones suelen estar bien informados sobre las dependencias sensibles a la latencia, pero común que pasen por alto algunos detalles, como los valores de configuración de la conectividad, las reglas del firewall o los requisitos de una lista de admitidos por parte de un socio. Puede utilizar los conocimientos institucionales para mejorar la detección de las dependencias de las aplicaciones, pero le recomendamos que también considere y mitigue los riesgos que esto implica. Por ejemplo, existe el riesgo de que se pierdan elementos de configuración de conectividad o dependencias sensibles a la latencia si solo depende de los conocimientos de los equipos de aplicaciones. Esto puede provocar interrupciones o migraciones erróneas. Para mitigar este riesgo, le recomendamos que lleve a cabo pruebas funcionales de aplicaciones detalladas.
