Considerações sobre ISV (fornecedor independente de software) para zonas de destino do Azure
Para muitas organizações, a arquitetura conceitual de zona de destino do Azure representa o destino da jornada de adoção da nuvem. As zonas de destino descrevem como criar um ambiente do Azure com várias assinaturas. Cada zona de destino é responsável pela escala, segurança, governança, rede e identidade e se baseia em comentários e lições aprendidas com muitos clientes.
Dica
Pode ser útil pensar nas zonas de destino do Azure como se fossem planos da cidade. As arquiteturas das cargas de trabalho implantadas em uma zona de destino são como planos para edifícios em uma cidade.
Os sistemas de água, gás, eletricidade e transporte de uma cidade devem ser estabelecidos antes de construir os edifícios. Da mesma forma, os componentes de uma zona de destino do Azure, incluindo grupos de gerenciamento, políticas, assinaturas e RBAC (controle de acesso baseado em função), devem ser estabelecidos antes de implantar as cargas de trabalho de produção.
Como ISV (fornecedor independente de software) que cria e opera a solução no Azure, você deve consultar os seguintes recursos ao criar o ambiente do Azure:
- Zonas de destino do Azure: fornecem as diretrizes para o ambiente geral do Azure.
- Azure Well-Architected Framework: fornece as diretrizes de arquitetura aplicáveis a todas as cargas de trabalho.
- Como criar soluções multilocatárias no Azure: fornece as diretrizes de arquitetura específicas para soluções multilocatárias no Azure.
As zonas de destino do Azure ajudam você a escolher uma direção para o ambiente geral do Azure. Mas como ISV, provedor SaaS ou startup, suas necessidades de implementação específicas podem ser diferentes dos cenários do cliente mais padrão. Veja a seguir alguns exemplos de cenário de implementação diferentes:
- Você cria um software que os clientes implantamo em suas próprias assinaturas.
- Você tem seu próprio painel de controle e usa scripts de automação ou software para implantar e configurar os recursos do Azure para as soluções SaaS.
- Você é um ISV de pequeno porte ou uma startup e deseja começar com o menor custo possível, e talvez não convenha usar inicialmente serviços como o Firewall do Azure e a Proteção contra DDoS do Azure.
- Você é um ISV SaaS de grande porte e planeja dividir o aplicativo SaaS em várias assinaturas para escala. Você também deseja agrupar as assinaturas para que correspondam aos ambientes de desenvolvimento, teste, preparo e produção.
- O modelo operacional da sua organização separa as funções da equipe de TI corporativa e das equipes de produto SaaS. A equipe de TI corporativa da sua organização pode gerenciar recursos como Microsoft Office 365 e Microsoft Teams, e a equipe de produto SaaS pode ser responsável por compilar e operar o produto de SaaS (incluindo a plataforma central e os componentes de identidade).
Observação
Às vezes, convém que os ISVs comecem com apenas uma única assinatura do Azure, que inclui os aspectos de "serviços compartilhados" da plataforma e os recursos reais da carga de trabalho. Embora isso seja tecnicamente possível, você enfrentará desafios posteriormente, quando precisar mover recursos entre assinaturas e descobrir que nem todos os tipos de recursos podem ser movidos. Examine o impacto dos desvios de design, para entender quais desvios são possíveis e os respectivos vários níveis de risco.
Modelos de implantação do ISV
As soluções do ISV geralmente se enquadram em um dos três modelos de implantação: SaaS puro, SaaS implantado pelo cliente ou SaaS de implantação dupla. Esta seção descreve as diferentes considerações de cada modelo para zonas de destino do Azure.
SaaS puro
No modelo de SaaS puro, o software é implantado totalmente apenas nas assinaturas do Azure. Os clientes finais consomem o software sem implantá-lo em suas próprias assinaturas do Azure. No diagrama a seguir, os usuários estão usando um aplicativo SaaS puro fornecido por um ISV:
Os exemplos de software SaaS puro incluem email como serviço, Kafka como serviço, cloud-data-warehouse-as-a-service e muitas listagens de SaaS no Azure Marketplace.
Se você é um ISV SaaS de pequeno porte, talvez não seja necessário usar várias assinaturas do Azure para implantar os recursos imediatamente. Mas à medida que você escala, os limites de assinatura do Azure podem afetar sua capacidade de escalar em uma única assinatura. Examine os princípios de design da zona de destino em escala empresarial, especificamente a democratização da assinatura, e familiarize-se com as abordagens de arquitetura para multilocação, para planejar seu crescimento futuro.
Os ISVs que compilam soluções de SaaS puro devem considerar as seguintes perguntas:
- Todos os recursos do Azure que compõem nossa solução SaaS devem estar em uma assinatura do Azure ou devem ser particionados em várias assinaturas do Azure?
- Devemos hospedar cada cliente em sua própria assinatura dedicada do Azure ou podemos criar recursos em uma ou algumas assinaturas compartilhadas?
- Como podemos aplicar o padrão de Selo de Implantação (unidade de escala) a todas as camadas da nossa solução?
- Como podemos usar a organização de recursos do Azure em soluções multilocatárias para impedir que enfrentemos desafios de escala e limites de assinatura do Azure?
Implantado pelo cliente
No modelo implantado pelo cliente, os clientes finais adquirem o software e implantam em suas próprias assinaturas do Azure. Eles podem iniciar a implantação no Azure Marketplace ou fazê-lo manualmente seguindo as instruções e usando os scripts fornecidos.
No diagrama a seguir, um ISV fornece um pacote de software ou um produto de catálogo do Azure Marketplace e os usuários implantam esse recurso em suas próprias assinaturas do Azure, juntamente com as outras cargas de trabalho:
O outro elemento de carga de trabalho do Cliente no diagrama pode representar a carga de trabalho do próprio cliente ou outro produto do ISV que o cliente implantou na assinatura do Azure. Frequentemente, os clientes implantam vários produtos de ISVs diferentes nas assinaturas do Azure. Eles combinam esses produtos individuais para criar soluções. Por exemplo, um cliente pode implantar um produto de banco de dados de um ISV, um dispositivo virtual de rede de outro ISV e um aplicativo Web de um terceiro ISV.
Os exemplos de produtos do ISV implantados pelo cliente incluem muitas imagens de máquina virtual (como soluções de virtualização de rede e armazenamento) e aplicativos do Azure no Azure Marketplace.
Para algumas soluções implantadas pelo cliente, uma organização pode fornecer gerenciamento e atualizações para a solução implantada nas assinaturas do Azure do cliente final, usando o Azure Lighthouse ou os Aplicativos Gerenciados do Azure. Os ISVs, SIs (Integradores de Soluções) e MSPs (Provedores de Serviços Gerenciados) podem usar essa estratégia quando ela atender a necessidades específicas.
As soluções do ISV implantadas pelo cliente são consideradas uma carga de trabalho de aplicativo padrão do ponto de vista das zonas de destino do Azure. Considere as diretrizes sobre zonas de destino do Azure, à medida que você cria o produto para trabalhar com os princípios de design das zonas de destino do Azure adotados pelos clientes do Azure.
É especialmente importante que você tenha uma boa compreensão dos conceitos de zona de destino do Azure, à medida que migra as cargas de trabalho dos clientes existentes para o Azure.
Os ISVs que compilam soluções implantadas pelo compilar devem considerar as seguintes perguntas:
- Um cliente deve implantar nossa solução em sua própria assinatura dedicada ou em uma assinatura existente que contenha as cargas de trabalho relacionadas?
- Como os clientes devem estabelecer a conectividade de rede entre as cargas de trabalho existentes (dentro e fora do Azure) e nossa solução?
- Nossa solução dá suporte a mecanismos de autenticação do Microsoft Entra ID ou requer outros protocolos, como LDAP ou Kerberos?
- Como reduzir ou eliminar as violações do Azure Policy, como as causadas por conflitos entre nossos modelos de solução e as políticas do Azure de um cliente?
As políticas do Azure do cliente que podem causar violações do Azure Policy incluem exemplos como "Todas as sub-redes devem ter um grupo de segurança de rede" e "Nenhum endereço IP público pode ser anexado a interfaces de rede na zona de destino Corp". Lembre-se do potencial dessas políticas causadoras de conflito, enquanto planeja a implantação.
SaaS de implantação dupla
Algumas soluções SaaS usam ou interagem com os recursos implantados nas assinaturas do Azure dos clientes. Às vezes, esse modelo de implantação é chamado de SaaS de implantação dupla ou SaaS híbrido. No diagrama a seguir, um ISV fornece uma solução SaaS hospedada que interage com os recursos implantados na assinatura do Azure de um cliente final:
Um exemplo real de SaaS de implantação dupla é o Microsoft Power BI, um serviço SaaS que pode, opcionalmente, usar um gateway de dados local do Power BI implantado em uma máquina virtual na assinatura do Azure de um cliente.
Outros exemplos de cenários de SaaS de implantação dupla incluem:
- Sua organização compila o Gerenciador da Área de Trabalho Virtual, um produto que fornece uma interface de console SaaS para controlar os recursos da Área de Trabalho Virtual do Azure na assinatura do Azure de cada cliente.
- Sua organização fornece um console SaaS para análise de dados e cria e exclui dinamicamente máquinas virtuais de nó de computação na assinatura do Azure de cada cliente.
Como ISV de implantação dupla, você deve consultar a zona de destino do Azure para obter diretrizes em duas áreas: estruturar seu próprio ambiente do Azure para hospedar o serviço SaaS e garantir a interação adequada entre as implantações nas assinaturas do Azure dos clientes e as zonas de destino dos clientes.
Os ISVs que compilam soluções de SaaS de implantação dupla devem considerar as seguintes perguntas:
- Examinamos todas as considerações para compilar as soluções de SaaS puro e implantadas pelo cliente?
- Quais componentes da nossa solução devem ser hospedados em nossas assinaturas do Azure e quais componentes devem ser implantados pelo cliente?
- Como podemos garantir a segurança do provisionamento e das interações com os recursos implantados nas assinaturas do Azure de nossos clientes?
Princípios de design e implementações da zona de destino do Azure
Os princípios de design da zona de destino do Azure recomendam o alinhamento com os recursos de plataforma nativos do Azure, como o Log Analytics, Azure Monitor e Firewall do Azure. As diretrizes de zona de destino também fornecem opções específicas de implementação de zona de destino do Azure.
Como ISV, você pode decidir implementar seus próprios ambientes de zona de destino. Talvez convenha usar sua própria automação para implantar os recursos do Azure nas assinaturas. Ou talvez você queira continuar usando as ferramentas que já emprega para log, monitoramento e outros serviços de camada de plataforma.
Se você implementar seus próprios ambientes de zona de destino, recomendamos que use as diretrizes e implementações de exemplo da zona de destino do Azure para referência e alinhe sua abordagem com os designs comprovados da zona de destino do Azure.
Locatários do Microsoft Entra
Cada zona de destino do Azure e sua hierarquia de grupo de gerenciamento estão enraizadas em um único locatário do Microsoft Entra. Isso significa que a primeira decisão que você precisa tomar é qual locatário do Microsoft Entra usar como fonte de identidades para gerenciar seus recursos do Azure. As identidades na ID do Microsoft Entra incluem usuários, grupos e entidades de serviço.
Dica
O locatário do Microsoft Entra selecionado para sua zona de destino não afeta a autenticação no nível do aplicativo. Você ainda pode usar outros provedores de identidade, como o Azure AD B2C, independentemente do locatário escolhido.
As diretrizes para zonas de destino do Azure e locatários do Microsoft Entra recomendam fortemente o uso de um único locatário do Microsoft Entra, e essa é a abordagem correta para a maioria das situações. No entanto, como ISV SaaS, você pode ter motivos para usar dois locatários.
Para alguns ISVs SaaS, uma equipe gerencia os recursos corporativos e uma equipe separada opera a solução SaaS. Essa separação pode ser por motivos operacionais ou para atender a requisitos regulatórios. Talvez sua equipe de TI corporativa não tenha permissão para gerenciar assinaturas e recursos relacionados a SaaS, portanto, eles não podem ser administradores do locatário do Microsoft Entra. Se esse cenário se aplicar a você, considere usar dois locatários separados do Microsoft Entra: um locatário para recursos de TI corporativos, como o Office 365, e um locatário para recursos do Azure que compõem sua solução SaaS.
Cada locatário do Microsoft Entra deve ter seu próprio nome de domínio. Se sua organização usa dois locatários, você pode escolher um nome como contoso.com para seu locatário corporativo do Microsoft Entra e contoso-saas-ops.com para seu locatário SaaS do Microsoft Entra, conforme mostrado no diagrama a seguir.
Aviso
Quando você usa vários locatários do Microsoft Entra, sua sobrecarga de gerenciamento aumenta. Se você usar recursos P1 ou P2 da ID do Microsoft Entra, como o Privileged Identity Management, precisará comprar licenças individuais para cada locatário do Microsoft Entra. É melhor usar apenas vários locatários do Microsoft Entra se sua situação realmente exigir.
Evite usar locatários separados do Microsoft Entra para ambientes de pré-produção e produção. Em vez de criar dois locatários como contoso-saas-ops-preprod.com e contoso-saas-ops-prod.com com assinaturas separadas do Azure em cada um, você deve criar um locatário do Microsoft Entra. Você pode usar os grupos de gerenciamento e a RBAC do Azure para controlar o acesso a assinaturas e recursos nesse locatário único.
Para obter mais informações sobre o uso de vários locatários do Microsoft Entra, consulte Zonas de destino do Azure e vários locatários do Microsoft Entra e isolamento de recursos com vários locatários.
Grupos de gerenciamento
A arquitetura conceitual de zona de destino do Azure recomenda o uso de uma hierarquia de grupo de gerenciamento específica. No entanto, os ISVs podem ter requisitos diferentes de outras organizações. Esta seção descreve algumas maneiras em que a organização do ISV pode optar por adotar práticas diferentes das recomendadas pela arquitetura conceitual de zona de destino.
Grupo de gerenciamento de nível superior
A hierarquia de grupo de gerenciamento está aninhada no grupo de gerenciamento Grupo raiz do locatário criado pelo Azure. Você não usará o Grupo raiz do locatário diretamente.
Uma organização padrão, que tem uma equipe de TI corporativa centralizada que gerencia a plataforma e os serviços compartilhados (como log, rede, identidade e segurança), geralmente cria um grupo de gerenciamento de nível superior no Grupo raiz do locatário criado pelo Azure e implanta o restante dos grupos de gerenciamento abaixo dele. Esse grupo de gerenciamento de nível superior geralmente tem o nome da própria organização (como Contoso).
Como ISV SaaS, você pode ter um produto SaaS, alguns produtos SaaS separados ou linhas de negócios. Embora você geralmente deva usar o mesmo locatário do Microsoft Entra para gerenciar recursos do Azure em todos os seus produtos (conforme discutido na seção de locatários do Microsoft Entra), em alguns cenários, você pode optar por implantar várias hierarquias de grupo de gerenciamento.
Considere se os produtos são independentes uns dos outros e pergunte a si mesmo o seguinte:
- Todos os nossos produtos usam as mesmas plataformas para DevOps, identidade, segurança, conectividade e log?
- Esses serviços compartilhados são operados por uma única equipe central?
Se você respondeu sim a ambas as perguntas, crie um único grupo de gerenciamento de nível superior Produto SaaS no Grupo raiz do locatário.
Se você respondeu não e cada um dos produtos SaaS é gerenciado e operado por equipes de plataforma separadas, crie um grupo de gerenciamento de nível superior separado para cada produto, como os dois grupos de gerenciamento de nível superior SaaS Product-01 e SaaS Product-02.
Dica
É incomum que um ISV tenha mais do que apenas alguns grupos de gerenciamento de nível superior. Muitas vezes, vários produtos podem ser combinados juntos devido a semelhanças na forma como são gerenciados e operados.
Essa abordagem de gerenciamento é semelhante à abordagem de teste para zonas de destino em escala empresarial. No entanto, em vez de criar Contoso e Contoso-Canary no Grupo raiz do locatário, nessa abordagem, a empresa de exemplo criaria os grupos de gerenciamento de nível superior específicos do produto Contoso-SaaS-Product-01, Contoso-SaaS-Product-02 e Contoso-SaaS-Product-03. Este cenário é ilustrado no seguinte diagrama:
Grupo de gerenciamento Plataforma
Na hierarquia de organização de recursos da zona de destino do Azure, o grupo de gerenciamento Plataforma contém todas as assinaturas do Azure que hospedam os componentes e serviços compartilhados, usados pelas cargas de trabalho nas assinaturas da zona de destino. Os exemplos de componentes implantados nas assinaturas de plataforma e serviços compartilhados incluem infraestrutura de log centralizada (como workspaces do Log Analytics), DevOps, segurança, ferramentas de automação, recursos de rede central (como planos de VNet de hub e Proteção contra DDos) e serviços de painel de controle do ISV.
Frequentemente, o grupo de gerenciamento Plataforma é particionado nos grupos filho Identidade, Gerenciamento e Conectividade, para fornecer uma separação prática de funções e políticas para clientes corporativos.
Em sua organização, você pode ter uma única equipe que gerencia todos os componentes de plataforma compartilhados, como identidade, rede e gerenciamento. Nesse caso, e se você não tiver planos de separar esse gerenciamento em várias equipes, use um único grupo de gerenciamento Plataforma.
Se, em vez disso, você tiver equipes separadas que gerenciam diferentes partes da plataforma centralizada, você deve implantar níveis adicionais na hierarquia de grupo de gerenciamento Plataforma. Isso permite que você atribua políticas separadas para cada parte da plataforma centralizada.
O diagrama a seguir ilustra duas possíveis implementações do grupo de gerenciamento Plataforma. A opção A mostra um cenário mais abrangente, em que o grupo de gerenciamento Plataforma contém três grupos de gerenciamento filho: Gerenciamento e DevOps, Identidade e Segurança e Conectividade. Cada grupo de gerenciamento filho contém uma assinatura com os recursos relevantes. A opção B mostra um cenário mais simples, em que o grupo de gerenciamento Plataforma contém uma única assinatura de plataforma.
Grupo de gerenciamento Zonas de Destino
O grupo de gerenciamento Zonas de Destino contém as assinaturas do Azure que hospedam os subsistemas e as cargas de trabalho reais da solução SaaS.
Esse grupo de gerenciamento contém um ou mais grupos de gerenciamento filho. Cada um dos grupos de gerenciamento filho em Zonas de Destino representa um arquétipo de carga de trabalho ou subsistema, com requisitos consistentes de política e acesso que devem ser aplicados a todas as assinaturas. Os motivos para usar vários arquétipos incluem:
- Conformidade: se um subsistema do produto SaaS precisa estar em conformidade com PCI-DSS, crie um grupo de gerenciamento filho do arquétipo PCI DSS, em Zonas de Destino. Todas as assinaturas do Azure que contêm recursos dentro do escopo de conformidade com PCI-DSS devem ser colocadas nesse grupo de gerenciamento.
- Camadas: crie os arquétipos de zona de destino separados para os clientes da camada dedicada da solução SaaS e para os clientes da camada gratuita. Cada um dos grupos de gerenciamento filho contém configurações diferentes do Azure Policy. Por exemplo, as políticas na camada gratuita podem restringir as implantações a habilitar apenas os SKUs de máquina virtual específicos e as políticas na camada dedicada podem exigir que os recursos sejam implantados em regiões específicas.
Grupos de gerenciamento específicos do ambiente
Geralmente, os ISVs SaaS organizam os ambientes de nuvem modelando os ambientes de ciclo de vida de desenvolvimento de software sequencialmente. Normalmente, isso exige implantar primeiro em um ambiente de Desenvolvimento, depois em um ambiente de Teste, em seguida, em um ambiente de Preparo e, por fim, em um ambiente de Produção.
Uma diferença comum entre os ambientes são as regras de RBAC do Azure, por exemplo, quem pode acessar cada grupo de assinaturas. Por exemplo, as equipes de DevOps, SaaSOps, desenvolvimento e teste podem ter níveis diferentes de acesso a ambientes diferentes.
Importante
A maioria dos clientes do Azure tem centenas de aplicativos e usa assinaturas separadas do Azure para cada equipe de aplicativos. Se cada aplicativo tivesse seus próprios grupos de gerenciamento de desenvolvimento, teste, preparo e produção, haveria um grande número de grupos de gerenciamento com políticas quase idênticas. Para a maioria dos clientes, as Perguntas Frequentes sobre Zona de Destino em Escala Empresarial aconselham o uso de grupos de gerenciamento separados para cada ambiente. Em vez disso, é recomendável o uso de assinaturas separadas em um único grupo de gerenciamento.
No entanto, os ISVs SaaS podem ter requisitos diferentes da maioria dos outros clientes do Azure e podem ter um bom motivo para usar grupos de gerenciamento específicos do ambiente em algumas situações.
Às vezes, os ISVs SaaS precisam agrupar várias assinaturas que representam fragmentos ou partições do mesmo subsistema, aplicativo ou carga de trabalho. Talvez seja necessário aplicar políticas ou atribuições de função a grupos de assinaturas de uma maneira visivelmente diferente do grupo de gerenciamento de arquétipo. Nesse caso, crie grupos de gerenciamento filho que correspondem a cada ambiente no grupo de gerenciamento de arquétipo.
Os diagramas a seguir ilustram duas opções possíveis. A opção A mostra um cenário com assinaturas separadas para cada ambiente, mas sem grupos de gerenciamento específicos do ambiente. A opção B mostra um cenário de ISV SaaS com grupos de gerenciamento específicos do ambiente no grupo de gerenciamento Selos regulares. Cada grupo de gerenciamento específico do ambiente contém várias assinaturas. Com o tempo, o ISV escala os recursos do Azure em cada ambiente em um número crescente de assinaturas, com um conjunto comum de políticas e atribuições de função.
Selecione cada guia para ver os dois diagramas.
Grupos de gerenciamento Desativados e Área Restrita
As diretrizes de organização de recursos da zona de destino do Azure recomendam incluir os grupos de gerenciamento Desativados e Área Restrita diretamente abaixo do grupo de gerenciamento de nível superior.
O grupo de gerenciamento Desativados é um local provisório para assinaturas do Azure que estão sendo desabilitadas e serão excluídas eventualmente. Você pode mover uma assinatura que não está mais em uso para esse grupo de gerenciamento, para rastreá-la até que todos os recursos na assinatura sejam excluídos permanentemente.
O grupo de gerenciamento de áreas restritas geralmente contém assinaturas do Azure que são usadas para fins de exploração e têm políticas soltas ou nenhuma política aplicada a elas. Por exemplo, você pode fornecer aos desenvolvedores individuais suas próprias assinaturas para desenvolvimento e teste. Você pode evitar aplicar as políticas normais e a governança a essas assinaturas, colocando-as no grupo de gerenciamento Área Restrita. Isso aumenta a agilidade dos desenvolvedores e permite fazer experimentos facilmente com o Azure.
Importante
As assinaturas no grupo de gerenciamento de áreas restritas não devem ter conectividade direta com as assinaturas da zona de destino. Evite conectar as assinaturas de área restrita com as cargas de trabalho de produção ou os ambientes de não produção que espelham os ambientes de produção.
O diagrama a seguir ilustra duas opções possíveis. A opção A não inclui os grupos de gerenciamento Desativados e Área Restrita, enquanto a opção B inclui.
Exemplo de zonas de destino do ISV
Esta seção inclui dois exemplos de estruturas de zona de destino do Azure para um ISV SaaS. Selecione cada guia para comparar os dois exemplo de zonas de destino.
O diagrama a seguir mostra um exemplo de hierarquia de zonas de destino do Azure do ISV SaaS com as seguintes características:
- O ISV mantém todos os componentes da plataforma em uma única assinatura do Azure, em vez de dividi-los em vários grupos de gerenciamento de plataforma.
- Existe apenas um grupo de gerenciamento de zona de destino.
- A zona de destino inclui grupos de gerenciamento específicos do ambiente para organizar assinaturas e atribuir diferentes políticas e funções.
- O ISV não incluiu os grupos de gerenciamento para assinaturas desativadas e de área restrita.
Próximas etapas
- Se você estiver compilando uma solução multilocatária, saiba mais sobre Como criar soluções multilocatárias no Azure.
- Saiba mais sobre O que é uma zona de destino do Azure.
- Saiba mais sobre Áreas de design da zona de destino do Azure.