Implantar zona de destino do Azure
Este artigo discute as opções disponíveis para você implantar zonas de destino de plataforma e aplicativo. As zonas de destino da plataforma fornecem serviços centralizados usados por cargas de trabalho. Zonas de destino de aplicativos são ambientes implantados para as próprias cargas de trabalho.
Importante
Para obter mais informações sobre definições e implementações de zonas de destino de plataforma versus aplicativo, consulte O que é uma zona de destino do Azure? no Cloud Adoption Framework para Azure.
Este artigo aborda as opções de implantação para zonas de destino de plataforma e aplicativo.
Escolher uma abordagem de zona de destino da plataforma
As seguintes opções de implantação de plataforma fornecem uma abordagem dogmática para implantar e operar a arquitetura conceitual da zona de destino do Azure, conforme detalhado no Cloud Adoption Framework. Dependendo das personalizações, a arquitetura resultante pode não ser a mesma para todas as opções de implantação listadas aqui. As diferenças entre as opções de implantação da plataforma são baseadas em como elas usam tecnologias diferentes, usam abordagens diferentes e são personalizadas de forma diferente.
Opções de implantação padrão
As opções de implantação padrão abordam o uso típico do Azure corporativo.
| Opção de implantação da zona de destino da plataforma do Azure | Descrição |
|---|---|
| Implantação do portal do Azure | Uma implantação baseada no portal do Azure que fornece uma implementação completa da arquitetura conceitual da zona de destino do Azure, juntamente com configurações dogmáticas para componentes-chave, como grupos de gerenciamento e políticas. |
| Implantação do Bicep | Uma implantação modular baseada em infraestrutura como código em que cada módulo Bicep encapsula um recurso principal da arquitetura conceitual da zona de destino do Azure. Enquanto os módulos podem ser implantados individualmente, o design propõe o uso de módulos orquestradores para encapsular a complexidade de implantar diferentes topologias com os módulos. A implantação do Bicep dá suporte à nuvem pública do Azure, às regiões do Azure China 21Vianet e às nuvens do Azure US Government. |
| Implantação do Terraform | Essa implantação baseada em infraestrutura como código fornece um módulo de orquestrador do Terraform e também permite implantar cada funcionalidade de plataforma individualmente ou como um todo. |
Variantes e especializações
Embora as opções de implantação de plataforma padrão endereçar o uso típico do Azure corporativo, há algumas opções de implantação que se concentram em especializações específicas.
| Opção de implantação | Descrição |
|---|---|
| Zona de destino soberana | A zona de destino soberana é uma variante das zonas de destino do Azure destinadas a organizações que precisam de controles soberanos avançados. |
Implementações de parceiros
Programas de parceiro, como o Azure Migrate e Modernize, podem ajudar a projetar e implementar uma zona de destino específica da plataforma para as necessidades da sua organização. Essas implementações começam com a arquitetura conceitual da zona de destino do Azure e ajudam a projetar configurações específicas para sua estratégia de adoção de nuvem, topologia organizacional e resultados desejados.
EPAC (política corporativa como código) para gerenciamento de políticas
EPAC (política corporativa como código) é um método alternativo para implantar, gerenciar e operar a Política do Azure em todo o ambiente do Azure da sua organização. Você pode usar o EPAC em vez das opções de plataforma padrão para gerenciar as políticas em um ambiente de zonas de destino do Azure. Para obter mais informações sobre a abordagem da integração, consulte Integrar a EPAC com as zonas de destino do Azure.
A política empresarial como código é a mais adequada para clientes de DevOps e infraestrutura como código que sejam mais avançados e maduros. No entanto, clientes de qualquer tamanho podem usar a EPAC se desejarem após avaliá-la. Para garantir que você esteja alinhado, veja primeiro Quem deve usar o EPAC?.
Observação
Compare o ciclo de vida e a flexibilidade das duas abordagens antes de decidir sobre qual abordagem você usa a longo prazo. Comece avaliando o gerenciamento de política nativa fornecido na implementação padrão descrita nas opções de plataforma padrão. Se essa implementação não parecer ideal para suas necessidades de governança, execute um MVP ou uma prova de conceito usando o EPAC. É importante comparar opções, validar e confirmar sua escolha antes de implementar uma abordagem, pois é um processo complexo alterar métodos de governança de políticas uma vez estabelecidos.
Operar as zonas de destino do Azure
Depois de implantar a zona de destino da plataforma, você precisará operá-la e mantê-la. Para obter mais informações, consulte as diretrizes sobre como Manter sua zona de destino do Azure atualizada.
Visualizador de governança do Azure
O visualizador de governança do Azure é destinado a ajudar você a obter uma visão geral holística sobre sua implementação técnica de governança do Azure, conectando os pontos e fornecendo relatórios sofisticados.
Venda de assinaturas
Depois que a zona de destino e a estratégia de governança da plataforma estiverem ativas, a próxima etapa é estabelecer a consistência sobre como as assinaturas serão criadas e operacionalizadas para proprietários de carga de trabalho. A democratização de assinatura é um princípio de design das zonas de destino do Azure que usa assinaturas como unidades de gerenciamento e escala. Esta abordagem acelera as migrações de aplicativos e o novo desenvolvimento de aplicativos.
As vendas de assinaturas padronizam o processo que as equipes da plataforma utilizam para que as equipes de carga de trabalho possam solicitar assinaturas, e as equipes da plataforma implantar e controlar essas assinaturas. Ele permite que as equipes de aplicativos obtenham acesso ao Azure em um método consistente e controlado, garantindo que a coleta de requisitos seja concluída.
Também é comum que as organizações tenham vários estilos diferentes de assinaturas que podem ser vendidos em seu locatário, muitas vezes conhecidas no setor como "linhas de produtos". Consulte Estabelecer linhas comuns de produtos de venda de assinaturas, para obter "linhas de produto" recomendadas para a sua organização.
Para começar, siga as orientações de implementação em Diretrizes para implementação de venda de assinaturas. Em seguida, examine os seguintes módulos de infraestrutura como código, que fornecem flexibilidade para atender às suas necessidades de implementação.
| Opção de implantação | Descrição |
|---|---|
| Venda de assinaturas do Bicep | Os módulos Bicep de venda de assinatura foram projetados para orquestrar a implantação das zonas de destino individuais do aplicativo baseadas em configuração por carga de trabalho. Eles podem ser executados manualmente ou como parte da automação. |
| Venda de assinatura do Terraform | Esses módulos usam o Terraform para orquestrar a implantação das zonas de destino de aplicativo individuais. |
Arquiteturas da zona de destino do aplicativo
As zonas de destino de aplicativos consistem em uma ou mais assinaturas implantadas como destinos aprovados para recursos de uma carga de trabalho sob a responsabilidade da equipe do aplicativo. Uma carga de trabalho pode aproveitar os serviços implantados em zonas de destino da plataforma ou pode ser isolada desses recursos centralizados. As zonas de destino do aplicativo devem ser usadas para aplicativos gerenciados centralmente, cargas de trabalho descentralizadas de propriedade das equipes de aplicativos e plataformas de hospedagem gerenciadas centralmente, como o AKS (Serviço de Kubernetes do Azure) que podem hospedar aplicativos para várias unidades de negócios. A menos que sejam forçadas por restrições fora do normal, as assinaturas de zona de destino do aplicativo contêm apenas recursos de uma carga de trabalho individual ou de limite de aplicativo lógico, tais como seu ciclo de vida ou sua classificação de criticidade.
As equipes de carga de trabalho comunicam os requisitos da carga de trabalho por meio de um processo formal estabelecido pela equipe da plataforma. Geralmente a equipe da plataforma implanta uma assinatura vazia que está registrada com toda a governança necessária. Em seguida, um arquiteto de carga de trabalho cria uma solução que funciona dentro das restrições dessa zona de destino do aplicativo e aproveita os recursos de plataforma compartilhada (como firewalls e roteamento entre premisis), onde é prático.
É possível que um arquiteto possa adaptar uma arquitetura de referência que não foi especificamente projetada com uma zona de destino do aplicativo em mente. No entanto, o Microsoft Learn também contém diretrizes de plataforma de dados e aplicativos para equipes de carga de trabalho que abordam especificamente os contextos da zona de destino do aplicativo. As equipes de plataforma devem estar cientes das diretrizes disponíveis para as equipes de carga de trabalho para que a equipe da plataforma possa prever os tipos de carga de trabalho e as características que podem estar presentes na organização.
| Arquitetura da zona de destino do aplicativo | Descrição |
|---|---|
| Ambiente do Serviço de Aplicativo do Azure | Recomendações comprovadas e considerações em ambos os casos de uso multilocatário e do Ambiente de Serviço de Aplicativo com uma implementação de referência. |
| APIM (Gerenciamento de API do Azure) | Recomendações e considerações comprovadas para implantar uma instância interna de Gerenciamento de API como parte de uma implementação de referência. O cenário usa o Gateway de Aplicativo do Azure para fornecer controle de entrada seguro e usa o Azure Functions como o back-end. |
| Azure Arc para cenários híbridos e multinuvem | Servidores habilitados para Azure Arc, Kubernetes e Instância Gerenciada de SQL habilitada para Azure Arc. |
| Aplicativos de Contêiner do Azure | Esta orientação dos Aplicativos de Contêiner do Azure descreve o caminho de design estratégico e define o estado técnico de destino para a implantação de Aplicativos de Contêiner do Azure. Uma equipe de carga de trabalho dedicada possui e opera essa plataforma. |
| Azure Data Factory | Saiba como pegar um medallion lakehouse tradicional e hospedá-lo dentro de uma zona de destino do aplicativo. |
| Carga de trabalho de chat de OpenAI do Azure | Descreve como integrar um aplicativo de chat típico do Azure OpenAI dentro das zonas de destino do Azure para utilizar recursos compartilhados centralizados ao aderir à governança e à eficiência de custos, oferecendo diretrizes para equipes de carga de trabalho sobre implantação e gerenciamento. |
| Azure Kubernetes Service (AKS) | Diretrizes e modelos de infraestrutura como código relacionados que representam o caminho de design estratégico e o estado técnico alvo para uma implantação do AKS em execução dentro de uma zona de destino do aplicativo. |
| Red Hat OpenShift no Azure | Uma coleção de código aberto de modelos Terraform que representa uma implantação otimizada do Azure Red Hat OpenShift que inclui recursos do Azure e da Red Hat. |
| Azure Synapse Analytics | Uma abordagem arquitetônica para preparar zonas de destino do aplicativo para uma implantação empresarial típica do Azure Synapse Analytics. |
| Área de Trabalho Virtual do Azure | Modelos ARM, Bicep e Terraform que devem ser referenciados ao projetar implantações da Área de Trabalho Virtual do Azure, incluindo a criação de pools de hosts, rede, armazenamento, monitoramento e complementos. |
| Máquinas Virtuais do Azure | Essa arquitetura estende as diretrizes da arquitetura de linha de base VM (máquina virtual) do Azure para uma zona de destino do aplicativo, com diretrizes sobre configuração de assinatura, conformidade de patch e outras preocupações de governança organizacional. |
| Solução VMware Azure | Modelos ARM, Bicep e Terraform que são úteis ao projetar implantações do VMware, incluindo nuvem privada da Solução VMware no Azure, jump box, rede, monitoramento e complementos. |
| Citrix no Azure | As diretrizes de design para o Cloud Adoption Framework para Citrix Cloud em uma zona de destino de escala empresarial do Azure cobrem muitas áreas de design. |
| Red Hat Enterprise Linux (RHEL) no Azure | O RHEL (Zona de Destino para Red Hat Enterprise Linux) no Azure é uma coleção de software livre de diretrizes arquitetônicas e recomendações de implementação de referência usadas para projetar cargas de trabalho baseadas em RHEL no Microsoft Azure. |
| Cargas de trabalho de computação de alto desempenho (HPC) | Uma solução de cluster HPC de ponta a ponta no Azure que usa ferramentas como Terraform, Ansible e Packer. Ele aborda as práticas recomendadas das zonas de aterrissagem do Azure, incluindo gerenciamento de identidade, acesso via jump box e dimensionamento automático. |
| Cargas de trabalho críticas | Aborda como uma carga de trabalho classificada como crítica deve ser projetada para ser executada dentro de uma zona de destino do aplicativo. |
| Cargas de trabalho do SAP | Fornece diretrizes e recomendações para cargas de trabalho SAP alinhadas às práticas recomendadas da zona de destino do Azure. Fornece recomendações para a criação de componentes de infraestrutura, como computação, rede, armazenamento, monitoramento e build de sistemas SAP. |
As cargas de trabalho geralmente são uma coleção de várias tecnologias e classificações. Recomendamos que você examine o material de referência relacionado para todas as tecnologias em sua carga de trabalho. Por exemplo, compreender as diretrizes do chat do Azure OpenAI e do Gerenciamento de API do Azure é importante para entender se seu cenário de IA gerativa se beneficiaria da adição de um gateway de API.