Diseño de la arquitectura de cargas de trabajo antes de la migración

En este artículo se describen el proceso y las consideraciones para diseñar el estado migrado previsto de una carga de trabajo en la nube. En el artículo se revisan las actividades que forman parte de la definición de la arquitectura de una carga de trabajo dentro de una iteración.

En el artículo sobre la racionalización incremental se indica que algunas hipótesis de arquitectura forman parte de cualquier transformación empresarial que implique una migración. En este artículo se aclaran las hipótesis habituales. Asimismo, se apuntan algunos obstáculos que se pueden evitar y se identifican oportunidades para acelerar el valor empresarial al desafiar esas hipótesis de arquitectura. Este modelo incremental para diseñar la arquitectura ayuda a los equipos a moverse más rápido y obtener resultados empresariales antes.

Diseño de arquitectura base en hipótesis comunes

Las suposiciones siguientes son típicas para cualquier esfuerzo de migración:

• Imagínese que tiene una carga de trabajo de infraestructura como servicio (IaaS). La migración de cargas de trabajo implica principalmente el traslado de servidores de un centro de datos físico a un centro de datos en la nube mediante una migración de IaaS. Este proceso normalmente requiere un mínimo de desarrollo o reconfiguración. Este enfoque se conoce como migración mediante lift-and-shift.
• Mantenga la arquitectura coherente. Los cambios en la arquitectura central durante una migración aumentan considerablemente la complejidad. La depuración de un sistema modificado en una plataforma nueva presenta muchas variables que pueden ser difíciles de aislar. Las cargas de trabajo se deben someter solo a cambios menores durante la migración, y cualquier cambio se debe probar minuciosamente.
• Planee cambiar el tamaño de los recursos. Suponga que algunos recursos en el entorno local usan completamente cualquier recurso. Antes o durante el transcurso de la migración, se cambia el tamaño de los recursos para ajustarse mejor a los requisitos de uso reales. Las herramientas como Azure Migrate y Modernize proporcionan un ajuste de tamaño basado en el uso real.
• Identifique los requisitos de continuidad empresarial y recuperación ante desastres (BCDR). Si tiene un acuerdo de nivel de servicio (SLA) acordado para la carga de trabajo ya negociado con la empresa, siga usándolo después de la migración a Azure. Si aún no se ha establecido un acuerdo de nivel de servicio, defina uno antes de diseñar la carga de trabajo en la nube para asegurarse de diseñarla correctamente.
• Planee el tiempo de inactividad de la migración. Al igual que el incumplimiento de los requisitos del acuerdo de nivel de servicio, el tiempo de inactividad que se produce cuando promueve una carga de trabajo a producción puede tener un efecto adverso en la empresa. A veces, las soluciones que deben realizar la transición con un tiempo de inactividad mínimo necesitan cambios de arquitectura. Antes de planear un lanzamiento, se supone que se estableció una descripción general de los requisitos de tiempo de inactividad.
• Defina patrones de tráfico de usuarios y aplicaciones. Las soluciones existentes pueden depender de los patrones y las soluciones de distribución de red existentes. Identifique los recursos que necesita para admitir el uso actual de la red.
• Planee para evitar conflictos de red. Al consolidar los centros de datos en un solo proveedor de nube, es probable que cree conflictos en el Sistema de nombres de dominio (DNS) u otras estructuras de red. Durante la migración, es importante diseñar para evitar estos conflictos y las interrupciones en los sistemas de producción hospedados en la nube.
• Planee para las tablas de enrutamiento. Asegúrese de que el proyecto incluya un plan para modificar las tablas de enrutamiento si consolida redes o centros de datos. Considere los requisitos de distribución entre centros de datos.

Arquitectura de diseño para una zona de aterrizaje

En la fase de preparación de Cloud Adoption Framework, la organización implementó servicios de plataforma compartida como parte de la adopción de las zonas de aterrizaje de Azure. En Preparación de la zona de aterrizaje para la migración, preparó la zona de aterrizaje para recibir cargas de trabajo migradas.

En función de este planeamiento, puede suponer que se han implementado los siguientes componentes de migración:

• La conectividad híbrida conecta las redes de Azure a las redes en el entorno local.
• Los dispositivos de seguridad de red, como Azure Firewall, controlan la inspección del tráfico fuera de la carga de trabajo.
• Las directivas de Azure para aplicar prácticas de gobernanza como los requisitos de registro, las regiones permitidas, los servicios no permitidos y otros controles están activas.
• Se ha configurado un área de trabajo de registros de Azure Monitor para el registro compartido en Azure Monitor.
• Se han establecido recursos de identidad compartidos para admitir servidores unidos a un dominio u otras necesidades relativas a las identidades.

Si no se establecen estos aspectos básicos de la migración, la organización debe volver inmediatamente a la fase de preparación para satisfacer estas necesidades. Sin estos componentes, es probable que la migración tenga retrasos y contratiempos y tenga menos éxito.

La carga de trabajo que está diseñando tiene asignada una suscripción, idealmente a través de un proceso de venta de suscripciones. La suscripción puede contener varias cargas de trabajo o solo una carga de trabajo en función de cómo la organización haya completado la organización de recursos para las cargas de trabajo. Si migra una carga de trabajo que tiene muchos entornos de aplicación, es posible que incluso tenga varias suscripciones en función de las guía para entornos de aplicación.

Diseño de la arquitectura de red de cargas de trabajo

Planee la implementación de los recursos específicos de la aplicación en una suscripción específica y planee el diseño de una red virtual dedicada para la carga de trabajo. Para obtener más información, consulte la guía para diseñar la arquitectura de red. Debe centrarse especialmente en la segmentación de redes virtuales.

Es probable que la red necesite recursos como equilibradores de carga y otros recursos de entrega de aplicaciones. Puede usar la guía de arquitectura de N niveles para planear estos recursos en Azure.

Diseño de dependencias de carga de trabajo

Las herramientas de evaluación de la migración deben proporcionar una manera de realizar análisis de las dependencias, como el análisis de dependencias en Azure Migrate y Modernize. Esta herramienta le ayuda a identificar las interdependencias entre servidores.

Además de planear la arquitectura de la propia carga de trabajo, es posible que tenga que tener en cuenta las dependencias de carga de trabajo a carga de trabajo. Por ejemplo, algunas cargas de trabajo pueden necesitar comunicación frecuente. Si es así, planear las fases de migración y las dependencias para tener en cuenta este requisito ayuda a que la migración se realice correctamente.

Puede usar las guías del Centro de arquitectura de Azure, como la guía para redes de radio a radio, para diseñar cómo funcionarán las cargas de trabajo interconectadas después de la migración.

Preparación para la adopción de la informática confidencial

Un subconjunto de las cargas de trabajo con requisitos de soberanía podría dar lugar al uso de la informática confidencial. Como parte de una implementación de zona de aterrizaje soberana, se crean grupos de administración para la informática confidencial.

Dentro de un contexto de soberanía, el uso de la informática confidencial requiere Azure Key Vault y claves administradas por el cliente como servicio auxiliar. Para obtener más información, consulte Cifrado mediante claves administradas por el cliente en Microsoft Cloud for Sovereignty.

Actualización de la estimación inicial de la nube

A medida que termine el diseño de la arquitectura, vuelva a consultar la estimación de la nube para asegurarse de que todavía esté dentro del presupuesto planeado. A medida que añada servicios auxiliares como equilibradores de carga o copias de seguridad, los costes pueden cambiar. Aunque puede usar herramientas como casos empresariales en Azure Migrate y Modernize para realizar ejercicios detallados de gestión de costes, debe revisar periódicamente las estimaciones a medida que ajusta el diseño de la arquitectura.

Si está familiarizado con los procesos de adquisición de TI tradicionales, es posible que la estimación de recursos en la nube le parezca extraña. Cuando se adoptan tecnologías de nube, la adquisición pasa de un modelo de gastos de capital rígido y estructurado a un modelo de gastos operativos fluido. El planeamiento de una migración a la nube suele ser la primera vez que una organización o un equipo de TI encuentre este cambio.

En el modelo tradicional de gastos de capital, un equipo de TI intenta combinar el poder de compra de varias cargas de trabajo en varios programas. Este enfoque centraliza un grupo de recursos de TI compartidos que pueden admitir cada una de esas soluciones. En el modelo de gastos operativos en la nube, los costes se pueden atribuir directamente a las necesidades de compatibilidad de cargas de trabajo individuales, equipos o unidades de negocio. Proporciona a una organización una atribución más directa de los costes para los clientes internos y los objetivos de negocio que respaldan. Este enfoque más dinámico para la administración financiera suele denominarse operaciones financieras (FinOps). Aunque FinOps no es una consideración específica de Azure, puede resultar útil tener una comprensión ampliada de FinOps. Para obtener más información, consulte ¿Qué es FinOps?.

Al diseñar la arquitectura de carga de trabajo para la migración, puede usar la calculadora de precios con la información de la evaluación para comprender el precio de toda la carga de trabajo.

Además, una vez migrada la carga de trabajo, debe seguir trabajando para optimizar los costes de la carga de trabajo. Para obtener más información sobre cómo las organizaciones pueden madurar sus capacidades de gestión de costes, consulte Mejora de la materia de gestión de costes.

Saber cuándo cambiar la arquitectura

Las migraciones tienden a centrarse en mantener una arquitectura existente y realizar la transición a la plataforma en la nube. Sin embargo, hay ocasiones en las que es posible que tenga que rediseñar la carga de trabajo, incluso para la migración. En esta lista se proporcionan ejemplos de cuándo es posible que tenga que realizar cambios en la arquitectura antes de migrar:

• Pago de una deuda técnica. Algunas cargas de trabajo antiguas tienen una gran cantidad de deuda técnica. La deuda técnica puede conducir a desafíos a largo plazo al aumentar los costos de hospedaje con cualquier proveedor de servicios en la nube. Cuando la deuda técnica aumenta de manera poco natural los costes de hospedaje, debe evaluar arquitecturas alternativas.
• Mejorar la confiabilidad. Las bases de referencia de las operaciones estándar proporcionan un grado de confiabilidad y recuperación en la nube. Sin embargo, algunos equipos de carga de trabajo pueden requerir acuerdos de nivel de servicio superiores que podrían conducir a cambios en la arquitectura.
• Cargas de trabajo de alto costo. Durante la migración, debe optimizar todos los recursos para ajustar su tamaño al uso real. Algunas cargas de trabajo pueden requerir modificaciones en la arquitectura para solucionar los problemas específicos de los costes.
• Requisitos de rendimiento. Cuando el rendimiento de la carga de trabajo afecta al negocio, es posible que sea necesaria tener en cuenta una arquitectura adicional.
• Aplicaciones seguras. Los requisitos de seguridad tienden a implementarse de forma centralizada y se suelen aplicar a todas las cargas de trabajo de la cartera. Algunas cargas de trabajo pueden tener requisitos de seguridad específicos que pueden conducir a cambios en la arquitectura.

Todos estos criterios sirven de indicadores de obstáculos potenciales para la migración. En la mayoría de los casos, puede abordar el criterio después de migrar la carga de trabajo mediante el dimensionamiento de los servidores, la adición de nuevos servidores o la aplicación de otros cambios. Sin embargo, si se requiere cualquiera de esos criterios antes de migrar una carga de trabajo, quite la carga de trabajo de la sesión de migración y evalúela individualmente.

El Marco de buena arquitectura de Azure y la Reseña de buena arquitectura de Azure pueden ayudar a guiar esas conversaciones con el propietario técnico de una carga de trabajo específica a fin de tener en cuenta las opciones alternativas para implementar la carga de trabajo.

A continuación, la carga de trabajo se clasificaría como un esfuerzo de rediseño de la arquitectura o modernización dentro del plan de adopción de la nube. Dado el tiempo adicional necesario para rediseñar la arquitectura de una carga de trabajo, tenga en cuenta estas rutas de adopción de carga de trabajo alternativas como parte independiente del proceso de migración.

Lista de comprobación de la arquitectura

Puede usar la siguiente lista de comprobación para asegurarse de cubrir las consideraciones críticas sobre la arquitectura:

• Confirme que la arquitectura cumple los acuerdos de nivel de servicio en materia de disponibilidad, recuperación ante desastres y recuperación de datos.
• Confirme que ha aplicado las prácticas de segmentación de red al diseño de red.
• Confirme que ha planeado la supervisión y la captura de registros.
• Confirme que las máquinas virtuales tienen el tamaño adecuado para el tiempo de proceso real que necesita.
• Confirme que los discos tienen el tamaño adecuado para el tamaño y el rendimiento reales que necesita.
• Confirme que ha previsto los servicios de equilibrio de carga, si fueran necesarios. Estos servicio pueden ser instancias de Azure Load Balancer, Azure Application Gateway, Azure Front Door o Azure Traffic Manager.
• Confirme que ha previsto los requisitos de soberanía e informática confidencial, si fueran necesarios.

Paso siguiente

Implementación de cargas de trabajo de migración