Planificación de olas

En la planificación de oleadas, un grupo de dependencias es un conjunto de aplicaciones e infraestructuras que tienen dependencias técnicas y no técnicas que no se pueden resolver. Debido a estas dependencias, las aplicaciones y la infraestructura de un grupo de dependencias se deben migrar al mismo tiempo o en una fecha específica. Por ejemplo, es probable que una aplicación que se ejecuta en una máquina virtual y una base de datos que se ejecuta en una máquina virtual independiente, donde hay requisitos de baja latencia o volúmenes de tráfico elevados y consultas complejas, se migren juntas en lugar de utilizar un componente en la nube y el otro de forma local. Del mismo modo, las aplicaciones independientes que interactúan a través de una API con requisitos similares de baja latencia también se migrarán al mismo tiempo.

Las oleadas de migración suelen durar de 4 a 8 semanas y pueden contener uno o más eventos de migración. Los grupos de dependencia se combinan en oleadas para que una oleada pueda contener uno o más grupos de dependencia. La oleada también contiene otras actividades que son necesarias para la migración. Estas incluyen la configuración de la AWS infraestructura (como la zona de aterrizaje, la seguridad y las operaciones), las herramientas de migración y las actividades de migración, como la replicación de datos, la planificación de cortes, las pruebas y el soporte posterior a la migración.

Para medir el éxito y hacer un seguimiento del progreso, las olas deben estar alineadas con los resultados y los impulsores del 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. La planificación de una ola también puede combinar otros factores, como los principios rectores técnicos. Por ejemplo, las olas se pueden definir por entorno (por ejemplo, desarrollo, prueba, producción) o por estrategia de migración (por ejemplo, oleada de realojamiento, oleada de replataforma).

Para crear planes de oleadas 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.

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 calendarios de publicación de las aplicaciones, los plazos de mantenimiento y las fechas comerciales clave, como el procesamiento a finales de mes o al final del trimestre, influirán en el plan de expansión.

Determine si la dependencia es suave 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. Otro ejemplo es un sistema que se puede migrar durante un período de mantenimiento sin que ello afecte a las actividades de mantenimiento.

Una dependencia estricta 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 (por ejemplo, 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 oleada de migración, determine sus grupos de dependencias analizando las dependencias, idealmente a partir de una fuente de datos de gran confianza, como herramientas de descubrimiento especializadas, y combine esta información con los criterios de priorización de las aplicaciones y las circunstancias operativas. Las aplicaciones que ocupen los primeros puestos de la clasificación de prioridades deberían estar orientadas a las oleadas de migración iniciales. Determine la capacidad de la oleada (la cantidad de aplicaciones que puede contener una oleada) en función de la disponibilidad de los recursos, la tolerancia al riesgo, las limitaciones empresariales y técnicas, la experiencia y las habilidades. Considere la posibilidad de trabajar con socios especializados en servicios AWS profesionales o en materia de AWS migración, que pueden proporcionarle especialistas que lo ayuden durante todo el proceso.

Los criterios de priorización son una indicación inicial del orden en el que trasladará sus aplicaciones a la nube. Sin embargo, los grupos de dependencias serán los determinantes reales de las aplicaciones que se trasladarán en un momento dado. Esto se debe a que las aplicaciones que se clasifican como de alta prioridad pueden depender en gran medida de las aplicaciones que se encuentran en la mitad o en la parte inferior de la clasificación.

La estrategia de migración también influirá en la composición de una ola. Por ejemplo, una aplicación de alta prioridad que requiere una estrategia de refactorización que puede requerir varias semanas o meses de análisis, diseño, pruebas y preparativos probablemente pase a una fase posterior.

Crear un plan de oleada

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.

Gestionar el cambio

La cartera de aplicaciones y la infraestructura asociada cambiarán durante el ciclo de vida de los programas de migración. Los programas de migración de larga duración coexisten con la evolución y los cambios 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á.