Arquitectura de línea base crítica en una zona de aterrizaje de Azure
Esta arquitectura de referencia proporciona instrucciones para implementar una carga de trabajo crítica que usa servicios compartidos centralizados, necesita conectividad local e se integra con otras cargas de trabajo de una empresa. Esta guía está pensada para un propietario de carga de trabajo que forma parte de un equipo de aplicaciones de la organización.
Es posible que se encuentre en esta situación cuando su organización quiera implementar la carga de trabajo en una zona de aterrizaje de aplicaciones de Azure que hereda el grupo de administración corp. Se espera que la carga de trabajo se integre con recursos compartidos aprovisionados previamente en la zona de aterrizaje de la plataforma Azure administrada por equipos centralizados.
Importante
¿Qué es una zona de aterrizaje de Azure? Una zona de aterrizaje de la aplicación es una suscripción de Azure en la que se ejecuta la carga de trabajo. Está conectado a los recursos compartidos de la organización. A través de esa conexión, tiene acceso a la infraestructura básica necesaria para ejecutar la carga de trabajo, como redes, administración de acceso a identidades, directivas y supervisión. Las zonas de aterrizaje de la plataforma son una colección de varias suscripciones, cada una con una función específica. Por ejemplo, la suscripción conectividad proporciona una resolución DNS centralizada, conectividad local y aplicaciones virtuales de red (NVA) que están disponibles para su uso por parte de los equipos de aplicaciones.
Como propietario de la carga de trabajo, puede beneficiarse al descargar la administración de recursos compartidos en equipos centrales y centrarse en los esfuerzos de desarrollo de cargas de trabajo. Las ventajas de la organización al aplicar una gobernanza coherente y amortizar los costos en varias cargas de trabajo.
Se recomienda encarecidamente que comprenda el concepto de zonas de aterrizaje de Azure.
En este enfoque, la confiabilidad máxima es una responsabilidad compartida entre usted y el equipo de la plataforma. Los componentes administrados centralmente deben ser muy confiables para que una carga de trabajo crítica funcione según lo previsto. Debe tener una relación de confianza con el equipo de la plataforma para que los problemas de falta de disponibilidad en los servicios centralizados, que afectan a la carga de trabajo, se mitiguen en el nivel de plataforma. Sin embargo, su equipo es responsable de los requisitos de conducción con el equipo de la plataforma para lograr sus objetivos.
Esta arquitectura se basa en la arquitectura de línea base crítica con controles de red. Se recomienda familiarizarse con la arquitectura de línea base antes de continuar con este artículo.
Nota:
La guía está respaldada por una implementación de ejemplo de nivel de producción que muestra el desarrollo de aplicaciones críticas en Azure. Esta implementación se puede usar como base para el desarrollo de soluciones adicionales como primer paso hacia la producción.
Estrategias clave de diseño
Aplique estas estrategias sobre la línea base crítica:
Ruta de acceso crítica
No todos los componentes de la arquitectura deben ser igualmente confiables. La ruta de acceso crítica incluye los componentes que deben mantenerse funcionales para que la carga de trabajo no experimente ningún tiempo de inclusión o un rendimiento degradado. Mantener esa ruta de acceso ajustada minimizará los puntos de error.
Ciclo de vida de los componentes
Considere el ciclo de vida de los componentes críticos porque tiene un impacto en el objetivo de lograr un tiempo de inactividad casi cero. Los componentes pueden ser recursos efímeros o de corta duración que se pueden crear y destruir según sea necesario; recursos no efímeros o de larga duración que comparten la duración con el sistema o la región.
Dependencias externas
Minimice las dependencias externas de componentes y procesos, que pueden introducir puntos de error. La arquitectura tiene recursos propiedad de varios equipos fuera de su equipo. Esos componentes (si son críticos) están dentro del ámbito de esta arquitectura.
Topología de suscripción
Las zonas de aterrizaje de Azure no implican una sola topología de suscripción. Planee la superficie de suscripción con antelación con el equipo de la plataforma para adaptarse a los requisitos de confiabilidad de la carga de trabajo en todos los entornos.
Observabilidad autónoma en la ruta de acceso crítica
Tener recursos de supervisión dedicados que permitan al equipo consultar rápidamente su recopilación de datos (especialmente la ruta crítica) y actuar en las correcciones.
Arquitectura
Descargar un archivo de Visio de esta arquitectura.
Los componentes de esta arquitectura son los mismos que la arquitectura de línea base crítica con controles de red. Las descripciones son breves para mayor brevedad. Si necesita más información, consulte los artículos vinculados. Para obtener documentación del producto sobre los servicios de Azure, consulte Recursos relacionados.
Recursos globales
Estos recursos residen en las suscripciones de zona de aterrizaje de la aplicación. Los recursos globales no son efímeros y comparten la duración del sistema. Los servicios de Azure y su configuración siguen siendo los mismos que los recursos globales de línea base.
Recursos de red regionales
Estos recursos residen en las suscripciones de la zona de aterrizaje de la plataforma y en las suscripciones de zona de aterrizaje de la aplicación. La arquitectura de línea de base implementa todos los recursos propiedad de usted. Sin embargo, en esta arquitectura, los recursos de red se proporcionan a través de la suscripción de conectividad se aprovisionan como parte de la zona de aterrizaje de la plataforma.
En este artículo, consulte la sección Red virtual del centro regional .
Recursos de sello regional
Estos recursos residen en las suscripciones de zona de aterrizaje de la aplicación. Estos recursos no comparten nada con otros recursos, excepto los recursos globales.
La mayoría de los servicios de Azure y su configuración siguen siendo los mismos que la arquitectura de marca de línea de base, excepto los recursos de red, que el equipo de plataforma aprovisiona previamente.
En este artículo, consulte la sección Red virtual de radio regional .
Recursos externos
La carga de trabajo interactúa con los recursos locales. Algunos de ellos se encuentran en la ruta de acceso crítica para la carga de trabajo, por ejemplo, una base de datos local. Estos recursos y la comunicación con ellos se tienen en cuenta en el Acuerdo de Nivel de Servicio (SLA) compuesto general de la carga de trabajo. Toda la comunicación se realiza a través de la suscripción de conectividad. Hay otros recursos externos a los que puede llegar la carga de trabajo, pero no se consideran críticos.
Recursos de canalización de implementación
Las canalizaciones de compilación y versión de una aplicación crítica deben estar totalmente automatizadas para garantizar una manera coherente de implementar una marca validada. Estos recursos siguen siendo los mismos que la canalización de implementación de línea base.
Recursos de supervisión regional
Estos recursos residen en las suscripciones de zona de aterrizaje de la aplicación. Los datos de supervisión de recursos globales y recursos regionales se almacenan de forma independiente. Los servicios de Azure y su configuración siguen siendo los mismos que los recursos de supervisión de línea base.
En este artículo, consulte la sección Consideraciones de supervisión .
Recursos de administración
Para obtener acceso al clúster de proceso privado y a otros recursos, esta arquitectura usa agentes de compilación privados y instancias de máquinas virtuales jump box. Azure Bastion proporciona acceso seguro a los jumpboxes. Los recursos dentro de los stamps siguen siendo los mismos que los recursos de administración de línea base.
Consideraciones sobre redes
En este diseño, la carga de trabajo se implementa en la zona de aterrizaje de la aplicación y necesita conectividad con los recursos federados de la zona de aterrizaje de la plataforma. El propósito podría ser acceder a los recursos locales, controlar el tráfico de salida, etc.
Topología de red
El equipo de la plataforma decide la topología de red para toda la organización. En esta arquitectura se asume la topología en estrella tipo hub-spoke. Una alternativa podría ser Azure Virtual WAN.
Red virtual del centro regional
La suscripción de conectividad contiene una red virtual de concentrador con recursos, que comparten toda la organización. Estos recursos son propiedad del equipo de la plataforma y los mantiene.
Desde una perspectiva crítica, esta red no es efímera y estos recursos se encuentran en la ruta crítica.
| Recurso de Azure | Propósito |
|---|---|
| Azure ExpressRoute | Proporciona conectividad privada desde el entorno local a la infraestructura de Azure. |
| Azure Firewall | Actúa como la aplicación virtual de red que inspecciona y restringe el tráfico de salida. |
| DNS de Azure | Proporciona resolución de nombres entre locales. |
| VPN Gateway | Conecta las ramas de la organización remota a través de la red pública de Internet a la infraestructura de Azure. También actúa como alternativa de conectividad de copia de seguridad para agregar resistencia. |
Los recursos se aprovisionan en cada región y se emparejan con la red virtual de radio (se describe a continuación). Asegúrese de que comprende y acepta las actualizaciones de NVA, reglas de firewall, reglas de enrutamiento, conmutación por error de ExpressRoute a VPN Gateway, infraestructura DNS, etc.
Nota:
Una ventaja clave en el uso del centro federado es que la carga de trabajo se puede integrar con otras cargas de trabajo en Azure o entre locales mediante el recorrido de los centros de red administrados por la organización. Este cambio también reduce los costos operativos porque una parte de la responsabilidad se desplaza al equipo de la plataforma.
Red virtual de radio regional
La zona de aterrizaje de la aplicación tiene al menos dos redes virtuales de Azure previamente aprovisionadas, por región, a las que hacen referencia los sellos regionales. Estas redes no son efímeras. Uno atiende el tráfico de producción y el otro tiene como destino la implementación de vNext. Este enfoque le ofrece la capacidad de realizar prácticas de implementaciones confiables y seguras.
Red virtual de operaciones
El tráfico operativo está aislado en una red virtual independiente. Esta red virtual no es efímera y posee esta red. Esta arquitectura mantiene el mismo diseño que la arquitectura de línea base con controles de red.
No hay ningún emparejamiento entre la red de operaciones y la red de radio. Toda la comunicación es a través de Private Links.
Responsabilidades compartidas
Comprenda claramente qué equipo es responsable de cada elemento de diseño de la arquitectura. Estas son algunas áreas clave.
Planeamiento de direcciones IP
Después de estimar el tamaño necesario para ejecutar la carga de trabajo, trabaje con el equipo de la plataforma para que puedan aprovisionar la red correctamente.
Equipo de plataforma
Proporcione direcciones distintas para las redes virtuales que participan en emparejamientos. Las direcciones superpuestas, por ejemplo, de redes locales y de carga de trabajo, pueden provocar interrupciones que provocan interrupciones.
Asigne espacios de direcciones IP lo suficientemente grandes como para contener los recursos de tiempo de ejecución e implementaciones, controlar las conmutaciones por error y admitir la escalabilidad.
La red virtual y los emparejamientos previamente aprovisionados deben ser capaces de admitir el crecimiento esperado de la carga de trabajo. Debe evaluar ese crecimiento con el equipo de la plataforma con regularidad. Para más información, consulte Conectividad a Azure.
Subred de red de radio regional
Es responsable de asignar subredes en la red virtual regional. Las subredes y los recursos de ellos son efímeros. El espacio de direcciones debe ser lo suficientemente grande como para dar cabida al crecimiento potencial.
Subred de puntos de conexión privados Una vez que el tráfico llega a la red virtual, la comunicación con los servicios PaaS dentro de la red está restringida mediante puntos de conexión privados, al igual que la arquitectura de línea base con controles de red. Estos puntos de conexión se colocan en una subred dedicada. Las direcciones IP privadas a los puntos de conexión privados se asignan desde esa subred.
Subred del clúster Los requisitos de escalabilidad de la carga de trabajo influyen en la cantidad de espacio de direcciones que se debe asignar para las subredes. A medida que los nodos y pods de AKS se escalan horizontalmente, las direcciones IP se asignan desde esta subred.
Segmentación de red
Mantenga la segmentación adecuada para que la confiabilidad de la carga de trabajo no esté comprometida por el acceso no autorizado.
Esta arquitectura usa grupos de seguridad de red (NSG) para restringir el tráfico entre subredes y la suscripción de conectividad. Los grupos de seguridad de red usan ServiceTags para los servicios admitidos.
Equipo de plataforma
Aplique el uso de grupos de seguridad de red mediante directivas de Azure Network Manager.
Tenga en cuenta el diseño de la carga de trabajo. No hay tráfico directo entre los sellos. Tampoco hay flujos entre regiones. Si se necesitan esas rutas de acceso, el tráfico debe fluir a través de la suscripción de conectividad.
Evite que el tráfico de concentrador innecesario se origine desde otras cargas de trabajo en la carga de trabajo crítica.
Tráfico de salida de sellos regionales
Todo el tráfico saliente de cada red de radio regional se enruta a través de Azure Firewall centralizado en la red del centro regional. Actúa como el próximo salto que inspecciona y, a continuación, permite o deniega el tráfico.
Equipo de plataforma
Cree udR para esa ruta personalizada.
Asigne directivas de Azure que impedirán que el equipo de la aplicación cree subredes que no tengan la nueva tabla de rutas.
Conceda permisos adecuados de control de acceso basado en rol (RBAC) al equipo de la aplicación para que puedan ampliar las rutas en función de los requisitos de la carga de trabajo.
Redundancia de varias regiones
Las cargas de trabajo críticas deben implementarse en varias regiones para soportar interrupciones regionales. Trabaje con el equipo de plataforma para asegurarse de que la infraestructura sea confiable.
Equipo de plataforma
Implemente recursos de red centralizados por región. La metodología de diseño crítica requiere aislamiento regional.
Trabaje con el equipo de aplicaciones para descubrir dependencias regionales ocultas para que un recurso de plataforma degradado en una región no afecte a las cargas de trabajo de otra región.
Resolución DNS
La suscripción de conectividad proporciona zonas DNS privadas. Sin embargo, ese enfoque centralizado podría no tener en cuenta las necesidades de DNS que podrían ser específicas del caso de uso. Aprovisione sus propias zonas DNS y vincule a la marca regional. Si el equipo de la aplicación no es propietario de DNS, la administración de vínculos privados se convierte en un desafío para los recursos globales, como Azure Cosmos DB.
Equipo de plataforma
Delegue las zonas DNS privadas de Azure al equipo de la aplicación para cubrir sus casos de uso.
Para la red del centro regional, establezca el valor de los servidores DNS en Predeterminado (proporcionado por Azure) para admitir zonas DNS privadas administradas por el equipo de la aplicación.
Consideraciones sobre el diseño del entorno
Es una práctica general colocar cargas de trabajo en entornos independientes para producción, preproducción y desarrollo. Estas son algunas consideraciones clave.
¿Cómo se mantiene el aislamiento?
El entorno de producción debe estar aislado de otros entornos. Los entornos inferiores también deben mantener un nivel de aislamiento. Evite compartir recursos propiedad de la aplicación entre entornos.
Se requiere un entorno de producción para los recursos globales, regionales y de stamp que pertenecen al equipo de la aplicación. Los entornos de preproducción, como el almacenamiento provisional y la integración, son necesarios para asegurarse de que la aplicación se prueba en un entorno que simula la producción, tanto como sea posible. El entorno de desarrollo debe ser una versión vertical de producción.
¿Cuál es el ciclo de vida esperado?
Los entornos de preproducción se pueden destruir una vez completadas las pruebas de validación. Se recomienda que los entornos de desarrollo compartan la duración de una característica y se destruyan cuando se complete el desarrollo. Esas acciones realizadas por la automatización continua de integración/implementación continua (CI/CD).
¿Cuáles son los inconvenientes?
Tenga en cuenta los inconvenientes entre el aislamiento de los entornos, la complejidad de la administración y la optimización de costos.
Sugerencia
Todos los entornos deben tener dependencias en instancias de producción de recursos externos, incluidos los recursos de la plataforma. Por ejemplo, un centro regional de producción en la suscripción conectividad. Podrá minimizar la diferencia entre entornos de preproducción y producción.
Topología de suscripción para la infraestructura de carga de trabajo
El equipo de plataforma le ofrece suscripciones. En función del número de entornos, solicitará varias suscripciones para una sola carga de trabajo. En función del tipo de entorno, es posible que algunos entornos necesiten suscripciones dedicadas, mientras que otros entornos se pueden consolidar en una suscripción.
Independientemente, trabaje con el equipo de la plataforma para diseñar una topología que cumpla el objetivo general de confiabilidad de la carga de trabajo. Existe la ventaja de compartir los recursos proporcionados por la plataforma entre entornos de la misma suscripción, ya que reflejará el entorno de producción.
Nota:
El uso de varias suscripciones para contener los entornos puede lograr el nivel de aislamiento necesario. Las suscripciones de zona de aterrizaje se heredan del mismo grupo de administración. Por lo tanto, se garantiza la coherencia con la producción para pruebas y validación.
Suscripción de producción
Puede haber límites de recursos en la suscripción que se le haya proporcionado. Si coloca todos esos recursos en una suscripción, puede alcanzar esos límites. En función de las unidades de escalado y la escala esperada, considere un modelo más distribuido. Por ejemplo
Una suscripción que contiene los agentes de compilación de Azure DevOps y los recursos globales.
Una suscripción, por región. Contiene los recursos regionales, los recursos de sello y los cuadros de salto para los sellos regionales.
Esta es una topología de suscripción de ejemplo que se usa en esta arquitectura.
Suscripción de preproducción
Se requiere al menos una suscripción. Sin embargo, puede ejecutar muchos entornos independientes; sin embargo, se recomienda tener varios entornos en suscripciones dedicadas. Esta suscripción también puede estar sujeta a límites de recursos, como la suscripción de producción, descrita anteriormente.
Suscripción de desarrollo
Se requiere al menos una suscripción. Esta suscripción puede estar sujeta a límites de recursos si ejecuta todos los entornos independientes. Por lo tanto, puede solicitar varias suscripciones. Se recomienda tener entornos individuales en sus suscripciones dedicadas.
Intente hacer coincidir la topología de producción tanto como sea posible.
Consideraciones sobre la implementación
Las implementaciones con errores o las versiones erróneas son causas comunes de interrupciones de aplicaciones. Pruebe la aplicación (y las nuevas características) exhaustivamente como parte del ciclo de vida de la aplicación. Al implementar la carga de trabajo en una zona de aterrizaje, deberá integrar el diseño con los recursos y la gobernanza proporcionados por la plataforma.
Consulte: Cargas de trabajo críticas bien diseñadas: Implementación y pruebas.
Infraestructura de implementación
La confiabilidad de la infraestructura de implementación, como los agentes de compilación y su red, suele ser tan importante como los recursos en tiempo de ejecución de la carga de trabajo.
Esta arquitectura usa agentes de compilación privados para evitar el acceso no autorizado que puede afectar a la disponibilidad de la aplicación.
Se recomienda mantener el aislamiento entre los recursos de implementación. Una infraestructura de implementación debe enlazarse a las suscripciones de carga de trabajo para ese entorno. Si usa varios entornos en suscripciones de preproducción, cree una separación adicional limitando el acceso solo a esos entornos individuales. Los recursos de implementación por región se pueden considerar para que la infraestructura de implementación sea más confiable.
Implementación sin tiempo de inactividad
Las actualizaciones de la aplicación pueden provocar interrupciones. La aplicación de implementaciones coherentes aumentará la confiabilidad. Estos enfoques se recomiendan:
- Tener canalizaciones de implementación totalmente automatizadas.
- Implemente actualizaciones en entornos de preproducción en una marca limpia.
Para obtener más información, consulte Directrices de implementación y pruebas críticas.
En la arquitectura de línea de base, esas estrategias se implementan desaprovisionando y, a continuación, anulando el sello con cada actualización. En este diseño, no es posible realizar un aprovisionamiento completo porque el equipo de la plataforma posee algunos recursos. Por lo tanto, se cambió el modelo de implementación.
Modelo de implementación
La arquitectura de línea base usa Blue-Green modelo para implementar actualizaciones de aplicaciones. Los nuevos sellos con cambios se implementan junto con los sellos existentes. Después de mover el tráfico a la nueva marca, se destruye la marca existente.
En este caso, la red virtual emparejada especificada no es efímera. No se permite que la marca cree la red virtual ni el emparejamiento en el centro regional. Tendrá que reutilizar esos recursos en cada implementación.
El modelo controlado puede lograr una implementación segura con la opción de revertir. En primer lugar, se implementa una nueva marca con cambios de código. La canalización de implementación hace referencia a la red virtual aprovisionada previamente y asigna subredes, implementa recursos, agrega puntos de conexión privados. A continuación, desplaza el tráfico a estas subredes en esta red virtual aprovisionada previamente.
Cuando ya no se requiere la marca existente, la canalización elimina todos los recursos de stamp, excepto los recursos propiedad de la plataforma. Se conservan la red virtual, la configuración de diagnóstico, el emparejamiento, el espacio de direcciones IP, la configuración de DNS y el control de acceso basado en rol (RBAC). En este momento, la marca está en un estado limpio y está lista para la siguiente implementación nueva.
Directivas de Azure de DINE (deploy-if-not-exists)
Las zonas de aterrizaje de aplicaciones de Azure pueden tener directivas de Azure DINE (deploy-if-not-exists). Estas comprobaciones garantizan que los recursos implementados cumplen los estándares corporativos en las zonas de aterrizaje de aplicaciones, incluso cuando son propiedad del equipo de la aplicación. Es posible que haya una discrepancia entre la implementación y la configuración final de los recursos.
Comprenda el impacto de todas las directivas DINE que se aplicarán a los recursos. Si hay cambios en la configuración de recursos, incorpore la intención de las directivas en las implementaciones declarativas al principio del ciclo de desarrollo de la carga de trabajo. De lo contrario, puede haber un desfase que conduce a delta entre el estado deseado y el estado implementado.
Administración de acceso de suscripción de implementación
Trate los límites de la suscripción como límites de seguridad para limitar el radio de explosión. Las amenazas pueden afectar a la confiabilidad de la carga de trabajo.
Equipo de plataforma
- Asigne a los equipos de aplicación autorización para las operaciones con permisos con ámbito de la suscripción a la zona de aterrizaje de la aplicación.
Si ejecuta varias implementaciones dentro de una sola suscripción, una infracción afectará a ambas implementaciones. Se recomienda ejecutar implementaciones en suscripciones dedicadas. Cree entidades de servicio por entorno para mantener la separación lógica.
La entidad de servicio debe proporcionar autonomía sobre los recursos de carga de trabajo. Además, debe tener restricciones que impidan la manipulación excesiva de los recursos de la plataforma dentro de la suscripción.
Consideraciones sobre supervisión
La plataforma de zona de aterrizaje de Azure proporciona recursos de observabilidad compartidos como parte de las suscripciones de administración. El equipo de operaciones centralizado anima a los equipos de aplicación a usar el modelo federado. Pero en el caso de las cargas de trabajo críticas, no se recomienda un único almacén de observabilidad centralizado porque puede ser un único punto de error. Las cargas de trabajo críticas también generan telemetría que podrían no ser aplicables o accionables para los equipos de operaciones centralizados.
Por lo tanto, se recomienda encarecidamente un enfoque autónomo para la supervisión. Los operadores de carga de trabajo son, en última instancia, responsables de la supervisión y deben tener acceso a todos los datos que representan el estado general.
La arquitectura de línea base sigue ese enfoque y continúa en esta arquitectura de referencia. Azure Log Analytics y Azure Application Insights se implementan de forma regional y global para supervisar los recursos de esos ámbitos. La agregación de registros, la creación de paneles y las alertas está en el ámbito del equipo. Aproveche las funcionalidades de Diagnóstico de Azure que envían métricas y registros a varios receptores para admitir los requisitos de la plataforma para la recopilación de métricas y registros.
Modelo de mantenimiento
La metodología de diseño crítica requiere un modelo de mantenimiento del sistema. Cuando se define una puntuación de estado general, incluya flujos de zona de aterrizaje de la plataforma en el ámbito de los que depende la aplicación. Compile consultas de registro, estado y alertas para realizar la supervisión entre áreas de trabajo.
Equipo de plataforma
Conceda consultas de control de acceso basado en rol (RBAC) y lea receptores de registro para los recursos de plataforma pertinentes que se usan en la ruta crítica de la aplicación crítica.
Admita el objetivo organizativo de confiabilidad hacia la carga de trabajo crítica al conceder al equipo de la aplicación permiso suficiente para realizar sus operaciones.
En esta arquitectura, el modelo de mantenimiento incluye registros y métricas de los recursos aprovisionados en la suscripción de conectividad. Si extiende este diseño para llegar a un recurso local, como una base de datos, el modelo de mantenimiento debe incluir conectividad de red a ese recurso, incluidos los límites de seguridad, como las aplicaciones virtuales de red en Azure y el entorno local. Esta información es importante para determinar rápidamente la causa principal y corregir el impacto en la confiabilidad. Por ejemplo, ¿se produjo el error al intentar enrutar a la base de datos o se produjo un problema con la base de datos?
Consulte: Cargas de trabajo críticas bien diseñadas: Modelado de estado.
Integración con las reglas y directivas proporcionadas por la plataforma
La suscripción a la zona de aterrizaje de la aplicación hereda las directivas de Azure, las reglas de Azure Network Manager y otros controles de su grupo de administración. El equipo de la plataforma proporciona esos límites de protección.
En el caso de las implementaciones, no dependa exclusivamente de las directivas proporcionadas por la plataforma, ya que:
- No están diseñados para cubrir las necesidades de las cargas de trabajo individuales.
- Las directivas y reglas pueden actualizarse o quitarse fuera de su equipo, por lo que pueden afectar a la confiabilidad.
Se recomienda encarecidamente crear y asignar directivas de Azure dentro de las implementaciones. Este esfuerzo podría provocar cierta duplicación, pero eso es aceptable, teniendo en cuenta el posible impacto en la confiabilidad del sistema. Si hay cambios en las directivas de la plataforma, las directivas de carga de trabajo seguirán en vigor localmente.
Equipo de plataforma
- Implique al equipo de aplicaciones en el proceso de administración de cambios de las directivas a medida que evolucionan.
- Tenga en cuenta las directivas que usa el equipo de la aplicación. Evalúe si se deben agregar al grupo de administración.
Implementación de esta arquitectura
Los aspectos de red de esta arquitectura se implementan en la implementación conectada crítica.
Nota:
La implementación conectada está pensada para ilustrar una carga de trabajo crítica que se basa en los recursos de la organización, se integra con otras cargas de trabajo y usa servicios compartidos. La implementación supone que ya existe una suscripción de conectividad.
Pasos siguientes
Revise el área de diseño de redes y conectividad en Azure Well-architected Framework.
Recursos relacionados
Además de los servicios de Azure usados en la arquitectura de línea base, estos servicios son importantes para esta arquitectura.