Partilhar via


Cenário: Fazer a transição de um ambiente de organização regional para a arquitetura conceitual da zona de aterrissagem do Azure

Este artigo descreve considerações e instruções para migrar e fazer a transição do seu ambiente do Azure para a arquitetura conceitual da zona de aterrissagem do Azure. Este cenário abrange uma organização regional com grupos de gerenciamento separados em ambientes de desenvolvimento, teste e produção (dev/test/prod).

Nesse cenário, o cliente tem uma grande pegada no Azure. Eles têm uma hierarquia de grupo de gerenciamento que é organizada por ambientes dev/test/prod e, em seguida, por região. A sua implementação atual limita a sua escalabilidade e crescimento. Eles têm aplicativos implantados em todo o mundo. Uma equipe central de TI gerencia cada região. Neste cenário, as regiões são a América; Europa, Oriente Médio e África (EMEA); e Ásia-Pacífico (APAC).

O cliente deseja mudar de seu ambiente existente para a arquitetura conceitual das zonas de aterrissagem do Azure. Essa abordagem suporta sua estratégia de nuvem em primeiro lugar e tem uma plataforma robusta que é dimensionada à medida que o cliente aposenta seus datacenters locais.

Estado atual

Nesse cenário, o estado atual do ambiente do Azure do cliente consiste em:

  • Vários grupos de gestão.
  • Uma hierarquia de grupo de gerenciamento baseada em ambientes de desenvolvimento/teste/prod no primeiro nível e, em seguida, baseada na geografia no segundo nível.
  • Uma assinatura do Azure para cada geografia e ambiente de aplicativo, como dev/test/prod. Esta subscrição é necessária para proporcionar aos programadores um ambiente descontraído para testes e inovação.
  • Algumas cargas de trabalho críticas que precisam do mesmo modelo de governança em desenvolvimento/teste/prod, o que pode criar desafios de governança para o cliente.
  • Distribuição não uniforme de recursos. Os recursos de plataforma e carga de trabalho para um único ambiente são implantados nas mesmas assinaturas do Azure.
  • Aplicativos que são implantados nas respetivas assinaturas com base em sua região e classificação de ambiente, como dev/test/prod.
  • Atribuições de política, como efeitos de auditoria e efeitos de negação, atribuídas no nível do grupo de gerenciamento e da assinatura.
  • O mesmo conjunto de políticas do Azure aplicado a todos os aplicativos na mesma região e no mesmo tipo de ambiente.
  • Atribuições de função de controle de acesso com base em função para cada assinatura e grupo de recursos.
  • Uma rede virtual de hub, como o Gateway de VPN do Azure ou a Rota Expressa do Azure, para conectividade híbrida.
  • Uma rede virtual para cada ambiente de aplicativo.
  • Uma equipe central de TI que controla e opera o respetivo grupo de gerenciamento para cada região. A equipe enfrenta alguns desafios de consistência, configuração e conformidade quando se trata de políticas, controle de acesso, configuração de recursos de plataforma e conformidade de segurança, porque alguns aplicativos são implantados em várias regiões.

O diagrama a seguir mostra o estado atual deste cenário de exemplo.

Diagram that shows the regional organization environment.

Transição para a arquitetura conceitual da zona de aterrissagem do Azure

Antes de implementar essa abordagem, revise a arquitetura conceitual da zona de aterrissagem do Azure, os princípios de design da zona de aterrissagem do Azure e as áreas de design da zona de aterrissagem do Azure.

Para fazer a transição do estado atual deste cenário para uma arquitetura conceitual de zona de aterrissagem do Azure, use esta abordagem:

  1. Implante o acelerador de zona de aterrissagem do Azure no mesmo locatário do Microsoft Entra ID em paralelo com o ambiente atual. Esse método fornece uma transição suave e em fases para a nova arquitetura de zona de aterrissagem com interrupção mínima para cargas de trabalho ativas.

    Essa implantação cria uma nova estrutura de grupo de gerenciamento. Essa estrutura está alinhada com os princípios e recomendações de design das zonas de aterrissagem do Azure. Ele também garante que essas alterações não afetem o ambiente existente.

    Para obter mais informações, consulte Como lidar com uma zona de aterrissagem de carga de trabalho dev/test/prod.

    Para obter informações sobre como usar a hierarquia de grupo de gerenciamento de área restrita para capacitar os desenvolvedores a testar e experimentar sem afetar outros ambientes, consulte Orientação de ambientes de área restrita da zona de aterrissagem do Azure.

    Para obter informações sobre como minimizar a interrupção de aplicativos e serviços durante a migração, consulte Adotar diretrizes de guardrails orientadas por políticas.

  2. (Opcional) Trabalhe com equipes de aplicativos ou serviços para migrar as cargas de trabalho implantadas nas assinaturas originais para novas assinaturas do Azure. Para obter mais informações, consulte Transição de ambientes existentes do Azure para a arquitetura conceitual da zona de aterrissagem do Azure. Você pode colocar cargas de trabalho na hierarquia do grupo de gerenciamento de arquitetura conceitual da zona de aterrissagem do Azure recém-implantada sob o grupo de gerenciamento correto, como corporativo ou online no diagrama a seguir.

    Para obter detalhes sobre o efeito nos recursos durante a migração, consulte Políticas.

    Eventualmente, você pode cancelar a assinatura existente do Azure e colocá-la no grupo de gerenciamento desativado.

    Nota

    Você não precisa necessariamente migrar os aplicativos ou serviços existentes para novas zonas de aterrissagem ou assinaturas do Azure.

  3. Crie novas assinaturas do Azure para fornecer zonas de destino que possam dar suporte a novos aplicativos e cargas de trabalho. Coloque-os sob o grupo de gerenciamento adequado, como corporativo ou on-line no diagrama a seguir.

    Para obter mais informações, consulte Preparando sua zona de desembarque para obter orientações sobre migração.

O diagrama a seguir mostra o estado desse cenário durante a migração.

Diagram that shows a single subscription environment in a transition state.

Resumo

Nesse cenário, o cliente estabeleceu a base necessária para dar suporte aos seus planos de crescimento e dimensionamento para suas cargas de trabalho no Azure implantando a arquitetura conceitual da zona de aterrissagem do Azure em paralelo ao ambiente existente.