Consideraciones del proveedor de software independiente (ISV) para las zonas de aterrizaje de Azure
En muchas organizaciones, la arquitectura conceptual de las zonas de aterrizaje de Azure que se muestra a continuación representa el destino en su recorrido de adopción de la nube. Las zonas de aterrizaje describen cómo crear un entorno de Azure con varias suscripciones. Cada zona de aterrizaje tiene en cuenta la escala, la seguridad, la gobernanza, las redes y la identidad, y se basa en comentarios y lecciones aprendidas de muchos clientes.
Sugerencia
Puede resultar útil pensar en las zonas de aterrizaje de Azure como planos de ciudad. Las arquitecturas de las cargas de trabajo implementadas en una zona de aterrizaje son como planos de los edificios de una ciudad.
Todos los sistemas de agua, gas, electricidad y transporte de una ciudad deben estar instalados antes de que se puedan construir edificios. Del mismo modo, los componentes de una zona de aterrizaje de Azure, incluidos los grupos de administración, las directivas, las suscripciones y el control de acceso basado en roles (RBAC), deben estar instalados antes de que se puedan implementar las cargas de trabajo de producción.
Como proveedor de software independiente (ISV) que compila y opera la solución en Azure, debe hacer referencia a los siguientes recursos a medida que compila el entorno de Azure:
- Zonas de aterrizaje de Azure: proporcionan instrucciones para el entorno general de Azure.
- Marco de buena arquitectura de Azure: proporciona instrucciones de arquitectura aplicables a todas las cargas de trabajo.
- Arquitectura de soluciones multiinquilino en Azure: proporciona instrucciones de arquitectura específicas para soluciones multiinquilino en Azure.
Las zonas de aterrizaje de Azure le permiten elegir una dirección para el entorno general de Azure. Sin embargo, como proveedor ISV, de SaaS o de una startup, las necesidades de implementación específicas pueden diferir de los escenarios de cliente más estándar. A continuación se muestran algunos ejemplos de escenarios de implementación diferentes:
- Debe crear software que los clientes implementen en sus propias suscripciones.
- Tiene su propio plano de control y usa scripts de automatización o software para implementar y configurar recursos de Azure para sus soluciones SaaS.
- Es un ISV o startup pequeño y quiere empezar con el menor costo posible, por lo que es posible que no quiera usar inicialmente servicios como Azure Firewall y Azure DDoS Protection.
- Es un ISV de SaaS grande y tiene previsto dividir la aplicación SaaS en varias suscripciones a escala. También quiere agrupar las suscripciones para que se correspondan con los entornos de desarrollo, prueba, ensayo y producción.
- El modelo operativo de la organización separa los roles del equipo de TI corporativo y de los equipos de productos SaaS. El equipo de TI corporativo de su organización puede administrar recursos como Microsoft Office 365 y Microsoft Teams y, por otro lado, el equipo de productos SaaS puede ser responsable de compilar y administrar el producto SaaS (incluida su plataforma central y sus componentes de identidad).
Nota
A veces, los ISV quieren empezar con una sola suscripción de Azure que incluya aspectos de la plataforma que sean de "servicios compartidos" y recursos de carga de trabajo reales. Aunque esto es técnicamente posible, tenga en cuenta que se enfrentará a otros desafíos más adelante, cuando necesite mover recursos entre suscripciones y vea que no todos los tipos de recursos se pueden mover. Revise el impacto de las desviaciones de diseño para comprender qué desviaciones son posibles y sus distintos niveles de riesgo.
Modelos de implementación de ISV
Las soluciones de ISV suelen ser apropiadas para uno de los tres modelos de implementación: SaaS puro, implementado por el cliente o SaaS de implementación dual. En esta sección se describen las diferentes consideraciones de cada modelo para las zonas de aterrizaje de Azure.
SaaS puro
En el modelo de tipo "SaaS puro", el software se implementa completamente solo en las suscripciones de Azure. Los clientes finales consumen el software sin implementarlo en sus propias suscripciones de Azure. En el diagrama siguiente, los usuarios usan una aplicación de SaaS puro proporcionada por un ISV:
Algunos ejemplos de software de tipo "SaaS puro" incluyen el correo electrónico como servicio, Kafka como servicio, el almacenamiento de datos en la nube como servicio y varias listas de SaaS en Azure Marketplace.
Si es un ISV de SaaS pequeño, es posible que no tenga que usar varias suscripciones de Azure para implementar los recursos inmediatamente. Pero a medida que se escala, los límites de suscripción de Azure pueden afectar a la capacidad de escalado de una sola suscripción. Revise los principios de diseño de la zona de aterrizaje a escala empresarial (especialmente la democratización de las suscripciones), y familiarícese con los enfoques arquitectónicos para multiinquilinos y así poder planear su crecimiento futuro.
Los ISV que crean soluciones de SaaS puro deben tener en cuenta lo siguiente:
- ¿Todos los recursos de Azure que componen la solución de SaaS deben estar en una suscripción de Azure o deben particionarse entre varias suscripciones de Azure?
- ¿Es necesario hospedar a cada cliente en su propia suscripción de Azure dedicada o se pueden crear recursos dentro de una o varias suscripciones compartidas?
- ¿Cómo se puede aplicar el patrón de stamp de implementación (unidad de escalado) en todos los niveles de la solución?
- ¿Cómo se puede usar la organización de recursos de Azure en soluciones multiinquilino para evitar desafíos de escala y los límites de suscripción de Azure?
Implementado por el cliente
En el modelo implementado por el cliente, los clientes finales le compran el software y, a continuación, lo implementan en sus propias suscripciones de Azure. Pueden iniciar la implementación desde Azure Marketplace o hacerlo manualmente siguiendo las instrucciones y usando los scripts que proporcione.
En el diagrama siguiente, un ISV proporciona un paquete de software o un producto de catálogo de Azure Marketplace, y los usuarios implementan ese recurso en sus propias suscripciones de Azure junto con otras cargas de trabajo:
El otro elemento de carga de trabajo del cliente del diagrama puede representar la propia carga de trabajo de un cliente u otro producto del ISV que el cliente haya implementado en su suscripción de Azure. Los clientes suelen implementar varios productos de diferentes ISV en sus suscripciones de Azure. Asimismo, combinan estos productos individuales para crear soluciones. Por ejemplo, un cliente puede implementar un producto de base de datos desde un ISV, una aplicación virtual de red de otro ISV y una aplicación web de un tercer ISV.
Entre los ejemplos de productos de ISV implementados por el cliente se incluyen varias imágenes de máquina virtual (como las aplicaciones virtuales de red y almacenamiento) y las aplicaciones de Azure en Azure Marketplace.
En el caso de algunas soluciones implementadas por el cliente, una organización puede proporcionar administración y actualizaciones de la solución implementada en sus suscripciones de Azure de cliente final mediante Azure Lighthouse o Azure Managed Applications. Los ISV, los integradores de soluciones (SI) y los proveedores de servicios administrados (MSP) pueden usar esta estrategia si les resulta útil para sus necesidades particulares.
Las soluciones de ISV implementadas por el cliente se consideran una carga de trabajo de aplicación estándar desde la perspectiva de las zonas de aterrizaje de Azure. Puede leer la guía de las zonas de aterrizaje de Azure a medida que diseña el producto para trabajar con los principios de diseño de las zonas de aterrizaje de Azure que adoptan los clientes de Azure.
Es especialmente importante que tenga una buena comprensión de los conceptos de la zona de aterrizaje de Azure a medida que migra las cargas de trabajo de los clientes existentes a Azure.
Los ISV que crean soluciones implementadas por el cliente deben tener en cuenta lo siguiente:
- ¿Un cliente debe implementar la solución en su propia suscripción dedicada o en una suscripción existente que contenga cargas de trabajo relacionadas?
- ¿Cómo deben establecer los clientes la conectividad de red entre las cargas de trabajo existentes (dentro y fuera de Azure) y la solución?
- ¿Nuestra solución admite mecanismos de autenticación de Microsoft Entra ID o requiere otros protocolos como LDAP o Kerberos?
- ¿Cómo se reducen o eliminan las infracciones de Azure Policy? Por ejemplo, las que causan conflictos entre las plantillas de la solución y las directivas de Azure de un cliente.
Las directivas de Azure del cliente que pueden causar infracciones de Azure Policy incluyen ejemplos como "Todas las subredes deben tener un grupo de seguridad de red" y "No se pueden conectar direcciones IP públicas a interfaces de red en la zona de aterrizaje Corp". Tenga en cuenta que es posible que se encuentre con este tipo de directivas conflictivas a medida que planee la implementación.
SaaS de implementación dual
Algunas soluciones de SaaS interactúan o usan recursos que se implementan en las suscripciones de Azure de los clientes. Este modelo de implementación se denomina a veces SaaS de implementación dual o híbrido de SaaS. En el diagrama siguiente, un ISV proporciona una solución de SaaS hospedada que interactúa con los recursos implementados en la suscripción de Azure de un cliente final:
Un ejemplo real de SaaS de implementación dual es Microsoft Power BI, un servicio de SaaS que, opcionalmente, puede usar una puerta de enlace de datos local de Power BI implementada en una máquina virtual en la suscripción de Azure de un cliente.
Otros ejemplos de escenarios de SaaS de implementación dual incluyen:
- Su organización crea Virtual Desktop Manager, un producto que proporciona una interfaz de consola de SaaS para controlar los recursos de Azure Virtual Desktop en la suscripción de Azure de cada cliente.
- Su organización proporciona una consola de SaaS para el análisis de datos y crea y elimina dinámicamente máquinas virtuales del nodo de proceso en la suscripción de Azure de cada cliente.
Como ISV de implementación dual, debe consultar la zona de aterrizaje de Azure para obtener instrucciones en dos áreas: estructurar su propio entorno de Azure para hospedar el servicio de SaaS y garantizar una interacción adecuada de las implementaciones en las suscripciones de Azure y las zonas de aterrizaje de los clientes.
Los ISV que crean soluciones de SaaS de implementación dual deben tener en cuenta lo siguiente:
- ¿Se han revisado todas las opciones para crear soluciones de SaaS puro e implementado por el cliente?
- ¿Qué componentes de la solución se deben hospedar en las suscripciones de Azure y qué componentes debe implementar el cliente?
- ¿Cómo se puede garantizar el aprovisionamiento seguro y las interacciones con los recursos implementados en las suscripciones de Azure de los clientes?
Principios de diseño e implementaciones de la zona de aterrizaje de Azure
Según los principios de diseño de la zona de aterrizaje de Azure, es recomendable alinearse con las funcionalidades de la plataforma nativa de Azure, como Log Analytics, Azure Monitor y Azure Firewall. La guía de zona de aterrizaje también proporciona opciones específicas para la implementación de la zona de aterrizaje de Azure.
Como ISV, puede decidir implementar sus propios entornos de zona de aterrizaje. Es posible que tenga que usar su propia automatización para implementar recursos de Azure en las suscripciones. O bien, es posible que quiera seguir usando herramientas que ya empleaba para el registro, la supervisión y otros servicios de nivel de plataforma.
Si implementa sus propios entornos de zona de aterrizaje, le recomendamos que use la guía de la zona de aterrizaje de Azure y las implementaciones de ejemplo para obtener una referencia y poder alinear su enfoque con los diseños de la zona de aterrizaje de Azure que se han probado.
Inquilinos de Microsoft Entra
Cada zona de aterrizaje de Azure y su jerarquía de grupos de administración se basa en un único inquilino de Microsoft Entra. Esto significa que la primera decisión que debe tomar es qué inquilino de Microsoft Entra va a usar como origen de identidades para administrar los recursos de Azure. Las identidades de Microsoft Entra ID incluyen usuarios, grupos y entidades de servicio.
Sugerencia
El inquilino de Microsoft Entra que seleccione para la zona de aterrizaje no afecta a la autenticación de nivel de aplicación. Todavía puede usar otros proveedores de identidades, como Azure AD B2C, independientemente del inquilino que elija.
En la guía para las zonas de aterrizaje de Azure e inquilinos de Microsoft Entra se recomienda encarecidamente usar un solo inquilino de Microsoft Entra, ya que este es el enfoque correcto para la mayoría de las situaciones. Sin embargo, como ISV de SaaS, es posible que tenga alguna razón para usar dos inquilinos.
En el caso de algunos ISV de SaaS, un equipo administra los recursos corporativos y un equipo independiente usa la solución de SaaS. Esta separación puede ser por motivos operativos o para cumplir con los requisitos normativos. Tal vez al equipo de TI corporativo no se le permite administrar ninguna suscripción ni recursos relacionados con SaaS, por lo que no pueden ser administradores del inquilino de Microsoft Entra. Si este es su caso, considere la posibilidad de usar dos inquilinos de Microsoft Entra independientes: un inquilino para recursos de TI corporativos como Office 365 y un inquilino para los recursos de Azure que componen la solución de SaaS.
Cada inquilino de Microsoft Entra debe tener su propio nombre de dominio. Si su organización usa dos inquilinos, puede elegir un nombre como contoso.com para el inquilino de Microsoft Entra corporativo y contoso-saas-ops.com para el inquilino de SaaS de Microsoft Entra, tal como se muestra en el diagrama siguiente.
Advertencia
Cuando se usan varios inquilinos de Microsoft Entra, aumenta la sobrecarga de administración. Si usa características de Microsoft Entra ID P1 o P2 como Privileged Identity Management, debe comprar licencias individuales para cada inquilino de Microsoft Entra. Es recomendable usar varios inquilinos de Microsoft Entra solo si su situación realmente lo requiere.
Evite el uso de inquilinos de Microsoft Entra independientes en entornos de preproducción y producción. En lugar de crear dos inquilinos como contoso-saas-ops-preprod.com y contoso-saas-ops-prod.com con suscripciones de Azure independientes en cada uno, debe crear un inquilino de Microsoft Entra. Puede usar grupos de administración y RBAC de Azure para controlar el acceso a suscripciones y recursos en este único inquilino.
Para obtener más información sobre el uso de varios inquilinos de Microsoft Entra, consulte Zonas de aterrizaje de Azure y varios inquilinos de Microsoft Entra y Aislamiento de recursos con varios inquilinos.
Grupos de administración
La arquitectura conceptual de la zona de aterrizaje de Azure recomienda usar una jerarquía de grupos de administración específica. Sin embargo, los ISV pueden tener requisitos diferentes que otros organismos. En esta sección se describen algunas formas en que la organización del ISV puede optar por adoptar prácticas diferentes a las que recomienda la arquitectura conceptual de la zona de aterrizaje.
Grupo de administración de nivel superior
La jerarquía de grupos de administración está anidada en el grupo de administración de grupos raíz de inquilino creado por Azure. Recuerde que no se usa directamente el grupo raíz del inquilino.
Una organización estándar que tiene un equipo de TI corporativo centralizado que administra su plataforma y servicios compartidos (como el registro, la red, la identidad y la seguridad), normalmente crea un grupo de administración de nivel superior en el grupo raíz de inquilino creado por Azure e implementa el resto de sus grupos de administración a continuación. Este grupo de administración de nivel superior suele nombrarse como la propia organización (como Contoso).
Como ISV de SaaS, es posible que tenga un producto de SaaS o algunos productos de SaaS o líneas de negocio independientes. Aunque generalmente debe usar el mismo inquilino de Microsoft Entra para administrar recursos de Azure en todos los productos (tal como se describe en la sección Inquilinos de Microsoft Entra), en algunos escenarios puede optar por implementar varias jerarquías de grupos de administración.
Tenga en cuenta la independencia de los productos y pregúntese lo siguiente:
- ¿Todos los productos usan las mismas plataformas para DevOps y las opciones de identidad, seguridad, conectividad y registro?
- ¿Un único equipo central administra los servicios compartidos?
Si respondió que Sí a ambas preguntas, cree un único grupo de administración de productos de SaaS de nivel superior en el grupo raíz inquilino.
Si en su lugar respondió que No y cada uno de los productos de SaaS está administrado y operado por equipos de plataforma independientes, considere la posibilidad de crear un grupo de administración de nivel superior independiente para cada producto, como los dos grupos de administración de nivel superior SaaS Product-01 y SaaS Product-02.
Sugerencia
Un ISV no suele tener más que algunos grupos de administración de nivel superior. A menudo, se pueden combinar varios productos debido a sus similitudes para administrarlos y usarlos.
Este enfoque de administración es similar al enfoque de prueba de las zonas de aterrizaje a escala empresarial. Sin embargo, en lugar de crear Contoso y Contoso-Canary en el grupo raíz inquilino, en este enfoque la empresa de ejemplo creará los grupos de administración de nivel superior contoso-SaaS-Product-01, Contoso-SaaS-Product-02 y Contoso-SaaS-Product-03 específicos del producto. Este escenario se ilustra en el diagrama siguiente:
Grupo de administración de plataformas
En la jerarquía de la organización de recursos de la zona de aterrizaje de Azure, el grupo de administración de plataformas contiene todas las suscripciones de Azure que hospedan los componentes y servicios compartidos que usan las cargas de trabajo en las suscripciones de la zona de aterrizaje. Algunos ejemplos de componentes implementados en las suscripciones de servicios compartidos y de plataforma incluyen la infraestructura de registro centralizada (como áreas de trabajo de Log Analytics), DevOps, la seguridad, las herramientas de automatización, los recursos de red central (como planes de protección contra DDos y red virtual de concentrador) y los servicios del plano de control de un ISV.
El grupo de administración de plataformas se divide con frecuencia en grupos secundarios de identidad, administración y conectividad para proporcionar una separación cómoda de roles y directivas para los clientes empresariales.
En su organización, es posible que tenga un único equipo que administre todos los componentes de la plataforma compartida, como la identidad, las redes y la administración. Si es así y si no tiene planes para separar esa administración en varios equipos, considere la posibilidad de usar un único grupo de administración de plataformas.
Si en su lugar tiene equipos independientes que administran diferentes partes de la plataforma centralizada, debe implementar más niveles en la jerarquía del grupo de administración en el grupo de administración de plataformas. Esto le permite asignar directivas independientes en cada parte de la plataforma centralizada.
En el diagrama siguiente se muestran dos implementaciones potenciales del grupo de administración de plataformas. La opción A muestra un escenario más completo, donde el grupo de administración de plataformas contiene tres grupos de administración secundarios: Administración y DevOps, Identidad y seguridad y Conectividad. Cada grupo de administración secundario contiene una suscripción con los recursos pertinentes. La opción B muestra un escenario más sencillo, donde el grupo de administración de plataformas contiene una sola suscripción de plataforma.
Grupo de administración de zonas de aterrizaje
El grupo de administración de zonas de aterrizaje contiene las suscripciones de Azure que hospedan los subsistemas y las cargas de trabajo reales de la solución de SaaS.
Este grupo de administración contiene uno o varios grupos de administración secundarios. Cada uno de los grupos de administración secundarios de la sección Zonas de aterrizaje representa un arquetipo de carga de trabajo o subsistema, con requisitos de acceso y directivas coherentes que deben aplicarse a todas las suscripciones. Entre las razones para usar varios arquetipos se incluyen:
- Cumplimiento: si un subsistema del producto SaaS debe ser compatible con PCI-DSS, considere la posibilidad de crear un grupo de administración secundario de arquetipo PCI DSS en las Zonas de aterrizaje. Todas las suscripciones de Azure que contienen recursos dentro del ámbito de cumplimiento de PCI-DSS deben colocarse dentro de ese grupo de administración.
- Niveles: considere la posibilidad de crear arquetipos de zona de aterrizaje independientes para los clientes de nivel dedicado y los clientes de nivel gratuito de la solución SaaS. Cada uno de los grupos de administración secundarios contiene diferentes configuraciones de Azure Policy. Por ejemplo, las directivas del nivel gratuito pueden restringir las implementaciones para habilitar solo las SKU de máquina virtual especificadas, y las directivas del nivel dedicado pueden requerir la implementación de recursos en regiones específicas.
Grupos de administración específicos del entorno
Los ISV de SaaS suelen organizar sus entornos de nube mediante el modelado de sus entornos de ciclo de vida de desarrollo de software en una secuencia. Normalmente, esto requiere primero la implementación en un entorno de desarrollo, luego en un entorno de prueba, en un entorno de ensayo y, por último, en un entorno de producción.
Una diferencia común entre los entornos son sus reglas de RBAC de Azure, como quién puede acceder a cada grupo de suscripciones. Por ejemplo, los equipos de DevOps, SaaSOps, desarrollo y pruebas pueden tener distintos niveles de acceso a diferentes entornos.
Importante
La mayoría de los clientes de Azure tienen cientos de aplicaciones y usan suscripciones de Azure independientes para cada equipo de aplicaciones. Si resulta que cada aplicación tiene sus propios grupos de desarrollo, prueba, ensayo y administración de producción, habría un gran número de grupos de administración con directivas casi idénticas. Para la mayoría de los clientes, las preguntas más frecuentes sobre la zona de aterrizaje de escalado de Enterprise aconsejan el uso de grupos de administración independientes para cada entorno. Es recomendable usar suscripciones independientes dentro de un único grupo de administración en su lugar.
Sin embargo, los ISV de SaaS pueden tener requisitos diferentes que la mayoría de los demás clientes de Azure y pueden tener una buena razón para usar grupos de administración específicos del entorno en algunas situaciones.
A veces, los ISV de SaaS necesitan agrupar varias suscripciones que representan extensiones o particiones del mismo subsistema, aplicación o carga de trabajo. Es posible que tenga que aplicar directivas o asignaciones de roles a grupos de suscripciones de una manera notablemente diferente que en el grupo de administración de arquetipos. En este caso, considere la posibilidad de crear grupos de administración secundarios que correspondan a cada entorno en el grupo de administración de arquetipos.
En los diagramas siguientes se muestran dos opciones posibles. La opción A muestra un escenario con suscripciones independientes para cada entorno, pero sin grupos de administración específicos del entorno. La opción B muestra un escenario de ISV de SaaS con grupos de administración específicos del entorno en el grupo de administración Stamps regulares. Cada grupo de administración específico del entorno contiene varias suscripciones. Con el tiempo, el ISV escala sus recursos de Azure en cada entorno en un número creciente de suscripciones con un conjunto común de directivas y asignaciones de roles.
Seleccione cada pestaña para ver los dos diagramas.
Grupos de administración de espacios aislados y retirados
La guía de organización de recursos de la zona de aterrizaje de Azure recomienda incluir grupos de administración retirados y espacios aislados directamente debajo del grupo de administración de nivel superior.
El grupo de administración retirado es un lugar de retención para las suscripciones de Azure deshabilitadas y que, finalmente, se eliminarán. Puede mover una suscripción que ya no esté en uso a este grupo de administración para realizar un seguimiento hasta que todos los recursos de la suscripción se eliminen permanentemente.
El grupo de administración de espacios aislados normalmente contiene suscripciones de Azure que se usan con fines de exploración y tienen directivas flexibles o no aplicadas a ellas. Por ejemplo, puede proporcionar a los desarrolladores individuales sus propias suscripciones para desarrollo y pruebas. Para evitar aplicar las directivas normales y la gobernanza a estas suscripciones, puede colocarlas en el grupo de administración de espacios aislados. Esto aumenta la agilidad de los desarrolladores y les permite experimentar fácilmente con Azure.
Importante
Las suscripciones del grupo de administración de espacios aislados no deben tener conectividad directa con las suscripciones de la zona de aterrizaje. Evite conectar suscripciones de espacio aislado a las cargas de trabajo de producción o a cualquier entorno que no sea de producción que refleje los entornos de producción.
En el diagrama siguiente se muestran dos opciones posibles. La opción A no incluye los grupos de administración de espacio aislado y retirados, mientras que la opción B sí.
Zonas de aterrizaje de ISV de ejemplo
En esta sección se incluyen dos estructuras de ejemplo de la zona de aterrizaje de Azure para un ISV de SaaS. Seleccione cada pestaña para comparar las dos zonas de aterrizaje de ejemplo.
En el diagrama siguiente se muestra una jerarquía de ejemplo de las zonas de aterrizaje de Azure de ISV de SaaS con las siguientes características:
- El ISV mantiene todos sus componentes de plataforma en una sola suscripción de Azure, en lugar de dividirlos en varios grupos de administración de plataformas.
- Solo hay un grupo de administración de zonas de aterrizaje.
- La zona de aterrizaje incluye grupos de administración específicos del entorno para organizar suscripciones y asignar diferentes directivas y roles.
- El ISV no incluye los grupos de administración para las suscripciones de espacio aislado y retiradas.
Pasos siguientes
- Si va a crear una solución multiinquilino, obtenga más información sobre cómo diseñar soluciones multiinquilino en Azure.
- Obtenga más información para saber qué es una zona de aterrizaje de Azure.
- Obtenga más información sobre las Áreas de diseño de las zonas de aterrizaje de Azure.