Arquitetura de linha de base crítica em uma zona de destino do Azure
Essa arquitetura de referência fornece diretrizes para implantar uma carga de trabalho crítica que usa serviços compartilhados centralizados, precisa de conectividade local e integra-se a outras cargas de trabalho de uma empresa. Essa orientação destina-se a um proprietário de carga de trabalho que faz parte de uma equipe de aplicativos na organização.
Você pode se encontrar nessa situação quando sua organização quiser implantar a carga de trabalho em uma zona de destino do aplicativo do Azure que herda o grupo de gerenciamento corp. Espera-se que a carga de trabalho se integre aos recursos compartilhados pré-provisionados na zona de destino da plataforma do Azure que são gerenciados por equipes centralizadas.
Importante
O que é uma zona de destino do Azure? Uma zona de destino do aplicativo é uma assinatura do Azure na qual a carga de trabalho é executada. Ele está conectado aos recursos compartilhados da organização. Por meio dessa conexão, ele tem acesso à infraestrutura básica necessária para executar a carga de trabalho, como rede, gerenciamento de acesso de identidade, políticas e monitoramento. As zonas de destino da plataforma são uma coleção de várias assinaturas, cada uma com uma função específica. Por exemplo, a assinatura conectividade fornece resolução DNS centralizada, conectividade local e NVAs (dispositivos virtuais de rede) disponíveis para uso pelas equipes de aplicativos.
Como proprietário de uma carga de trabalho, você se beneficia descarregando o gerenciamento de recursos compartilhados para equipes centrais e se concentra nos esforços de desenvolvimento de carga de trabalho. A organização se beneficia aplicando governança consistente e amortizando custos em várias cargas de trabalho.
É altamente recomendável que você entenda o conceito de zonas de destino do Azure.
Nessa abordagem, a confiabilidade máxima é uma responsabilidade compartilhada entre você e a equipe da plataforma. Os componentes gerenciados centralmente precisam ser altamente confiáveis para que uma carga de trabalho crítica opere conforme o esperado. Você deve ter uma relação confiável com a equipe de plataforma para que os problemas de indisponibilidade nos serviços centralizados, que afetam a carga de trabalho, sejam mitigados no nível da plataforma. Porém, sua equipe é responsável por gerar requisitos com a equipe de plataforma para atingir seus destinos.
Essa arquitetura se baseia na arquitetura de linha de base crítica com controles de rede. É recomendável que você se familiarize com a arquitetura de linha de base antes de prosseguir com este artigo.
Observação
As diretrizes são apoiadas por uma implementação de exemplo de nível de produção que mostra o desenvolvimento de aplicativos críticos no Azure. Essa implementação pode ser usada como base para o desenvolvimento de soluções como seu primeiro passo para a produção.
Estratégias-chave de design
Aplique estas estratégias sobre a linha de base crítica da missão:
Caminho crítico
Nem todos os componentes da arquitetura precisam ser igualmente confiáveis. O caminho crítico inclui os componentes que devem ser mantidos funcionais para que a carga de trabalho não experimente nenhum tempo de inatividade ou desempenho degradado. Manter esse caminho magro minimizará os pontos de falha.
Ciclo de vida de componentes
Considere o ciclo de vida de componentes críticos porque ele tem um impacto em sua meta de atingir um tempo de inatividade próximo de zero. Os componentes podem ser recursos efêmeros ou de curta duração que podem ser criados e destruídos conforme necessário; recursos não efêmeros ou de longa duração que compartilham o tempo de vida com o sistema ou a região.
Dependências externas
Minimize as dependências externas em componentes e processos, o que pode introduzir pontos de falha. A arquitetura tem recursos pertencentes a várias equipes fora de sua equipe. Esses componentes (se críticos) estão no escopo dessa arquitetura.
Topologia de assinatura
As zonas de destino do Azure não implicam uma única topologia de assinatura. Planeje seu volume de assinatura com antecedência com sua equipe de plataforma para acomodar os requisitos de confiabilidade da carga de trabalho em todos os ambientes.
Observabilidade autônoma no caminho crítico
Tenha recursos de monitoramento dedicados que permitem à equipe consultar rapidamente sua coleta de dados (especialmente o caminho crítico) e agir sobre correções.
Arquitetura
Baixe um arquivo do Visio dessa arquitetura.
Os componentes dessa arquitetura são iguais à arquitetura de linha de base crítica com controles de rede. As descrições são curtas para a brevidade. Se você precisar de mais informações, consulte os artigos vinculados. Para obter a documentação do produto sobre os serviços do Azure, consulte Recursos relacionados.
Recursos globais
Esses recursos residem nas assinaturas da zona de destino do aplicativo. Os recursos globais não são efêmeros e compartilham o tempo de vida do sistema. Os serviços do Azure e sua configuração permanecem os mesmos que os recursos globais de linha de base.
Recursos de rede regionais
Esses recursos residem nas assinaturas da zona de destino da plataforma e nas assinaturas da zona de destino do aplicativo. A arquitetura de linha de base implanta todos os recursos pertencentes a você. No entanto, nessa arquitetura, os recursos de rede são fornecidos por meio da assinatura conectividade são provisionados como parte da zona de destino da plataforma.
Neste artigo, consulte a seção De rede virtual do hub regional .
Recursos de selo regional
Esses recursos residem nas assinaturas da zona de destino do aplicativo. Esses recursos não compartilham nada com outros recursos, exceto os recursos globais.
A maioria dos serviços do Azure e sua configuração permanecem iguais à arquitetura de selo de linha de base, exceto para os recursos de rede, que são pré-provisionados pela equipe de plataforma.
Neste artigo, consulte a seção De rede virtual de spoke regional .
Recursos externos
A carga de trabalho interage com recursos locais. Alguns deles estão no caminho crítico para a carga de trabalho, por exemplo, um banco de dados local. Esses recursos e a comunicação com eles são levados em conta no SLA (Contrato de Nível de Serviço) composto geral da carga de trabalho. Toda a comunicação é por meio da assinatura conectividade. Há outros recursos externos que a carga de trabalho pode alcançar, mas eles não são considerados críticos.
Recursos de pipeline de implantação
Os pipelines de build e lançamento de um aplicativo crítico devem ser totalmente automatizados para garantir uma maneira consistente de implantar um carimbo validado. Esses recursos permanecem os mesmos que o pipeline de implantação de linha de base.
Recursos de monitoramento regional
Esses recursos residem nas assinaturas da zona de destino do aplicativo. Os dados de monitoramento de recursos globais e recursos regionais são armazenados de forma independente. Os serviços do Azure e sua configuração permanecem os mesmos que os recursos de monitoramento de linha de base.
Neste artigo, consulte a seção Considerações sobre monitoramento.
Recursos de gerenciamento
Para obter acesso ao cluster de computação privada e a outros recursos, essa arquitetura usa agentes de build privados e instâncias de máquinas virtuais jump box. O Azure Bastion fornece acesso seguro às caixas de salto. Os recursos dentro dos selos permanecem os mesmos que os recursos de gerenciamento de linha de base.
Considerações sobre rede
Nesse design, a carga de trabalho é implantada na zona de destino do aplicativo e precisa de conectividade com os recursos federados na zona de destino da plataforma. A finalidade pode ser acessar recursos locais, controlar o tráfego de saída e assim por diante.
Topologia de rede
A equipe de plataforma decide a topologia de rede para toda a organização. A topologia hub-spoke é assumida nessa arquitetura. Uma alternativa pode ser a WAN Virtual do Azure.
Rede virtual do hub regional
A assinatura de conectividade contém uma rede virtual de hub com recursos, que são compartilhados por toda a organização. Esses recursos são de propriedade e mantidos pela equipe de plataforma.
De uma perspectiva crítica, essa rede não é efêmera e esses recursos estão no caminho crítico.
| Recursos do Azure | Propósito |
|---|---|
| Azure ExpressRoute | Fornece conectividade privada do local para a infraestrutura do Azure. |
| Firewall do Azure | Atua como a NVA que inspeciona e restringe o tráfego de saída. |
| DNS do Azure | Fornece resolução de nomes entre locais. |
| Gateway de VPN | Conecta branches de organização remota pela Internet pública à infraestrutura do Azure. Também atua como uma alternativa de conectividade de backup para adicionar resiliência. |
Os recursos são provisionados em cada região e emparelhados com a rede virtual spoke (descrito em seguida). Certifique-se de entender e concordar com as atualizações de NVA, regras de firewall, regras de roteamento, failover do ExpressRoute para o Gateway de VPN, infraestrutura DNS e assim por diante.
Observação
Um benefício fundamental no uso do hub federado é que a carga de trabalho pode se integrar a outras cargas de trabalho no Azure ou entre locais, percorrendo os hubs de rede gerenciados pela organização. Essa alteração também reduz seus custos operacionais porque uma parte da responsabilidade é deslocada para a equipe de plataforma.
Rede virtual de spoke regional
A zona de destino do aplicativo tem pelo menos duas Redes Virtuais do Azure pré-provisionadas, por região, que são referenciadas pelos selos regionais. Essas redes não são efêmeras. Um serve o tráfego de produção e o outro tem como destino a implantação do vNext. Essa abordagem oferece a capacidade de executar práticas de implantações confiáveis e seguras.
Rede virtual de operações
O tráfego operacional é isolado em uma rede virtual separada. Essa rede virtual não é efêmera e você é proprietário dessa rede. Essa arquitetura mantém o mesmo design da arquitetura de linha de base com controles de rede.
Não há emparelhamento entre a rede de operações e a rede spoke. Toda a comunicação é por meio de Links Privados.
Responsabilidades compartilhadas
Tenha uma compreensão clara de qual equipe é responsável por cada elemento de design da arquitetura. Aqui estão algumas áreas-chave.
Planejamento de endereço IP
Depois de estimar o tamanho necessário para executar sua carga de trabalho, trabalhe com a equipe de plataforma para que ela possa provisionar a rede adequadamente.
Equipe de plataforma
Forneça endereços distintos para redes virtuais que participam de emparelhamentos. Endereços sobrepostos, por exemplo, redes locais e de carga de trabalho, podem causar interrupções que levam à interrupção.
Aloque espaços de endereço IP grandes o suficiente para conter os recursos de runtime e implantações, lidar com failovers e dar suporte à escalabilidade.
A rede virtual pré-provisionada e os emparelhamentos devem ser capazes de dar suporte ao crescimento esperado da carga de trabalho. Você deve avaliar esse crescimento com a equipe de plataforma regularmente. Para obter mais informações, consulte Conectividade com o Azure.
Sub-rede de rede de spoke regional
Você é responsável por alocar sub-redes na rede virtual regional. As sub-redes e os recursos nelas são efêmeros. O espaço de endereço deve ser grande o suficiente para acomodar o crescimento potencial.
Sub-rede de pontos de extremidade privados Depois que o tráfego atinge a rede virtual, a comunicação com os serviços de PaaS na rede é restrita usando pontos de extremidade privados, assim como a arquitetura de linha de base com controles de rede. Esses pontos de extremidade são colocados em uma sub-rede dedicada. Os endereços IP privados para os pontos de extremidade privados são atribuídos a partir dessa sub-rede.
Sub-rede do cluster Os requisitos de escalabilidade da carga de trabalho influenciam a quantidade de espaço de endereço que deve ser alocada para as sub-redes. À medida que os nós e pods do AKS são escalados horizontalmente, os endereços IP são atribuídos a partir dessa sub-rede.
Segmentação de rede
Mantenha a segmentação adequada para que a confiabilidade da carga de trabalho não seja comprometida pelo acesso não autorizado.
Essa arquitetura usa NSGs (Grupos de Segurança de Rede) para restringir o tráfego entre sub-redes e a assinatura conectividade. Os NSGs usam ServiceTags para os serviços com suporte.
Equipe de plataforma
Imponha o uso de NSGs por meio de Políticas do Gerenciador de Rede do Azure.
Esteja ciente do design da carga de trabalho. Não há tráfego direto entre os selos. Além disso, não há fluxos entre regiões. Se esses caminhos forem necessários, o tráfego deverá fluir pela assinatura conectividade.
Impedir que o tráfego de hub desnecessário seja originado de outras cargas de trabalho na carga de trabalho crítica da missão.
Tráfego de saída de selos regionais
Todo o tráfego de saída de cada rede de spoke regional é roteado por meio do Firewall centralizado do Azure na rede de hub regional. Ele atua como o próximo salto que inspeciona e, em seguida, permite ou nega o tráfego.
Equipe de plataforma
Crie UDRs para essa rota personalizada.
Atribua políticas do Azure que impedirão a equipe de aplicativos de criar sub-redes que não tenham a nova tabela de rotas.
Conceda permissões de RBAC (controle de acesso baseado em função) adequadas à equipe de aplicativos para que eles possam estender as rotas com base nos requisitos da carga de trabalho.
Redundância de várias regiões
Suas cargas de trabalho críticas devem ser implantadas em várias regiões para suportar interrupções regionais. Trabalhe com a equipe de plataforma para garantir que a infraestrutura seja confiável.
Equipe de plataforma
Implantar recursos de rede centralizados por região. A metodologia de design crítico requer isolamento regional.
Trabalhe com a equipe de aplicativos para descobrir dependências regionais ocultas para que um recurso de plataforma degradado em uma região não afete cargas de trabalho em outra região.
Resolução DNS
A assinatura de conectividade fornece zonas DNS privadas. No entanto, essa abordagem centralizada pode não levar em conta as necessidades de DNS que podem ser específicas para seu caso de uso. Provisione suas próprias zonas DNS e vincule-se ao carimbo regional. Se a equipe de aplicativos não possui DNS, o gerenciamento de links privados torna-se desafiador para recursos globais, como o Azure Cosmos DB.
Equipe de plataforma
Delegar as zonas DNS privadas do Azure à equipe de aplicativos para cobrir seus casos de uso.
Para a rede de hub regional, defina o valor dos servidores DNS como Padrão (fornecido pelo Azure) para dar suporte a zonas DNS privadas gerenciadas pela equipe de aplicativos.
Considerações sobre design de ambiente
É uma prática geral colocar cargas de trabalho em ambientes separados para produção, pré-produção e desenvolvimento. Aqui estão algumas considerações importantes.
Como o isolamento é mantido?
O ambiente de produção deve ser isolado de outros ambientes. Ambientes inferiores também devem manter um nível de isolamento. Evite compartilhar recursos de propriedade do aplicativo entre ambientes.
Um ambiente de produção é necessário para recursos globais, regionais e de carimbo de propriedade da equipe de aplicativos. Ambientes de pré-produção, como preparo e integração, são necessários para garantir que o aplicativo seja testado em um ambiente que simule a produção, o máximo possível. O ambiente de desenvolvimento deve ser uma versão horizontal da produção.
Qual é o ciclo de vida esperado?
Os ambientes de pré-produção podem ser destruídos após a conclusão dos testes de validação. É recomendável que os ambientes de desenvolvimento compartilhem o tempo de vida de um recurso e sejam destruídos quando o desenvolvimento for concluído. Essas ações feitas pela automação de CI/CD (integração contínua/implantação contínua).
Quais são as desvantagens?
Considere as compensações entre o isolamento de ambientes, a complexidade do gerenciamento e a otimização de custos.
Dica
Todos os ambientes devem assumir dependências em instâncias de produção de recursos externos, incluindo recursos de plataforma. Por exemplo, um hub regional de produção na assinatura conectividade. Você poderá minimizar o delta entre ambientes de pré-produção e produção.
Topologia de assinatura para infraestrutura de carga de trabalho
As assinaturas são fornecidas a você pela equipe da plataforma. Dependendo do número de ambientes, você solicitará várias assinaturas para apenas uma carga de trabalho. Dependendo do tipo de ambiente, alguns ambientes podem precisar de assinaturas dedicadas, enquanto outros ambientes podem ser consolidados em uma assinatura.
Independentemente disso, trabalhe com a equipe de plataforma para criar uma topologia que atenda ao destino de confiabilidade geral da carga de trabalho. Há um benefício em compartilhar os recursos fornecidos pela plataforma entre ambientes na mesma assinatura, pois isso refletirá o ambiente de produção.
Observação
O uso de várias assinaturas para conter os ambientes pode atingir o nível necessário de isolamento. As assinaturas da zona de destino são herdadas do mesmo grupo de gerenciamento. Portanto, a consistência com a produção é assegurada para teste e validação.
Assinatura de produção
Pode haver limites de recursos na assinatura fornecida a você. Se você colocar todos esses recursos em uma assinatura, poderá atingir esses limites. Com base nas unidades de escala e na escala esperada, considere um modelo mais distribuído. Por exemplo
Uma assinatura que contém agentes de build do Azure DevOps e recursos globais.
Uma assinatura, por região. Ele contém os recursos regionais, os recursos de carimbo e as caixas de salto para os selos regionais.
Aqui está uma topologia de assinatura de exemplo usada nesta arquitetura.
Assinatura de pré-produção
Pelo menos uma assinatura é necessária. Ele pode executar muitos ambientes independentes, no entanto, é recomendável ter vários ambientes em assinaturas dedicadas. Essa assinatura também pode estar sujeita a limites de recursos, como a assinatura de produção, descrita acima.
Assinatura de desenvolvimento
Pelo menos uma assinatura é necessária. Essa assinatura poderá estar sujeita a limites de recursos se executar todos os ambientes independentes. Portanto, você pode solicitar várias assinaturas. É recomendável ter ambientes individuais em suas assinaturas dedicadas.
Tente corresponder à topologia de produção o máximo possível.
Considerações sobre implantação
Implantações com falha ou versões errôneas são causas comuns para interrupções de aplicativo. Teste seu aplicativo (e novos recursos) completamente como parte do ciclo de vida do aplicativo. Ao implantar a carga de trabalho em uma zona de destino, você precisará integrar seu design aos recursos e à governança fornecidos pela plataforma.
Consulte: Cargas de trabalho críticas de missão bem arquiteta: implantação e teste.
Infraestrutura de implantação
A confiabilidade da infraestrutura de implantação, como agentes de build e sua rede, geralmente é tão importante quanto os recursos de runtime da carga de trabalho.
Essa arquitetura usa agentes de build privados para impedir o acesso não autorizado que pode afetar a disponibilidade do aplicativo.
É altamente recomendável manter o isolamento entre os recursos de implantação. Uma infraestrutura de implantação deve ser associada às suas assinaturas de carga de trabalho para esse ambiente. Se você estiver usando vários ambientes em assinaturas de pré-produção, crie uma separação adicional limitando o acesso a apenas esses ambientes individuais. Os recursos de implantação por região podem ser considerados para tornar a infraestrutura de implantação mais confiável.
Implantação de tempo de inatividade zero
As atualizações no aplicativo podem causar interrupções. A imposição de implantações consistentes aumentará a confiabilidade. Essas abordagens são recomendadas:
- Tenha pipelines de implantação totalmente automatizados.
- Implante atualizações em ambientes de pré-produção em um carimbo limpo.
Para obter mais informações, consulte diretrizes de teste e implantação críticas.
Na arquitetura de linha de base, essas estratégias são implementadas desprovisionando e, em seguida, derrubando o carimbo a cada atualização. Nesse design, não é possível desprovisionar completamente porque a equipe de plataforma possui alguns recursos. Portanto, o modelo de implantação foi alterado.
Modelo de implementação
A arquitetura de linha de base usa Blue-Green modelo para implantar atualizações de aplicativos. Novos selos com alterações são implantados junto com os selos existentes. Depois que o tráfego é movido para o novo carimbo, o carimbo existente é destruído.
Nesse caso, a rede virtual emparelhada fornecida não é efêmera. O carimbo não tem permissão para criar a rede virtual ou emparelhamento com o hub regional. Você precisará reutilizar esses recursos em cada implantação.
O modelo canário pode obter uma implantação segura com a opção de reverter. Primeiro, um novo carimbo é implantado com alterações de código. O pipeline de implantação faz referência à rede virtual pré-provisionada e aloca sub-redes, implanta recursos e adiciona pontos de extremidade privados. Em seguida, ele desloca o tráfego para essas sub-redes nessa rede virtual pré-provisionada.
Quando o carimbo existente não é mais necessário, todos os recursos de selo são excluídos pelo pipeline, exceto para os recursos de propriedade da plataforma. A rede virtual, as configurações de diagnóstico, o emparelhamento, o espaço de endereço IP, a configuração de DNS e o RBAC (controle de acesso baseado em função) são preservados. Neste ponto, o carimbo está em um estado limpo e pronto para a próxima nova implantação.
Políticas do Azure DINE (deploy-if-not-exists)
As zonas de destino do aplicativo do Azure podem ter políticas do Azure DINE (deploy-if-not-exists). Essas verificações garantem que os recursos implantados atendam aos padrões corporativos nas zonas de destino do aplicativo, mesmo quando pertencem à equipe de aplicativos. Pode haver uma incompatibilidade entre a implantação e a configuração final do recurso.
Entenda o impacto de todas as políticas DINE que serão aplicadas aos seus recursos. Se houver alterações na configuração de recursos, incorpore a intenção das políticas em suas implantações declarativas no início do ciclo de desenvolvimento da carga de trabalho. Caso contrário, pode haver uma descompasso que leva ao delta entre o estado desejado e o estado implantado.
Gerenciamento de acesso à assinatura de implantação
Trate os limites de assinatura como seus limites de segurança para limitar o raio de explosão. As ameaças podem afetar a confiabilidade da carga de trabalho.
Equipe de plataforma
- Conceda às equipes de aplicativos autorização para operações com permissões no escopo da assinatura da zona de destino do aplicativo.
Se você estiver executando várias implantações em uma única assinatura, uma violação afetará ambas as implantações. É recomendável executar implantações em assinaturas dedicadas. Crie entidades de serviço por ambiente para manter a separação lógica.
A entidade de serviço deve fornecer autonomia sobre os recursos de carga de trabalho. Além disso, ele deve ter restrições em vigor que impedirão a manipulação excessiva dos recursos da plataforma dentro da assinatura.
Considerações de monitoramento
A plataforma de zona de destino do Azure fornece recursos de observabilidade compartilhados como parte das assinaturas de Gerenciamento. A equipe de operações centralizada incentiva as equipes de aplicativos a usar o modelo federado. No entanto, para cargas de trabalho críticas, um único repositório de observabilidade centralizado não é recomendado porque pode ser um único ponto de falha. Cargas de trabalho críticas também geram telemetria que pode não ser aplicável ou acionável para equipes de operações centralizadas.
Portanto, uma abordagem autônoma para monitoramento é altamente recomendada. Os operadores de carga de trabalho são, em última análise, responsáveis pelo monitoramento e devem ter acesso a todos os dados que representam a integridade geral.
A arquitetura de linha de base segue essa abordagem e continua nessa arquitetura de referência. O Azure Log Analytics e o Azure Application Insights são implantados regional e globalmente para monitorar recursos nesses escopos. Agregar logs, criar dashboards e alertas está no escopo da sua equipe. Aproveite os recursos do Diagnóstico do Azure que enviam métricas e logs para vários coletores para dar suporte aos requisitos da plataforma para coleta de logs e métricas.
Modelo de integridade
A metodologia de design crítico exige um modelo de integridade do sistema. Quando você estiver definindo uma pontuação geral de integridade, inclua fluxos de zona de destino da plataforma no escopo dos quais o aplicativo depende. Crie consultas de log, integridade e alerta para executar o monitoramento entre workspaces.
Equipe de plataforma
Conceda a consulta RBAC (controle de acesso baseado em função) e os coletores de log de leitura para recursos de plataforma relevantes que são usados no caminho crítico do aplicativo crítico.
Dê suporte à meta organizacional de confiabilidade para a carga de trabalho crítica, dando à equipe de aplicativos permissão suficiente para executar suas operações.
Nessa arquitetura, o modelo de integridade inclui logs e métricas de recursos provisionados na assinatura conectividade. Se você estender esse design para alcançar um recurso local, como um banco de dados, o modelo de integridade deverá incluir conectividade de rede com esse recurso, incluindo limites de segurança, como dispositivos virtuais de rede no Azure e no local. Essas informações são importantes para determinar rapidamente a causa raiz e corrigir o impacto da confiabilidade. Por exemplo, a falha ocorreu ao tentar rotear para o banco de dados ou houve um problema com o banco de dados?
Consulte: Cargas de trabalho de missão crítica bem arquitetas: modelagem de integridade.
Integração com as políticas e regras fornecidas pela plataforma
A assinatura da zona de destino do aplicativo herda as políticas do Azure, as regras do Azure Network Manager e outros controles de seu grupo de gerenciamento. A equipe de plataforma fornece esses guardrails.
Para implantações, não dependa exclusivamente das políticas fornecidas pela plataforma, pois:
- Eles não são design para cobrir as necessidades de cargas de trabalho individuais.
- As políticas e as regras podem ser atualizadas ou removidas fora de sua equipe e, portanto, podem afetar a confiabilidade.
É altamente recomendável que você crie e atribua políticas do Azure em suas implantações. Esse esforço pode levar a alguma duplicação, mas isso é aceitável, considerando o potencial impacto na confiabilidade do sistema. Se houver alterações nas políticas de plataforma, as políticas de carga de trabalho ainda estarão em vigor localmente.
Equipe de plataforma
- Envolva a equipe de aplicativos no processo de gerenciamento de alterações das políticas conforme elas evoluem.
- Esteja ciente das políticas usadas pela equipe de aplicativos. Avalie se eles devem ser adicionados ao grupo de gerenciamento.
Implantar essa arquitetura
Os aspectos de rede dessa arquitetura são implementados na implementação conectada crítica da missão.
Observação
A implementação conectada destina-se a ilustrar uma carga de trabalho crítica que depende de recursos organizacionais, integra-se a outras cargas de trabalho e usa serviços compartilhados. A implementação pressupõe que já exista uma assinatura de Conectividade.
Próximas etapas
Examine a área de design de rede e conectividade no Azure Well-architected Framework.
Recursos relacionados
Além dos serviços do Azure usados na arquitetura de linha de base, esses serviços são importantes para essa arquitetura.