Planificación de oleadas

En esencia, un plan de oleaje es un cronograma de migración y es similar a otras actividades de planificación de proyectos. Le recomendamos que utilice las oleadas de migración como medio para crear grupos gestionables, reducir el riesgo y organizar las actividades en torno a esos grupos.

Para crear planes de migración eficaces y fiables, debe obtener una visión completa de la cartera de aplicaciones, la infraestructura asociada (computación, almacenamiento, redes), el mapeo de dependencias y la estrategia de migración.

Además de las aplicaciones empresariales, que son una forma de agrupar un conjunto de componentes de software e infraestructura, puede utilizar otros niveles de grupo. Una ola es el nivel de grupo más alto. Dentro de una ola, puede crear grupos de dependencias. Este tipo de subgrupo puede contener más de una aplicación. Por ejemplo, dos o más aplicaciones que deben migrarse al mismo tiempo debido a dependencias técnicas, como la baja latencia, u otros factores. Luego, ese grupo de dependencias se administra como un todo. Se pueden asignar varios grupos de dependencias a una ola. A continuación, puede asignar una fecha de migración a toda la oleada o a los grupos de dependencias individuales de una oleada. La fecha de migración es la fecha y la hora en que ese grupo se detendrá en la ubicación actual y se activará en ella AWS.

Las oleadas migratorias tienen múltiples actividades. Le recomendamos que organice la ola en fases y establezca una duración prevista para cada fase. A modo de ejemplo, se muestran las fases siguientes:

No existe una duración predefinida para una ola de migración y dependerá del nivel de esfuerzo y complejidad. Recomendamos mantener las oleadas de migración en un plazo de 6 a 10 semanas. Los casos en los que se requiere más tiempo, por ejemplo, cuando se reescribe por completo un componente de la aplicación, suelen gestionarse mejor fuera de las oleadas de migración.

Para medir el éxito y hacer un seguimiento del progreso, las oleadas deben estar alineadas con los resultados y los factores que impulsan el negocio. Esto también influirá en la duración de la onda y en los grupos de dependencia que contiene una ola. La finalización de una oleada debe reflejar un logro mensurable.

Hay varias formas de organizar las oleadas migratorias. En la siguiente tabla se describen las opciones de organización de oleadas más comunes. Por lo general, se combinan.

La sección sobre el establecimiento de una base para la cartera de aplicaciones describió cuatro categorías de dependencias técnicas. Estas dependencias contribuyen a la creación de oleadas de migración y a la definición de grupos de dependencia. Los grupos de dependencia vendrán determinados por la criticidad de la dependencia. Además, se deben considerar las dependencias no técnicas. Por ejemplo, los cronogramas de publicación de las aplicaciones, los plazos de mantenimiento y las fechas comerciales clave (como el procesamiento de fin de mes o fin de trimestre) pueden influir en el plan de oleada.

Determine si la dependencia es débil o dura. Una dependencia flexible es una relación entre dos o más activos, o entre un activo y una restricción, que no depende de la ubicación de los componentes. Por ejemplo, dos sistemas que funcionan en la misma red local (o en la misma infraestructura) se pueden separar moviendo uno de esos sistemas a la nube y el otro permanece en las instalaciones. Una dependencia fuerte es una relación entre dos o más activos, o entre un activo y una restricción, que depende de la ubicación. Por ejemplo, dos sistemas que funcionan en la misma red local y que dependen en gran medida de la baja latencia para la comunicación entre el servidor de aplicaciones y el servidor de bases de datos tienen una fuerte dependencia. Mover solo uno de estos sistemas a la nube provocaría problemas de funcionalidad o rendimiento que no se pueden resolver. Del mismo modo, motivos no técnicos, como la disponibilidad de recursos (como el equipo que realiza la migración) o las limitaciones operativas (como los períodos de mantenimiento en los que solo se pueden migrar dos sistemas en un período de tiempo determinado), podrían crear una fuerte dependencia para estos activos.

Para crear un plan de migración gradual, determine sus grupos de dependencias analizando las dependencias, idealmente a partir de una fuente de datos muy fiable, como las herramientas de detección especializadas. Combine esta información con los criterios de priorización de las aplicaciones y las circunstancias operativas.

Determinar las dependencias técnicas es un desafío. Se requieren varios puntos de datos y ninguna fuente de datos los contiene todos. Por ejemplo, aunque se puede obtener información de comunicación entre procesos a partir de las herramientas de detección, es difícil clasificarlas en dependencias físicas y físicas. La tolerancia a la latencia también es difícil de determinar únicamente a partir de los datos de la red.

Las siguientes técnicas pueden ayudarle a gestionar la ambigüedad que supone determinar las dependencias reales:

AWS Transform puede ayudarlo a analizar las dependencias y planificar las oleadas.

Crear un plan de oleaje

Un requisito previo para migrar una oleada de aplicaciones son los datos de la cartera de aplicaciones y la evaluación detallada de las aplicaciones del grupo de aplicaciones que se migrarán en la oleada. La evaluación detallada debe incluir la lista de aplicaciones de la oleada, los detalles de la infraestructura asociada, un diseño objetivo y una estrategia de migración para cada aplicación. 

Establecer la propiedad y el gobierno de la oleada es clave para gestionar y hacer un seguimiento del trabajo de la oleada, las dependencias de los programas, la gestión de los cambios, los problemas y los riesgos. Asegúrese de que exista un marco de gobierno para gestionar el plan.

Para delinear el plan de oleaje, comience con una construcción de oleaje predeterminada. ¿Qué ocurre dentro de una ola? Una vez definida la entrada inicial, la onda puede comenzar. Por lo general, las actividades serán: 

La duración de cada una de estas actividades dependerá de la complejidad del alcance, la capacidad de la ola, las personas involucradas y sus circunstancias únicas. Siempre que sea posible, es preferible utilizar oleadas más pequeñas, ya que reducirán el impacto de cualquier retraso o bloqueo de la migración. Determina, con tus equipos, cuál será la duración predeterminada de una oleada.

A continuación, proceda a analizar las fechas para crear una estructura inicial de alto nivel de oleadas vacías (sin ninguna aplicación asignada todavía). Tenga en cuenta las siguientes preguntas:

Con estas consideraciones, trace las olas en un plan. Para acelerar el proceso de migración, recomendamos superponer las oleadas siempre que sea posible. La clave de la superposición de ondas es definir y considerar lo que ocurre dentro de una ola. Por lo general, las actividades de despliegue, la validación de la infraestructura de destino y la sincronización de datos se llevan a cabo durante la primera mitad de una oleada. La segunda mitad se centrará en la migración, las pruebas y el traspaso operativo propiamente dichos. Esto significa que participan diferentes equipos en cada mitad del proceso y que se puede obtener cierta eficiencia. Por ejemplo, tan pronto como el equipo implicado en la preparación de la infraestructura objetivo haya completado su trabajo, podrá empezar a trabajar en los requisitos de la próxima oleada. En general, es preferible que la mayoría de las olas tengan una longitud y una estructura similares para facilitar un enfoque de migración similar al de una fábrica. Sin embargo, durante el proceso de planificación de las olas, el tamaño de una ola determinada puede ampliarse para cumplir con las dependencias o los requisitos operativos. 

A continuación, en función de los grupos de dependencias que se hayan identificado, determine el tamaño máximo de una ola en términos del número de grupos de dependencias que puede contener. El tamaño de la ola suele estar determinado por el apetito por el riesgo (por ejemplo, cuánto cambio paralelo se puede tolerar) y la disponibilidad de recursos (por ejemplo, cuánto cambio paralelo se puede realizar con los recursos, las habilidades y el presupuesto disponibles). Sin embargo, durante la planificación temprana, no se deje limitar por las necesidades y la disponibilidad de los recursos. Las ondas que contienen más de un grupo de dependencias se pueden descomponer en ondas más pequeñas en futuras iteraciones.

Una vez confirmados los grupos de dependencias de una oleada determinada, revise los requisitos de recursos para migrar la oleada. Considere ajustar el tamaño de la onda (la cantidad de grupos de dependencias que contiene) en función de las necesidades de recursos. Esto podría provocar olas más pequeñas o más grandes. Repite el plan de olas según sea necesario hasta que se hayan definido todas las olas. Considere la posibilidad de trabajar con socios de servicios AWS profesionales o con competencias en AWS migración, que pueden proporcionarle especialistas que lo ayuden durante todo el proceso.

Gestionar el cambio

La cartera de aplicaciones y la infraestructura asociada cambiarán durante el ciclo de vida de los programas de migración. Long-running los programas de migración coexisten con la evolución y el cambio normales de la empresa. Las aplicaciones siguen evolucionando a medida que esperan ser migradas. Se agregan o quitan servidores y la nueva infraestructura se implementa en las instalaciones. Se espera que el alcance de una oleada o grupo de dependencias requiera cambios. Los cambios son necesarios, especialmente cuando, cuando se acerca la fecha de migración, se identifica una dependencia previamente desconocida o se incluye un nuevo servidor en el inventario. A veces, esto puede ocurrir durante la propia migración.

Los cambios de alcance afectan a los grupos y oleadas de dependencias. Para gestionar los cambios y minimizar el impacto, es importante establecer un mecanismo de control del alcance. Un mecanismo de control del cambio de ámbito requiere la definición de una única fuente de información veraz para el ámbito. Podría ser una herramienta para administrar el ámbito o un archivo, hoja de cálculo o base de datos .csv, tal como se define en la gobernanza del programa de migración. Debe identificar los cambios, analizar el impacto y comunicarlos a las partes interesadas pertinentes para que puedan tomar medidas. Como resultado, el plan de oleaje se iterará.