Princípios de design da zona de destino do Azure

A arquitetura de referência da zona de destino do Azure se aplica universalmente a qualquer processo ou implementação da zona de destino do Azure. Na base da arquitetura, um conjunto de princípios de design básicos serve como uma bússola para decisões de design subsequentes em domínios técnicos críticos.

Os princípios são intencionalmente aspiracionais, para ajudá-lo a se esforçar por um design ideal da arquitetura de destino. Se você optar por implantar uma implementação que seja uma arquitetura de referência da zona de destino do Azure ou qualquer versão da base de código da zona de destino em escala empresarial, baseie-se na arquitetura aplicando os princípios de design descritos neste artigo.

Use esses princípios em sua implementação como um guia útil para obter os benefícios das tecnologias de nuvem. Essa abordagem nativa de nuvem ou orientada à nuvem representa maneiras de trabalhar e opções técnicas para sua organização que abordagens de tecnologia herdadas normalmente não oferecem.

Familiarize-se com esses princípios para entender melhor seu impacto e as compensações associadas ao desvio.

Impacto dos desvios de design

Pode haver razões válidas para se desviar dos princípios de design. Por exemplo, os requisitos organizacionais podem ditar resultados ou abordagens específicos para criar um ambiente do Azure. Nesses casos, é importante entender o impacto que o desvio tem no design e nas operações futuras. Considere cuidadosamente as compensações que cada princípio descreve.

Como regra geral, esteja preparado para balancear os requisitos e a funcionalidade. Sua jornada para uma arquitetura conceitual evolui ao longo do tempo à medida que os requisitos mudam e você aprende com sua implementação. Por exemplo, o uso de serviços de versão prévia e a dependência de roteiros de serviço podem remover bloqueadores técnicos durante a adoção.

Democratização da assinatura

A democratização da assinatura fornece uma maneira escalonável de acelerar as migrações de aplicativos e o desenvolvimento de novos aplicativos. Essa abordagem permite que as equipes de carga de trabalho acessem e gerenciem assinaturas do Azure de forma independente, mantendo-se dentro da governança da plataforma e dos guardrails operacionais.

1. Use assinaturas como unidades de gerenciamento. As assinaturas representam o limite fundamental para organizar e gerenciar recursos do Azure. Atribua assinaturas a unidades de negócios para dar suporte ao design, desenvolvimento, teste e migração de cargas de trabalho. Esse alinhamento com as necessidades e prioridades de negócios capacita os proprietários de portfólio e as equipes de carga de trabalho a fornecer valor mais rapidamente.

2. Use assinaturas para separar ambientes de aplicativo. As assinaturas também devem ser usadas para controlar e separar ambientes no SDLC (ciclo de vida de desenvolvimento de software), como desenvolvimento, teste e produção. Essa separação melhora a governança, reduz o risco e dá suporte ao gerenciamento de carga de trabalho consistente. Siga as diretrizes para gerenciar ambientes de desenvolvimento de aplicativos em zonas de destino do Azure.

3. Habilite um processo de venda automática de assinatura. Estabeleça um processo que permite que as equipes de aplicativos e serviços solicitem e recebam assinaturas com o mínimo de atrito. Um modelo de autoatendimento ou autoatendimento próximo reduz os atrasos causados por aprovações manuais e aprovações de negócios complexas. Siga as diretrizes na venda automática de assinaturas para simplificar o provisionamento e acelerar a inovação.

4. Ofereça vários tipos de assinatura para dar suporte a requisitos diferentes. Forneça uma variedade de linhas de produtos de assinatura adaptadas a diferentes cenários de carga de trabalho. Essa flexibilidade permite que as equipes escolham o tipo de assinatura mais apropriado para suas necessidades. Consulte para estabelecer linhas comuns de produtos de venda automática de assinatura.

5. Suporte a assinaturas com uma hierarquia de grupo de gerenciamento escalonável. Use uma hierarquia bem definida do Grupo de Gerenciamento para operar, governar e proteger assinaturas efetivamente em escala. Essa hierarquia permite a imposição de política centralizada e a organização eficiente de várias assinaturas. Siga as considerações e recomendações de design de assinatura ehierarquia recomendadas da zona de destino do Azure para garantir a consistência.

Impacto do desvio

• Gerenciamento compartilhado versus operações centralizadas. Uma maneira de implementar este princípio é transferir operações para unidades de negócios e equipes de carga de trabalho. Essa reatribuição permite que os proprietários de cargas de trabalho tenham mais controle e autonomia sobre suas cargas de trabalho, dentro das proteções da base da plataforma. As organizações que exigem operações centrais podem não querer delegar o controle de ambientes de produção para equipes de carga de trabalho ou unidades de negócios. Essas organizações podem precisar modificar o design da organização de recursos para se desviarem desse princípio.

• Desalinhamento do modelo operacional. O design da arquitetura de referência da zona de destino do Azure pressupõe um grupo de gerenciamento específico e uma hierarquia de assinatura para todas as assinaturas de gerenciamento de operações. Essa hierarquia pode não se alinhar à abordagem de operações. À medida que sua organização cresce e evolui, seu modelo operacional pode mudar. Mover recursos para assinaturas separadas pode levar a migrações técnicas complicadas. Examine as diretrizes alinhar antes de se comprometer com uma abordagem.

• Falta de processo de venda automática de assinatura e automação. Se você não fornecer um processo de provisionamento de assinaturas e a automação associada, seja por autoatendimento ou não, as equipes de aplicativos e serviços terão atraso na entrega de valor para sua organização enquanto as assinaturas forem criadas para elas e colocadas no Grupo de Gerenciamento apropriado na hierarquia. Se o processo para obter novas assinaturas for complicado e levar muito tempo, as equipes de aplicativos e serviços poderão optar por criar assinaturas sozinhas por meio de contas de cobrança alternativas e talvez também em locatários do Microsoft Entra não gerenciados ou controlados, o que significa que a TI sombra já existe.

Governança orientada por políticas

Use o Azure Policy para fornecer guardrails e garantir que os aplicativos implantados estejam em conformidade com a segurança, a governança e os controles regulatórios da sua organização que são independentes das ferramentas de implementação e configuração. O Azure Policy fornece às equipes de plataforma as ferramentas necessárias para implementar, impor, auditar e controlar as operações e configurações do plano de dados e controle do Azure. Isso permite que as assinaturas sejam democratizadas, idealmente por meio de um processo de autoatendimento, para equipes de aplicativos e serviços para que possam fornecer valor comercial rapidamente para a organização.

Para obter mais informações sobre como utilizar o Azure Policy, examine a adoção de guardrails controlados por políticas.

Impacto do desvio

Aumento da sobrecarga operacional e de gerenciamento. Se você não usar o Azure Policy para criar guardrails em seu ambiente, aumentará a sobrecarga operacional e de gerenciamento da manutenção da conformidade. O Azure Policy ajuda você a restringir e automatizar o estado de conformidade desejado em seu ambiente.

Controle único e plano de gerenciamento

Evite a dependência em camadas de abstração, como portais ou ferramentas desenvolvidas pelo cliente. É melhor ter uma experiência consistente para operações centrais e operações de carga de trabalho. O Azure fornece um plano de controle unificado e consistente que se aplica a todos os recursos do Azure e canais de provisionamento, conhecidos como Azure Resource Manager. O plano de controle está sujeito a controles de acesso baseados em função e controles controlados por políticas. Você pode usar esse plano de controle do Azure para estabelecer um conjunto padronizado de políticas e controles que regem todo o seu patrimônio empresarial.

Impacto do desvio

Maior complexidade de integração. Uma abordagem multivendor para planos de controle e gerenciamento pode introduzir uma complexidade de integração e suporte a recursos. Substituir componentes individuais para obter um design "melhor da raça" ou ferramentas de operações multivendor tem limitações e pode causar erros não intencionais devido a dependências inerentes.

Se você estiver utilizando um investimento já existente em ferramentas para operações, segurança ou governança, revise os serviços do Azure e quaisquer dependências.

Modelo de serviço centrado no aplicativo

Concentre-se em migrações e desenvolvimento centrados em aplicativos, em vez de migrações puras de elevação e mudança de infraestrutura, como a movimentação de máquinas virtuais. As opções de design não devem diferenciar entre aplicativos antigos e novos, aplicativos iaaS (infraestrutura como serviço) ou aplicativos PaaS (plataforma como serviço).

Independentemente do modelo de serviço, procure fornecer um ambiente seguro para todos os aplicativos implantados na plataforma do Azure.

Impacto do desvio

• Maior complexidade da política de governança. Se você segmentar cargas de trabalho de forma diferente das opções de implementação da hierarquia do grupo de gerenciamento, aumentará a complexidade nas políticas de governança e nas estruturas de controle de acesso que governam seu ambiente. Exemplos incluem desvio da estrutura de hierarquia organizacional ou agrupamento pelo serviço Azure.

• Aumento da sobrecarga operacional. Essa compensação introduz o risco de duplicação e exceções de política não intencionais, o que aumenta as sobrecargas operacionais e de gerenciamento.

• Desenvolvimento/Teste/Produção é outra abordagem comum que as organizações consideram. Para obter mais informações, consulte Como lidar com zonas de destino de carga de trabalho de "desenvolvimento/teste/produção" na arquitetura da zona de destino do Azure.

Alinhamento com o design e os roteiros nativos do Azure

Use os serviços e funcionalidades da plataforma nativa do Azure sempre que possível. Essa abordagem deve se alinhar aos roteiros da plataforma do Azure para garantir que novos recursos estejam disponíveis em seus ambientes. Os roteiros da plataforma do Azure devem ajudar a informar a estratégia de migração e a trajetória conceitual da zona de destino do Azure.

Impacto do desvio

Maior complexidade de integração. A introdução de soluções de terceiros em seu ambiente do Azure pode criar uma dependência dessas soluções para fornecer suporte a recursos e integração com serviços de primeira parte do Azure.

Às vezes, é inevitável trazer investimentos de soluções de terceiros existentes para um ambiente. Considere esse princípio e suas compensações cuidadosamente para se alinhar às suas necessidades.

Próximas etapas

As organizações podem estar em diferentes estágios de seus percursos na nuvem quando revisarem essas diretrizes. Portanto, as ações e recomendações necessárias para avançar em direção aos resultados anteriores podem variar. Para entender as melhores próximas ações para o estágio de adoção da nuvem, examine o percurso até a arquitetura de destino.

Para escolher a opção certa de implementação da zona de destino do Azure, entenda as áreas de design da zona de destino do Azure.