Essa arquitetura de referência fornece orientação para implantar uma carga de trabalho de missão crítica que usa serviços compartilhados centralizados, precisa de conectividade local e se integra a outras cargas de trabalho de uma empresa. Esta 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 de aplicativo do Azure que herda o grupo de gerenciamento da Corp. Espera-se que a carga de trabalho se integre a recursos compartilhados pré-provisionados na zona de destino da plataforma Azure que são gerenciados por equipes centralizadas.
Importante
O que é uma zona de destino do Azure? Uma zona de destino de aplicativo é uma assinatura do Azure em que executamos uma carga de trabalho. Ela está conectada aos recursos compartilhados da organização. Por meio dessa conexão, ela 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 é uma coleção de várias assinaturas, cada qual com uma função específica. Por exemplo, a assinatura Conectividade fornece resolução DNS centralizada, conectividade local e dispositivos virtuais de rede (NVAs) que estão disponíveis para uso por equipes de aplicativos.
Como proprietário de carga de trabalho, você se beneficia ao transferir o gerenciamento de recursos compartilhados para equipes centrais e se concentra nos esforços de desenvolvimento da carga de trabalho. A organização beneficia-se aplicando uma 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 máxima confiabilidade é 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 de missão crítica opere conforme o esperado. Você deve ter um relacionamento confiável com a equipe da plataforma para que os problemas de indisponibilidade nos serviços centralizados que afetam a carga de trabalho sejam atenuados no nível da plataforma. Mas sua equipe é responsável por verificar os requisitos com a equipe da plataforma para atingir suas metas.
Essa arquitetura se baseia na arquitetura de linha de base de missão 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
A orientação é apoiada por uma implementação de exemplo no nível de produção que mostra o desenvolvimento de aplicativos de missão crítica no Azure. Essa implementação pode ser usada como base para o desenvolvimento de soluções adicionais na sua primeira etapa para produção.
Principais estratégias de design
Aplique estas estratégias sobre a linha de base de missão crítica:
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 sofra nenhum tempo de inatividade ou degradação de desempenho. Manter esse caminho livre minimizará os pontos de falha.
Ciclo de vida dos componentes
Considere o ciclo de vida dos componentes críticos, pois ele tem um impacto na 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 região.
Dependências externas
Minimize dependências externas em componentes e processos, porque isso pode introduzir pontos de falha. A arquitetura tem recursos pertencentes a várias equipes fora da 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 topologia de assinatura única. Planeje seu espaço 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 permitam que a equipe verifique rapidamente a coleta de dados (especialmente o caminho crítico) e trabalhe em correções.
Arquitetura
Baixe um Arquivo Visio dessa arquitetura.
Os componentes dessa arquitetura são os mesmos da arquitetura de linha de base de missão crítica com controles de rede. As descrições são curtas para 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 os Recursos relacionados.
Recursos globais
Esses recursos estão ligados à(s) assinatura(s) 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 a configuração deles permanecem os mesmos que os recursos globais de linha de base.
Recursos de rede regional
Esses recursos estão ligados às assinaturas da zona de destino da plataforma e na(s) assinatura(s) da zona de destino do aplicativo. A arquitetura de linha de base implanta todos os recursos de sua propriedade. No entanto, nessa arquitetura, os recursos de rede fornecidos por meio da assinatura de conectividade são provisionados como parte da zona de destino da plataforma.
Neste artigo, consulte a seção Rede virtual de hub regional.
Recursos de carimbo regionais
Esses recursos estão ligados à(s) assinatura(s) 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 a configuração deles permanecem iguais à arquitetura de carimbo de linha de base, exceto para os recursos de rede, que são pré-provisionados pela equipe da plataforma.
Neste artigo, consulte a seção Rede virtual 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 consideração no Contrato de Nível de Serviço (SLA) do composto geral da carga de trabalho. Toda a comunicação é feita por meio da assinatura de 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 criação e liberação para um aplicativo de missão crítica 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 estão ligados à(s) assinatura(s) 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 a configuração deles permanecem os mesmos que os recursos de monitoramento de linha de base.
Neste artigo, veja a seção Considerações sobre monitoramento.
Recursos de gerenciamento
Para obter acesso ao cluster de cálculo privado e a outros recursos, essa arquitetura usa agentes de compilação privados e instâncias de máquinas virtuais de jumpbox. O Azure Bastion fornece acesso seguro às jumpboxes. Os recursos dentro dos carimbos permanecem os mesmos que os recursos de gerenciamento de linha de base.
Considerações de 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 da plataforma decide a topologia de rede para toda a organização. Considera-se a topologia hub-spoke nessa arquitetura. Uma alternativa pode ser a WAN Virtual do Azure.
Integração de rede de 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 da plataforma.
De uma perspectiva de missão crítica, essa rede não é efêmera, e esses recursos estão no caminho crítico.
| Recursos do Azure | Finalidade |
|---|---|
| Azure ExpressRoute | Fornece conectividade privada do local para a infraestrutura do Azure. |
| Firewall do Azure | Atua como o 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 ramificações 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 para a rede virtual spoke (descrita a seguir). Leia e concorde com as atualizações de NVA, regras de firewall, regras de roteamento, failover de ExpressRoute para Gateway de VPN, infraestrutura DNS e assim por diante.
Observação
Um benefício importante no uso do hub federado é que a carga de trabalho pode se integrar a outras cargas de trabalho no Azure ou entre locais atravessando os hubs de rede gerenciados pela organização. Essa mudança também reduz seus custos operacionais, pois parte da responsabilidade é transferida para a equipe da plataforma.
Rede virtual regional spoke
A zona de destino do aplicativo tem pelo menos duas Redes Virtuais do Azure pré-provisionadas, por região, que são referenciadas pelos carimbos regionais. Essas redes não são efêmeras. Um atende ao tráfego de produção e o outro tem como alvo 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ê é o proprietário dessa rede. Essa arquitetura mantém o mesmo design que a arquitetura de linha de base com controles de rede.
Não há peering entre a rede de operações e a rede de 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. Estas são algumas áreas.
Planejamento de endereço IP
Depois de estimar o tamanho necessário para executar sua carga de trabalho, trabalhe com a equipe da plataforma para que eles possam provisionar a rede adequadamente.
Equipe de plataforma
Forneça endereços distintos para redes virtuais que participam de emparelhamentos. Endereços sobrepostos, por exemplo, de redes locais e de carga de trabalho, podem causar disrupções que levam à interrupção.
Aloque espaços de endereço IP grandes o suficiente para conter os recursos de tempo de execução e implantações, lidar com failovers e oferecer suporte à escalabilidade.
A rede virtual pré-provisionada e os emparelhamentos devem ser capazes de suportar o crescimento esperado da carga de trabalho. Você deve avaliar esse crescimento com a equipe da plataforma regularmente. Para obter mais informações, consulte Conectividade com o Azure.
Sub-rede de rede regional spoke
Você é responsável por alocar sub-redes na rede virtual regional. As sub-redes e os recursos nelas contidos são efêmeros. O espaço de endereçamento deve ser grande o suficiente para acomodar o crescimento potencial.
Sub-rede de pontos de extremidade privados Depois que o tráfego chega à rede virtual, a comunicação com os serviços de PaaS dentro da 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 de cluster Os requisitos de escalabilidade da carga de trabalho influenciam a quantidade de espaço de endereçamento que deve ser alocada para as sub-redes. À medida que os nós e pods do AKS se expandem, 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 sua carga de trabalho não seja comprometida por acesso não autorizado.
Essa arquitetura usa Grupos de Segurança de Rede (NSGs) para restringir o tráfego entre sub-redes e a assinatura de conectividade. Os NSGs usam ServiceTags para os serviços compatíveis.
Equipe de plataforma
Imponha o uso de NSGs por meio das Políticas do Gerenciador de Rede do Azure.
Conheça o design da carga de trabalho. Não há tráfego direto entre os carimbos. Também não há fluxos inter-regionais. Se esses caminhos forem necessários, o tráfego deverá fluir pela assinatura de conectividade.
Evite o tráfego de hub desnecessário originado de outras cargas de trabalho na carga de trabalho de missão crítica.
Tráfego de saída de carimbos regionais
Todo o tráfego de saída de cada rede spoke regional é roteado por meio do Firewall do Azure centralizado 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 do aplicativo de criar sub-redes que não tenham a nova tabela de rotas.
Conceda permissões adequadas de controle de acesso baseado em função (RBAC) à equipe do aplicativo 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 de missão crítica devem ser implantadas em várias regiões para resistir a interrupções regionais. Trabalhe com a equipe da plataforma para garantir que a infraestrutura seja confiável.
Equipe de plataforma
Implante recursos de rede centralizados por região. A metodologia de projeto de missão crítica requer isolamento regional.
Trabalhe com a equipe do aplicativo para descobrir dependências regionais ocultas para que um recurso de plataforma degradado em uma região não afete as cargas de trabalho em outra região.
Resolução DNS
A assinatura de conectividade fornece zonas de DNS privado. No entanto, essa abordagem centralizada pode não levar em consideração as necessidades de DNS que podem ser específicas para o seu caso de uso. Provisione suas próprias zonas DNS e vincule-se ao carimbo regional. Se a equipe de aplicativos não possuir um DNS, o gerenciamento de links privados se tornará um desafio para recursos globais, como o Azure Cosmos DB.
Equipe de plataforma
Delegue as zonas de DNS Privado do Azure à equipe do aplicativo para abranger 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 de DNS privado gerenciadas pela equipe do aplicativo.
Considerações sobre o design do 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 mais baixos 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 reduzida 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. Ações realizadas pela automação de integração contínua/implantação contínua (CI/CD).
Quais são as compensações?
Considere as compensações entre isolamento de ambientes, complexidade de gerenciamento e otimização de custos.
Dica
Todos os ambientes devem ter 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 de conectividade. Você poderá minimizar o delta entre os 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 da plataforma para projetar uma topologia que atenda à meta geral de confiabilidade para a carga de trabalho. Há benefícios em compartilhar os recursos fornecidos pela plataforma entre ambientes na mesma assinatura, pois isso refletirá o ambiente de produção.
Observação
Usar 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. Assim, a consistência com a produção é garantida para testes e validação.
Assinatura de produção
Pode haver limites de recursos na sua assinatura. Se você colocar todos esses recursos em uma assinatura, poderá atingir esses limites. Com base nas suas unidades de escala e na escala esperada, considere um modelo mais distribuído. Por exemplo,
Uma assinatura que contém agentes de compilação e recursos globais do Azure DevOps.
Uma assinatura por região. Contém os recursos regionais, os recursos de carimbo e as jumpboxes para o(s) carimbo(s) regional(is).
Confira um exemplo de topologia de assinatura usada nessa arquitetura.
Assinatura de pré-produção
É necessário pelo menos uma assinatura. 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
É necessário pelo menos uma assinatura. Essa assinatura poderá estar sujeita a limites de recursos se executar todos os ambientes independentes. Assim, você pode solicitar várias assinaturas. Recomenda-se ter ambientes individuais nas suas assinaturas dedicadas.
Tente corresponder à topologia de produção o máximo possível.
Considerações de implantação
Implantações com falha ou versões incorretas são causas comuns de interrupções de aplicativos. 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 com os recursos e a governança fornecidos pela plataforma.
Consulte: Cargas de trabalho de missão crítica bem arquitetadas: implantação e teste.
Infraestrutura de implantação
A confiabilidade da infraestrutura de implantação, como agentes de compilação e a rede deles, geralmente é tão importante quanto os recursos de tempo de execução da carga de trabalho.
Essa arquitetura usa agentes de compilação privados para impedir o acesso não autorizado que pode afetar a disponibilidade do aplicativo.
Manter o isolamento entre os recursos de implantação é altamente recomendado. Uma infraestrutura de implantação deve estar vinculada à(s) sua(s) assinatura(s) 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 apenas a esses ambientes individuais. Considere os recursos de implantação por região para tornar a infraestrutura de implantação mais confiável.
Implantação sem tempo de inatividade
As atualizações do aplicativo podem causar interrupções. Impor implantações consistentes aumentará a confiabilidade. Estas abordagens são recomendadas:
- Tenha pipelines de implantação totalmente automatizados.
- Implante atualizações em ambientes de pré-produção com um carimbo limpo.
Para obter mais informações, consulte Diretrizes de implantação e teste de missão crítica.
Na arquitetura de linha de base, essas estratégias são implementadas desprovisionando e, em seguida, removendo o carimbo a cada atualização. Nesse design, o desprovisionamento completo não é possível porque a equipe da plataforma detém alguns recursos. Assim, o modelo de implantação foi alterado.
Modelo de implantação
A arquitetura de linha de base usa o modelo Blue-Green para implantar atualizações de aplicativos. Novos carimbos com alterações são implantados junto com os existentes. Depois que o tráfego é movido para o novo carimbo, o 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 emparelhar para o hub regional. Você precisará reutilizar esses recursos em cada implantação.
O modelo Canário pode alcançar uma implantação segura com a opção de reversão. 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 carimbo são excluídos pelo pipeline, exceto 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 controle de acesso baseado em função (RBAC) são preservados. Nesse 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 de aplicativos, mesmo quando pertencem à equipe do aplicativo. Pode haver uma incompatibilidade entre sua 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 nas suas implantações declarativas no início do ciclo de desenvolvimento da carga de trabalho. Caso contrário, pode haver um descompasso que leva ao delta entre o estado desejado e o estado implantado.
Gerenciamento de acesso de assinatura de implantação
Trate os limites de assinatura como seus limites de segurança para limitar o raio de alcance. As ameaças podem afetar a confiabilidade da carga de trabalho.
Equipe de plataforma
- Dê às equipes de aplicativos autorização para operações com escopo para a assinatura da zona de destino do aplicativo.
Se você estiver executando várias implantações em uma assinatura única, uma violação afetará ambas as implantações. Recomenda-se 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 da carga de trabalho. Além disso, deve ter restrições em vigor que impeçam a manipulação excessiva dos recursos da plataforma dentro da assinatura.
Considerações de monitoramento
A plataforma de zona de destino do Azure oferece recursos de observabilidade compartilhados como parte da assinatura de gerenciamento. A equipe de operações centralizadas incentiva as equipes de aplicativos a usar o modelo federado. Mas, para cargas de trabalho de missão crítica, um único armazenamento de observabilidade centralizado não é recomendado porque pode ser um único ponto de falha. As cargas de trabalho de missão crítica também geram telemetria que pode não ser aplicável ou acionável para equipes de operações centralizadas.
Assim, uma abordagem autônoma para o monitoramento é altamente recomendada. Os operadores de carga de trabalho são, em última instância, 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 é mantida 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 painéis e alertas está no escopo de 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 de plataforma para coleta de métricas & de log.
Modelo de integridade
A metodologia de projeto de missão crítica requer um modelo de integridade do sistema. Ao definir 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 espaços de trabalho.
Equipe de plataforma
Crie uma consulta de controle de acesso baseado em função (RBAC) e colete logs de leitura para recursos de plataforma relevantes que são usados no caminho crítico do aplicativo de missão crítica.
Apoie a meta organizacional de confiabilidade em relação à carga de trabalho de missão crítica, dando à equipe de aplicativos permissão suficiente para realizar suas operações.
Nessa arquitetura, o modelo de integridade inclui logs e métricas de recursos provisionados na assinatura de 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 para 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 na 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 arquitetadas: 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 Gerenciador de Rede do Azure e outros controles de seu grupo de gerenciamento. A equipe da plataforma fornece essas proteções.
Para implantações, não dependa exclusivamente das políticas fornecidas pela plataforma, pois:
- Elas não são projetadas para as necessidades de cargas de trabalho individuais.
- As políticas e regras podem ser atualizadas ou removidas da sua equipe e, portanto, podem afetar a confiabilidade.
É altamente recomendável que você crie e atribua políticas do Azure nas suas implantações. Esse esforço pode levar a duplicações, mas isso é aceitável, considerando o impacto potencial na confiabilidade do sistema. Se houver alterações nas políticas da 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 à medida que elas evoluem.
- Esteja ciente das políticas usadas pela equipe do aplicativo. Avalie se eles devem ser adicionados ao grupo de gerenciamento.
Implantar essa arquitetura
Os aspectos de rede dessa arquitetura são implantados na implementação conectada de missão crítica.
Observação
A implementação conectada visa ilustrar uma carga de trabalho de missão 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 uma assinatura de conectividade já exista.
Próximas etapas
Revise a área de design de rede e conectividade na Estrutura Bem Arquitetada do Azure.
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.