Essa arquitetura de referência fornece orientação para a implantação de 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 aterrissagem de aplicativo do Azure que herda o grupo Corp. Management. Espera-se que a carga de trabalho se integre a recursos compartilhados pré-provisionados na zona de aterrissagem da plataforma Azure que são gerenciados por equipes centralizadas.
Importante
O que é uma zona de destino do Azure? Uma zona de aterrissagem de aplicativo é uma assinatura do Azure na qual a carga de trabalho é executada. Está ligado aos recursos partilhados 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 aterrissagem da plataforma são uma coleção de várias assinaturas, cada uma com uma função específica. Por exemplo, a assinatura de 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 da carga de trabalho, você se beneficia ao transferir o gerenciamento de recursos compartilhados para equipes centrais e se concentrar nos esforços de desenvolvimento da 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 aterrissagem 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 de missão crítica opere conforme o esperado. Você deve ter um relacionamento de confiança com a equipe da plataforma para que os problemas de indisponibilidade nos serviços centralizados, que afetam a carga de trabalho, sejam mitigados no nível da plataforma. Mas, sua equipe é responsável por conduzir os requisitos com a equipe da plataforma para alcançar 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.
Nota
A orientação é apoiada por uma implementação de exemplo de 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 como o primeiro passo para a 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 desempenho degradado. Manter esse caminho enxuto minimizará os pontos de falha.
Ciclo de vida dos componentes
Considere o ciclo de vida dos componentes críticos, pois isso tem um impacto no seu objetivo de alcançar 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 partilham o tempo de vida com o sistema ou região.
Dependências externas
Minimize as dependências externas de componentes e processos, o que pode introduzir pontos de falha. A arquitetura tem recursos de propriedade de várias equipes fora da sua equipe. Esses componentes (se críticos) estão no escopo dessa arquitetura.
Topologia de subscrição
As zonas de aterrissagem do Azure não implicam uma única topologia de assinatura. Planeje sua pegada 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 à equipe consultar rapidamente sua coleta de dados (especialmente o caminho crítico) e agir em remediações.
Arquitetura
Transfira um ficheiro do Visio desta 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 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 vivem na(s) assinatura(s) da zona de destino do aplicativo. Os recursos globais não são efêmeros e compartilham a vida útil 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 regional
Esses recursos vivem nas 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 são fornecidos por meio da assinatura de conectividade são provisionados como parte da zona de aterrissagem da plataforma.
Neste artigo, consulte a seção Rede virtual do hub regional.
Recursos regionais de selos
Esses recursos vivem na(s) assinatura(s) da zona de destino do aplicativo. Estes recursos não partilham nada com outros recursos, exceto os recursos globais.
A maioria dos serviços do Azure e sua configuração permanecem iguais à arquitetura de carimbo de linha de base, exceto os recursos de rede, que são pré-provisionados pela equipe da plataforma.
Neste artigo, consulte a seção Rede virtual regional falada.
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 considerados no Acordo de Nível de Serviço (SLA) composto geral da carga de trabalho. Toda a comunicação é feita através da subscrição de Conectividade. Existem 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 compilaçã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 regionais de monitorização
Esses recursos vivem na(s) assinatura(s) da zona de destino do aplicativo. Os dados de monitoramento para 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 de monitoramento.
Recursos de gestão
Para obter acesso ao cluster de computação privado e outros recursos, essa arquitetura usa agentes de compilação privados e instâncias de máquinas virtuais de caixa de salto. 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 a rede
Neste projeto, a carga de trabalho é implantada na zona de aterrissagem do aplicativo e precisa de conectividade com os recursos federados na zona de aterrissagem da plataforma. O objetivo 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. A topologia Hub-spoke é assumida nessa arquitetura. Uma alternativa poderia ser a WAN Virtual do Azure.
Rede virtual 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 perspetiva de missão crítica, essa rede não é efêmera, e esses recursos estão no caminho crítico.
| Recurso do Azure | Propósito |
|---|---|
| Azure ExpressRoute | Fornece conectividade privada do local para a infraestrutura do Azure. |
| Azure Firewall | Atua como o NVA que inspeciona e restringe o tráfego de saída. |
| Azure DNS | Fornece resolução de nomes entre locais. |
| Gateway de VPN | Conecta filiais de organizações remotas 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 falada (descrita a seguir). Certifique-se de entender e concordar com as atualizações de NVA, regras de firewall, regras de roteamento, failover de Rota Expressa para Gateway VPN, infraestrutura de DNS e assim por diante.
Nota
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 uma parte da responsabilidade é transferida para a equipe da plataforma.
Rede virtual regional falada
A zona de aterrissagem 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 serve o tráfego de produção e o outro visa a implantação do vNext. Essa abordagem oferece a capacidade de executar práticas de implantação confiáveis e seguras.
Rede virtual de operações
O tráfego operacional é isolado em uma rede virtual separada. Esta rede virtual não é efêmera e você é dono 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 falada. Toda a comunicação é feita através de Links Privados.
Responsabilidade partilhada
Tenha uma compreensão clara de qual equipe é responsável por cada elemento de design da arquitetura. Aqui estão algumas áreas-chave.
Planeamento de endereços 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.
Equipa da plataforma
Forneça endereços distintos para redes virtuais que participam de emparelhamentos. A sobreposição de endereços, por exemplo, de redes locais e de carga de trabalho, pode causar interrupções que levam a interrupções.
Aloque espaços de endereço IP que sejam 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 peerings 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 falada
Você é responsável pela alocação de 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 serviços 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 AKS se expandem, os endereços IP são atribuídos a partir desta 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 NSGs (Network Security Groups) para restringir o tráfego entre sub-redes e a assinatura de conectividade. Os NSGs usam ServiceTags para os serviços suportados.
Equipa da plataforma
Imponha o uso de NSGs por meio das Políticas do Azure Network Manager.
Esteja ciente do design da carga de trabalho. Não há tráfego direto entre os selos. Também não há fluxos inter-regiões. Se esses caminhos forem necessários, o tráfego deverá fluir através da assinatura de Conectividade.
Evite o tráfego de hub desnecessário originado de outras cargas de trabalho para a carga de trabalho de missão crítica.
Tráfego de saída de selos regionais
Todo o tráfego de saída de cada rede spoke regional é roteado através 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.
Equipa da 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.
Dê 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 multirregião
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.
Equipa da plataforma
Implante recursos de rede centralizados por região. A metodologia de design 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 de 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 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 DNS, o gerenciamento de links privados se tornará um desafio para recursos globais, como o Azure Cosmos DB.
Equipa da plataforma
Delegue as zonas de DNS Privado do Azure à equipe do aplicativo 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 do aplicativo.
Considerações de 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 se mantém o isolamento?
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 pertencentes à equipe de aplicativos. Ambientes de pré-produção, como preparação e integração, são necessários para garantir que o aplicativo seja testado em um ambiente que simule a produção, tanto quanto 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. Recomenda-se 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 são feitas por integração contínua/implantação contínua (CI/CD) automação.
Quais são as compensações?
Considere as compensações entre isolamento de ambientes, complexidade de gerenciamento e otimização de custos.
Gorjeta
Todos os ambientes devem depender de instâncias de produção de recursos externos, incluindo recursos da plataforma. Por exemplo, um hub regional de produção na assinatura de conectividade. Você será capaz de minimizar o delta entre os ambientes de pré-produção e produção.
Topologia de assinatura para infraestrutura de carga de trabalho
As subscrições são-lhe dadas pela equipa 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.
Nota
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. Assim, a consistência com a produção é assegurada para testes e validação.
Subscrição de produção
Pode haver limites de recursos na assinatura dada a você. Se você colocalizar todos esses recursos em uma assinatura, poderá atingir esses limites. Com base em suas unidades de escala e escala esperada, considere um modelo mais distribuído. Por exemplo,
Uma assinatura que contém agentes de compilação do Azure DevOps e recursos globais.
Uma assinatura, por região. Ele contém os recursos regionais, os recursos de carimbo e caixas de salto para o(s) selo(s) regional(is).
Aqui está um exemplo de topologia de assinatura usada nessa arquitetura.
Subscrição de pré-produção
É necessária pelo menos uma subscrição. Ele pode executar muitos ambientes independentes, no entanto, é recomendável ter vários ambientes em assinaturas dedicadas. Esta subscrição também pode estar sujeita a limites de recursos, como a subscrição de produção, descrita acima.
Subscrição de desenvolvimento
É necessária pelo menos uma subscrição. Esta subscrição pode estar sujeita a limites de recursos se executar todos os ambientes independentes. Assim, você pode solicitar várias assinaturas. Recomenda-se ter ambientes individuais em suas assinaturas dedicadas.
Tente corresponder à topologia de produção tanto quanto possível.
Considerações sobre implementaçã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 projeto com os recursos e a governança fornecidos pela plataforma.
Consulte a: Cargas de trabalho de missão crítica bem arquitetadas: implantação e testes.
Infraestrutura de implantação
A confiabilidade da infraestrutura de implantação, como agentes de compilação e sua rede, 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.
É altamente recomendável manter o isolamento entre os recursos de implantação. 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 mais separação limitando o acesso apenas a 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 sem tempo de inatividade
As atualizações do aplicativo podem causar interrupções. A imposição de implantações consistentes aumentará a confiabilidade. Estas abordagens são recomendadas:
- Ter pipelines de implantação totalmente automatizados.
- Implante atualizações em ambientes de pré-produção com um selo 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, derrubando o carimbo a cada atualização. Neste design, o desprovisionamento completo não é possível porque a equipe da plataforma possui alguns recursos. Assim, o modelo de implantação foi alterado.
Modelo de implementação
A arquitetura de linha de base usa o modelo azul-verde para implantar atualizações de aplicativos. Novos selos com alterações são implantados juntamente com os selos existentes. Depois que o tráfego é movido para o novo carimbo, o carimbo existente é destruído.
Neste caso, a rede virtual emparelhada dada não é efêmera. O carimbo não tem permissão para criar a rede virtual ou emparelhamento para o hub regional. Você precisará reutilizar esses recursos em cada implantação.
O modelo Canary pode alcançar 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 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 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 aterrissagem de aplicativos 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 em zonas de aterrissagem de aplicativos, mesmo quando são de propriedade da equipe do aplicativo. Pode haver uma incompatibilidade entre sua implantação e a configuração final do recurso.
Compreenda 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 um desvio 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 explosão. As ameaças podem afetar a confiabilidade da carga de trabalho.
Equipa da plataforma
- Dê às equipes de aplicativos autorização para operações com permissões com escopo para a assinatura da zona de aterrissagem do aplicativo.
Se você estiver executando várias implantações em uma única assinatura, 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 aterrissagem do Azure fornece recursos de observabilidade compartilhados como parte das assinaturas 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, recomenda-se vivamente uma abordagem autónoma para a monitorização. 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 é continuada nesta 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 alertar 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 a coleta de métricas de log & .
Modelo de estado de funcionamento
A metodologia de design 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 aterrissagem na plataforma no escopo dos quais o aplicativo depende. Crie consultas de log, integridade e alerta para executar o monitoramento entre espaços de trabalho.
Equipa da plataforma
Conceda a consulta RBAC (controle de acesso baseado em função) e coletores de log de leitura para recursos relevantes da plataforma 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 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 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 a: 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 aterrissagem do aplicativo herda políticas do Azure, regras do Azure Network Manager e outros controles de seu grupo de gerenciamento. A equipe da plataforma fornece esses guarda-corpos.
Para implantações, não dependa exclusivamente das políticas fornecidas pela plataforma, porque:
- Eles não são projetados para cobrir as necessidades de cargas de trabalho individuais.
- As políticas e regras podem ser atualizadas ou removidas fora da 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 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.
Equipa da 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 esta arquitetura
Os aspetos de rede dessa arquitetura são implementados na implementação Mission-critical Connected.
Nota
A implementação Connected destina-se a ilustrar uma carga de trabalho de missão crítica que depende de recursos organizacionais, integra-se com outras cargas de trabalho e usa serviços compartilhados. A implementação pressupõe que já exista uma assinatura de conectividade.
Próximos passos
Analise 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.