Diseño de la arquitectura de carga 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.

El artículo sobre la racionalización incremental indica que algunas suposiciones arquitectónicas forman parte de cualquier transformación empresarial que incluya una migración. En este artículo se aclaran las suposiciones típicas. También apunta a algunos obstáculos que puede evitar e identifica oportunidades para acelerar el valor empresarial mediante suposiciones arquitectónicas desafiantes. Este modelo incremental para diseñar la arquitectura ayuda a los equipos a avanzar más rápido y obtener resultados empresariales antes.

Diseño de arquitectura base en supuestos comunes

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

• Supongamos una carga de trabajo de infraestructura como servicio (IaaS). La migración de cargas de trabajo implica principalmente mover servidores de un centro de datos físico a un centro de datos en la nube a través de una migración de IaaS. Normalmente, el proceso requiere un mínimo de desarrollo o reconfiguración. Este enfoque se conoce como migración mediante lift-and-shift .
• Mantenga la arquitectura coherente. Realizar cambios en la arquitectura principal durante una migración aumenta considerablemente la complejidad. La depuración de un sistema modificado en una nueva plataforma presenta muchas variables que pueden ser difíciles de aislar. Las cargas de trabajo solo deben someterse a cambios menores durante la migración y se deben probar exhaustivamente los cambios.
• Planear redimensionar los activos Supongamos que pocos activos locales aprovechan completamente algún recurso. Antes o durante 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.
• Capture 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 negociada con la empresa, siga usando el Acuerdo de Nivel de Servicio 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ñar correctamente.
• Planifique el tiempo de inactividad de la migración. Al igual que no cumplir los requisitos del Acuerdo de Nivel de Servicio, el tiempo de inactividad que se produce cuando se 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 comenzar con la planificación del lanzamiento, supongamos que se ha establecido un entendimiento general de los requisitos de interrupción.
• Defina patrones de tráfico de usuarios y aplicaciones. Las soluciones existentes pueden depender de los patrones y soluciones de enrutamiento de red existentes. Identifique los recursos que necesita para soportar el uso actual de la red.
• Planee evitar conflictos de red. Al consolidar centros de datos en un único 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 para evitar interrupciones en los sistemas de producción hospedados en la nube.
• Planificar las tablas de enrutamiento. Asegúrese de que el proyecto incluye un plan para modificar las tablas de enrutamiento si consolida redes o centros de datos. Considere los requisitos de enrutamiento 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 zonas de aterrizaje de Azure. En Preparar la zona de aterrizaje para la migración, ha preparado 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 locales.
• 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 activos.
• Se configura un área de trabajo de registros de Azure Monitor para el registro compartido.
• Se establecen recursos de identidad compartidos para admitir servidores vinculados a un dominio u otras necesidades relacionadas con la identidad.

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

La carga de trabajo que está diseñando tiene asignada una suscripción, idealmente a través de un proceso de vending 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 su 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 según las pautas de los entornos de aplicación.

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

Planee la implementación de recursos específicos de la aplicación en una suscripción específica y planee diseñar una red virtual dedicada para la carga de trabajo. Para obtener más información, consulte instrucciones 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 dependencias, como el análisis de dependencias en Azure Migrate y Modernize. La herramienta le ayuda a identificar las interdependencias entre servidores.

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

Puede usar instrucciones en el Centro de arquitectura de Azure, como las redes de radio a radio , para diseñar cómo funcionan las cargas de trabajo interconectadas después de la migración.

Preparación para la adopción de la computación confidencial

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

Dentro de un contexto de soberanía, el uso de la computación confidencial requiere Azure Key Vault y claves administradas por el cliente como servicio auxiliar. Para obtener más información, consulte cifrado con 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 agregue servicios auxiliares como equilibradores de carga o copias de seguridad, los costos pueden cambiar. Aunque puede usar herramientas como casos empresariales en Azure Migrate y Modernize para realizar ejercicios detallados de administración de costos, debe revisar periódicamente las estimaciones a medida que ajusta el diseño de la arquitectura.

Si está familiarizado con los procesos tradicionales de adquisición de TI, es posible que la estimación de recursos en la nube parezca externa. Al adoptar tecnologías en la nube, la adquisición cambia de un modelo rígido y estructurado de gastos de capital a un modelo de gastos operativos fluidos. Planear 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 nube de gastos operativos, los costos se pueden atribuir directamente a las necesidades de soporte técnico de cargas de trabajo individuales, equipos o unidades de negocio. Proporciona a una organización una atribución más directa de los costos a los clientes internos y a los objetivos empresariales que respaldan. Este enfoque más dinámico para la administración financiera se denomina a menudo 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 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 costos de la carga de trabajo. Para obtener más información sobre cómo las organizaciones pueden madurar sus aptitudes de administración de costos, consulte Mejora de la materia de administración de costos.

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 arquitectónicos antes de migrar:

• Pagar por deuda técnica. Algunas cargas de trabajo envejecidas conllevan una gran cantidad de deuda técnica. La deuda técnica puede provocar desafíos a largo plazo aumentando los costos de hospedaje con cualquier proveedor de nube. Cuando la deuda técnica aumenta de manera anormal los costos de hospedaje, debe evaluar arquitecturas alternativas.
• Mejora de la confiabilidad. Las líneas base de operación estándar proporcionan un grado de confiabilidad y recuperación en la nube. Algunos equipos de carga de trabajo pueden requerir acuerdos de nivel de servicio más altos, lo que podría provocar cambios arquitectónicos.
• Cargas de trabajo de alto costo. Durante la migración, debe optimizar todos los recursos para alinear el tamaño con el uso real. Algunas cargas de trabajo pueden requerir modificaciones arquitectónicas para abordar problemas de costos específicos.
• Requisitos de rendimiento. Cuando el rendimiento de la carga de trabajo afecta directamente a la empresa, podría ser necesario tener en cuenta una arquitectura adicional.
• Aplicaciones seguras. Los requisitos de seguridad tienden a implementarse de forma centralizada y normalmente se aplican a todas las cargas de trabajo de una cartera. Algunas cargas de trabajo pueden tener requisitos de seguridad específicos que pueden dar lugar a cambios arquitectónicos.

Cada uno de estos criterios sirve como indicador de un posible obstáculo de migración. En la mayoría de los casos, puede abordar el criterio después de migrar la carga de trabajo mediante el ajuste de tamaño de los servidores, agregar nuevos servidores o realizar otros cambios. Sin embargo, si se requiere alguno de esos criterios antes de migrar una carga de trabajo, quite la carga de trabajo de la oleada de migración y evalúela individualmente.

Azure Well-Architected Framework y Azure Well-Architected Review pueden ayudar a guiar las conversaciones con el propietario técnico de una carga de trabajo específica para ayudarles a considerar opciones alternativas para implementar la carga de trabajo.

A continuación, la carga de trabajo se clasifica como un esfuerzo de rediseño o modernización en el plan de adopción de la nube. Debido al tiempo adicional que se tarda en rediseñar una carga de trabajo, considere estas rutas de adopción de cargas de trabajo alternativas como independientes del proceso de migración.

Lista de comprobación de arquitectura

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

• Confirme que la arquitectura cumple los Acuerdos de Nivel de Servicio para la disponibilidad, la recuperación ante desastres y la recuperación de datos.
• Confirme que ha aplicado 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 real y el rendimiento que necesita.
• Confirme que ha planificado los servicios de equilibrio de carga si son necesarios. Los servicios pueden incluir instancias de Azure Load Balancer, Azure Application Gateway, Azure Front Door o Azure Traffic Manager.
• Confirme que ha planeado los requisitos de soberanía y computación confidencial si son necesarios.

Paso siguiente

Desplegar cargas de trabajo de migración