Escenario: transición de una suscripción única sin grupos de administración a la arquitectura conceptual de la zona de aterrizaje de Azure

En este artículo se describen las consideraciones e instrucciones para migrar y realizar la transición del entorno de Azure a la arquitectura conceptual de la zona de aterrizaje de Azure. Este escenario abarca una suscripción única sin grupos de administración.

En este escenario, el cliente ya usa Azure y ya hospeda algunas aplicaciones o servicios dentro de la plataforma. Sin embargo, su implementación actual limita su escalabilidad y crecimiento en relación a su estrategia de primero en la nube.

Como parte de esta expansión, también planean migrar fuera de sus centros de datos locales y en Azure. Durante la migración, conducen a la modernización y transformación de sus aplicaciones o servicios para usar tecnologías nativas de nube siempre que sea posible. Por ejemplo, pueden usar Azure SQL Database y Azure Kubernetes Service (AKS). Saben que se tarda mucho tiempo y esfuerzo, por lo que planean lift-and-shift para empezar. Inicialmente, este plan requiere conectividad híbrida a través de servicios como Azure VPN Gateway o Azure ExpressRoute.

El cliente desea pasar de su enfoque existente a una arquitectura de escala empresarial. Esta arquitectura admite su estrategia de primero en la nube y tiene una plataforma sólida que se escala a medida que el cliente elimina sus centros de datos locales.

Estado actual

En este escenario, el estado actual del entorno de Azure del cliente consta de:

• Una única suscripción de Azure.
• Sin grupos de administración personalizados.
• Distribución de recursos no uniforme. Los recursos de plataforma y carga de trabajo se implementan en la misma suscripción de Azure.
• Uso mínimo de Azure Policy. Las asignaciones de directivas, como los efectos de auditoría y los efectos de denegación, se realizan para cada grupo de recursos, con excepciones.
• Grupos de recursos que se tratan como unidades de administración y escalado.
• Asignaciones de roles de control de acceso basado en roles para cada grupo de recursos.
• Una sola red virtual.
  • Conectividad que no sea híbrida a través de servicios como Azure VPN Gateway o Azure ExpressRoute.
  • Se crea una nueva subred por cada aplicación.
• Varias aplicaciones independientes en cada uno de los grupos de recursos app-xx-rg. Las aplicaciones se controlan y operan por diferentes equipos de aplicaciones o servicios.

En el diagrama siguiente se muestra el estado actual de este escenario.

Transición a la arquitectura conceptual de la zona de aterrizaje de Azure

Antes de implementar este enfoque, revise Arquitectura conceptual de zonas de aterrizaje de Azure y Áreas de diseño de zonas de aterrizaje de Azure.

Para realizar la transición del estado actual de este escenario a una arquitectura conceptual de zona de aterrizaje de Azure, use este enfoque:

1. Implemente el acelerador de zona de aterrizaje de Azure en el inquilino de Microsoft Entra ID en paralelo con el entorno actual. Este método proporciona una transición fluida y por fases a la nueva arquitectura de zona de aterrizaje con una interrupción mínima de las cargas de trabajo activas.

   Esta implementación crea una nueva estructura de grupo de administración. Esta estructura está alineada con los principios y recomendaciones de diseño de las zonas de aterrizaje de Azure. También garantiza que estos cambios no afecten al entorno existente.

2. (Opcional) trabaje con equipos de aplicación o servicio para migrar las cargas de trabajo que se implementan en la suscripción original a nuevas suscripciones de Azure. Para más información, consulte Transición de entornos de Azure existentes a la arquitectura conceptual de la zona de aterrizaje de Azure. Coloque cargas de trabajo en la jerarquía del grupo de administración de arquitectura conceptual de la zona de aterrizaje de Azure recién implementada en el grupo de administración correcto, como corporativo o en línea en el diagrama siguiente.

   Para obtener más información sobre el efecto en los recursos al migrar, consulte Directivas.

   Finalmente, puede cancelar la suscripción de Azure existente y colocarla en el grupo de administración retirado.

   Nota:

   No es necesario migrar las aplicaciones o servicios existentes a nuevas zonas de aterrizaje ni suscripciones de Azure.

3. Cree nuevas suscripciones de Azure para proporcionar zonas de aterrizaje que puedan admitir proyectos de migración desde el entorno local. Colóquelas en el grupo de administración adecuado, como corporativo o en línea en el diagrama siguiente.

   Para obtener más información, consulte Preparación de la zona de aterrizaje para obtener instrucciones de migración.

En el diagrama siguiente se muestra el estado de este escenario durante la migración.

Resumen

En este escenario, el cliente logró sus planes de expansión y escalado dentro de Azure mediante la implementación de la arquitectura conceptual de la zona de aterrizaje de Azure en paralelo a su entorno existente.