Considerações sobre ISV (fornecedor independente de software) para zonas de aterrissagem do Azure
Para muitas organizações, a arquitetura conceitual das zonas de aterrissagem do Azure representa o destino de sua jornada de adoção da nuvem. As zonas de aterrissagem descrevem como criar um ambiente do Azure com várias assinaturas. Cada zona de aterrissagem leva em conta escala, segurança, governança, rede e identidade, e é baseada em feedback e lições aprendidas de muitos clientes.
Gorjeta
Pode ser útil pensar nas zonas de aterrissagem do Azure como sendo como planos de cidade. As arquiteturas de cargas de trabalho implantadas em uma zona de pouso são como planos para edifícios em uma cidade.
Os sistemas de água, gás, eletricidade e transporte de uma cidade devem estar em funcionamento antes que os edifícios possam ser construídos. Da mesma forma, os componentes de uma zona de aterrissagem do Azure, incluindo grupos de gerenciamento, políticas, assinaturas e RBAC (controle de acesso baseado em função), todos devem estar em vigor antes que qualquer carga de trabalho de produção possa ser implantada.
Como um fornecedor de software independente (ISV) criando e operando sua solução no Azure, você deve consultar os seguintes recursos ao criar seu ambiente do Azure:
- Zonas de aterrissagem do Azure: fornece orientação para seu ambiente geral do Azure.
- Azure Well-Architected Framework: fornece orientação arquitetônica aplicável a todas as cargas de trabalho.
- Arquitetando soluções multilocatárias no Azure: fornece orientação arquitetônica específica para soluções multilocatárias no Azure.
As zonas de aterrissagem do Azure ajudam você a escolher uma direção para seu ambiente geral do Azure. Mas, como um ISV, provedor de SaaS ou startup, suas necessidades específicas de implementação podem diferir de cenários de clientes mais padrão. A seguir estão apenas alguns exemplos diferentes de cenários de implementação:
- Você cria software que os clientes implantam em suas próprias assinaturas.
- Você tem seu próprio plano de controle e usa scripts de automação ou software para implantar e configurar recursos do Azure para suas soluções SaaS.
- Você é um pequeno ISV ou startup e deseja começar com o menor custo possível, e talvez não queira usar inicialmente serviços como o Firewall do Azure e a Proteção contra DDoS do Azure.
- Você é um grande ISV SaaS e planeja dividir seu aplicativo SaaS em várias assinaturas para escala. Você também deseja agrupar as assinaturas para que elas correspondam aos seus ambientes de desenvolvimento, teste, preparação e produção.
- O modelo operacional da sua organização separa as funções da sua equipe de TI corporativa e das equipes de produtos SaaS. A equipe de TI corporativa da sua organização pode gerenciar recursos como o Microsoft Office 365 e o Microsoft Teams, e sua equipe de produto SaaS pode ser responsável por criar e operar seu produto SaaS (incluindo sua plataforma central e componentes de identidade).
Nota
Às vezes, os ISVs querem começar com apenas uma única assinatura do Azure que inclui aspetos de "serviços compartilhados" da plataforma e recursos reais de carga de trabalho. Embora isso seja tecnicamente possível, você enfrentará desafios mais tarde quando precisar mover recursos entre assinaturas e descobrir que nem todos os tipos de recursos podem ser movidos. Analise o impacto dos desvios de projeto para entender quais desvios são possíveis e seus vários níveis de risco.
Modelos de implantação de ISV
As soluções ISV geralmente se encaixam em um dos três modelos de implantação: SaaS puro, implantado pelo cliente ou SaaS de implantação dupla. Esta seção descreve as diferentes considerações de cada modelo para zonas de aterrissagem do Azure.
SaaS puro
No modelo SaaS puro, seu software é implantado totalmente somente em suas assinaturas do Azure. Os clientes finais consomem seu 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:
Exemplos de software SaaS puro incluem email como serviço, Kafka-as-a-service, cloud-data-warehouse-as-a-service e muitas listagens SaaS no Azure Marketplace.
Se você for um pequeno ISV SaaS, talvez não precise usar várias assinaturas do Azure para implantar seus recursos imediatamente. Mas, à medida que você dimensiona, os limites de assinatura do Azure podem afetar sua capacidade de dimensionar em uma única assinatura. Analise os princípios de design da zona de aterrissagem em escala empresarial, particularmente a democratização da assinatura, e familiarize-se com as abordagens arquitetônicas para multilocação para planejar seu crescimento futuro.
ISVs construindo soluções SaaS puras 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 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 Deployment Stamp (unidade de escala) a todos os níveis da nossa solução?
- Como podemos usar a organização de recursos do Azure em soluções multilocatárias para evitar que enfrentemos desafios de escala e limites de assinatura do Azure?
Implantado pelo cliente
No modelo implantado pelo cliente, seus clientes finais compram software de você e o implantam em suas próprias assinaturas do Azure. Eles podem iniciar a implantação a partir do Azure Marketplace ou fazê-lo manualmente seguindo instruções e usando 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 junto com suas outras cargas de trabalho:
O outro elemento de carga de trabalho do Cliente no diagrama pode representar a própria carga de trabalho de um cliente ou outro produto ISV que o cliente implantou em sua assinatura do Azure. Os clientes frequentemente implantam vários produtos de ISVs diferentes em suas 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.
Exemplos de produtos ISV implantados pelo cliente incluem as muitas imagens de máquina virtual (como dispositivos virtuais 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 em suas assinaturas do Azure do cliente final usando o Azure Lighthouse ou os Aplicativos Gerenciados do Azure. ISVs, integradores de soluções (SIs) e provedores de serviços gerenciados (MSPs) podem usar essa estratégia quando ela atende às suas necessidades específicas.
As soluções ISV implantadas pelo cliente são consideradas uma carga de trabalho de aplicativo padrão da perspetiva das zonas de aterrissagem do Azure. Considere as diretrizes de zonas de aterrissagem do Azure ao projetar seu produto para trabalhar com os princípios de design de zonas de aterrissagem do Azure que seus clientes do Azure adotam.
É especialmente importante que você tenha uma boa compreensão dos conceitos de zona de aterrissagem do Azure ao migrar as cargas de trabalho de seus clientes existentes para o Azure.
Os ISVs que criam soluções implantadas pelo cliente 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 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?
- A nossa solução suporta mecanismos de autenticação a partir do Microsoft Entra ID ou requer outros protocolos como LDAP ou Kerberos?
- Como reduzimos ou eliminamos violações da Política do Azure, como aquelas 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 da Política do Azure 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 aterrissagem Corp". Tenha em mente o potencial dessas políticas causadoras de conflitos ao planejar sua implantação.
SaaS de implantação dupla
Algumas soluções SaaS interagem ou usam recursos implantados nas assinaturas do Azure dos clientes. Esse modelo de implantação às vezes é 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 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 SaaS de implantação dupla incluem:
- Sua organização cria o Virtual Desktop Manager, 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 um ISV de implantação dupla, você deve consultar a zona de aterrissagem do Azure para obter orientação em duas áreas: estruturar seu próprio ambiente do Azure para hospedar seu serviço SaaS e garantir a interação adequada entre suas implantações nas assinaturas do Azure dos clientes e as zonas de aterrissagem dos clientes.
ISVs que criam soluções SaaS de implantação dupla devem considerar as seguintes perguntas:
- Revisamos todas as considerações para a criação de SaaS puro e soluções implantadas pelo cliente?
- Quais componentes de nossa solução devem ser hospedados em nossas assinaturas do Azure e quais componentes devem ser implantados pelo cliente?
- Como podemos garantir o provisionamento seguro e as interações com os recursos implantados nas assinaturas do Azure de nossos clientes?
Princípios e implementações de design da zona de aterrissagem do Azure
Os princípios de design da zona de aterrissagem do Azure recomendam o alinhamento com os recursos da plataforma nativa do Azure, como o Log Analytics, o Azure Monitor e o Azure Firewall. A orientação da zona de aterrissagem também fornece opções específicas de implementação da zona de aterrissagem do Azure.
Como um ISV, você pode decidir implementar seus próprios ambientes de zona de pouso. Talvez seja necessário usar sua própria automação para implantar recursos do Azure em assinaturas. Ou talvez você queira continuar usando ferramentas que já emprega para registro, monitoramento e outros serviços de camada de plataforma.
Se você implementar seus próprios ambientes de zona de aterrissagem, recomendamos que use a orientação de zona de aterrissagem do Azure e implementações de exemplo para referência e alinhe sua abordagem com designs comprovados de zona de aterrissagem do Azure.
Locatários do Microsoft Entra
Cada zona de aterrissagem 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.
Gorjeta
O locatário do Microsoft Entra selecionado para sua zona de destino não afeta sua 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.
A orientação para zonas de aterrissagem do Azure e locatários do Microsoft Entra recomenda 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 um ISV SaaS, você pode ter motivos para usar dois locatários.
Para alguns ISVs SaaS, uma equipe gerencia recursos corporativos e uma equipe separada opera a solução SaaS. Esta separação pode ser feita por razões operacionais ou para cumprir requisitos regulamentares. 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 os recursos do Microsoft Entra ID P1 ou P2, 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 do Azure separadas em cada um, você deve criar um locatário do Microsoft Entra. Você pode usar grupos de gerenciamento e o RBAC do Azure para controlar o acesso a assinaturas e recursos sob esse único locatário.
Para obter mais informações sobre o uso de vários locatários do Microsoft Entra, consulte Zonas de aterrissagem do Azure e vários locatários do Microsoft Entra e isolamento de recursos com vários locatários.
Grupos de gestão
A arquitetura conceitual da zona de aterrissagem 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 pelas quais sua organização ISV pode optar por adotar práticas diferentes das recomendadas pela arquitetura conceitual da zona de pouso.
Grupo de gestão de nível superior
Sua hierarquia de grupo de gerenciamento está aninhada no grupo de gerenciamento de grupo raiz de locatário criado pelo Azure. Você não usa o grupo raiz do locatário diretamente.
Uma organização padrão que tem uma equipe de TI corporativa centralizada gerenciando sua plataforma e serviços compartilhados (como log, rede, identidade e segurança) geralmente cria um grupo de gerenciamento de nível superior no grupo raiz de Locatário criado pelo Azure e implanta o restante de seus grupos de gerenciamento abaixo dele. Esse grupo de gerenciamento de nível superior geralmente leva o nome da própria organização (como Contoso).
Como um ISV SaaS, você pode ter um produto SaaS ou 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 locatários do Microsoft Entra), em alguns cenários você pode optar por implantar várias hierarquias de grupo de gerenciamento.
Considere o quão independentes os seus produtos são uns dos outros e pergunte-se:
- Todos os nossos produtos usam as mesmas plataformas para DevOps, identidade, segurança, conectividade e registro?
- Esses serviços partilhados são operados por uma única equipa central?
Se você respondeu sim a ambas as perguntas, crie um único grupo de gerenciamento de produtos SaaS de nível superior no grupo raiz do locatário.
Se, em vez disso, você respondeu que não, e cada um dos seus produtos SaaS é gerenciado e operado por equipes de plataforma separadas, considere criar 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.
Gorjeta
É incomum que um ISV tenha mais do que apenas alguns grupos de gerenciamento de alto nível. Muitas vezes, vários produtos podem ser combinados devido a semelhanças na forma como são geridos e operados.
Essa abordagem de gerenciamento é semelhante à abordagem de teste para zonas de pouso 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 sob ele. Este cenário é ilustrado no diagrama a seguir:
Grupo de gestão da plataforma
Na hierarquia da organização de recursos da zona de aterrissagem do Azure, o grupo de gerenciamento de Plataforma contém todas as assinaturas do Azure que hospedam componentes e serviços compartilhados usados por cargas de trabalho nas assinaturas da zona de aterrissagem. Exemplos de componentes implantados na plataforma e assinaturas de serviços compartilhados incluem infraestrutura de registro centralizado (como espaços de trabalho do Log Analytics), DevOps, segurança, ferramentas de automação, recursos de rede central (como planos de proteção contra DDos e hub-VNet) e serviços de plano de controle de um ISV.
O grupo de gerenciamento de plataforma é frequentemente particionado em grupos filhos de Identidade, Gerenciamento e Conectividade para fornecer separação conveniente de funções e políticas para clientes corporativos.
Em sua organização, você pode ter uma única equipe que gerencia todos os componentes da plataforma compartilhada, como identidade, rede e gerenciamento. Em caso afirmativo, e se você não tiver planos de separar esse gerenciamento em várias equipes, considere usar um único grupo de gerenciamento de plataforma .
Se, em vez disso, você tiver equipes separadas que gerenciam diferentes partes de sua plataforma centralizada, deverá implantar outros níveis na hierarquia do grupo de gerenciamento sob o grupo de gerenciamento de plataforma . Isso permite que você atribua políticas separadas para cada parte da sua plataforma centralizada.
O diagrama a seguir ilustra duas implementações potenciais do grupo de gerenciamento de plataforma . A opção A mostra um cenário mais abrangente, onde o grupo de gerenciamento de 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 de plataforma contém uma única assinatura de plataforma.
Grupo de gestão das Zonas de Desembarque
O grupo de gerenciamento Landing Zones contém as assinaturas do Azure que hospedam os subsistemas e cargas de trabalho reais da sua solução SaaS.
Este grupo de gestão contém um ou mais grupos de gestão de filhos. Cada um dos grupos de gerenciamento filho em Zonas de aterrissagem representa um arquétipo de carga de trabalho ou subsistema, com políticas consistentes e requisitos de acesso que devem ser aplicados a todas as assinaturas. As razões para usar vários arquétipos incluem:
- Conformidade: Se um subsistema do seu produto SaaS precisar ser compatível com PCI-DSS, considere a criação de um grupo de gerenciamento filho de arquétipo PCI DSS em Zonas de aterrissagem. Todas as assinaturas do Azure que contêm recursos dentro do escopo de conformidade com PCI-DSS devem ser colocadas dentro desse grupo de gerenciamento.
- Níveis: considere a criação de arquétipos de zona de aterrissagem separados para os clientes de nível dedicado e os clientes de nível gratuito da sua solução SaaS. Cada um dos grupos de gerenciamento filho contém diferentes configurações de Política do Azure. Por exemplo, as políticas na camada livre podem restringir as implantações para habilitar apenas SKUs de máquinas virtuais específicas, e as políticas na camada dedicada podem exigir que os recursos sejam implantados em regiões específicas.
Grupos de gestão específicos do ambiente
Os ISVs SaaS geralmente organizam seus ambientes de nuvem modelando seus ambientes de ciclo de vida de desenvolvimento de software em uma sequência. Isso geralmente requer implantação primeiro em um ambiente de desenvolvimento , depois em um ambiente de teste , depois em um ambiente de preparo e, finalmente, em um ambiente de produção .
Uma diferença comum entre os ambientes são as regras do RBAC do Azure, como quem pode acessar cada grupo de assinaturas. Por exemplo, as equipes de DevOps, SaaSOps, desenvolvimento e teste podem ter diferentes níveis 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, preparação 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 a zona de aterrissagem em escala empresarial desaconselham o uso de grupos de gerenciamento separados para cada ambiente. Em vez disso, recomenda o uso de assinaturas separadas dentro de um único grupo de gerenciamento.
No entanto, os ISVs SaaS podem ter requisitos diferentes da maioria dos outros clientes do Azure e podem ter bons motivos para usar grupos de gerenciamento específicos do ambiente em algumas situações.
ISVs SaaS às vezes 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 que no grupo de gerenciamento de arquétipo. Nesse caso, considere a criação de grupos de gerenciamento filho que correspondam a cada ambiente sob o grupo de gerenciamento de arquétipo.
Os diagramas a seguir ilustram duas opções potenciais. 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 de carimbos regulares. Cada grupo de gerenciamento específico do ambiente contém várias assinaturas. Com o tempo, o ISV dimensiona seus 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 de descomissionados e Sandboxes
A orientação da organização de recursos da zona de aterrissagem do Azure recomenda incluir grupos de gerenciamento Descomissionados e Sandboxes diretamente abaixo do seu grupo de gerenciamento de nível superior.
O grupo de gerenciamento Descomissionado é um local de retenção para assinaturas do Azure que estão sendo desabilitadas e eventualmente serão excluídas. 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 da assinatura sejam excluídos permanentemente.
O grupo de gerenciamento de Sandboxes geralmente contém assinaturas do Azure que são usadas para fins de exploração e têm políticas soltas ou nenhuma aplicada a elas. Por exemplo, você pode fornecer a desenvolvedores individuais suas próprias assinaturas para desenvolvimento e teste. Você pode evitar aplicar as políticas e a governança normais a essas assinaturas colocando-as no grupo de gerenciamento de Sandboxes . Isso aumenta a agilidade dos desenvolvedores e permite que eles experimentem facilmente o Azure.
Importante
As assinaturas no grupo de gerenciamento de Sandboxes não devem ter conectividade direta com as assinaturas da zona de destino. Evite conectar assinaturas de área restrita a cargas de trabalho de produção ou a ambientes que não sejam de produção que espelhem ambientes de produção.
O diagrama a seguir ilustra duas opções potenciais. A opção A não inclui os grupos de gerenciamento Descomissionado e Sandbox, enquanto a opção B inclui.
Exemplo de zonas de aterragem de ISV
Esta seção inclui dois exemplos de estruturas de zona de aterrissagem do Azure para um ISV SaaS. Selecione cada guia para comparar as duas zonas de pouso de exemplo.
O diagrama a seguir mostra um exemplo de hierarquia de zonas de aterrissagem do Azure ISV SaaS com as seguintes características:
- O ISV mantém todos os seus componentes de 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 gestão da zona de desembarque.
- A zona de aterrissagem 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 sandbox.
Próximos passos
- Se você estiver criando uma solução multilocatário, saiba mais sobre como arquitetar soluções multilocatárias no Azure.
- Saiba o que é uma zona de aterrissagem do Azure.
- Saiba mais sobre as áreas de design da zona de aterrissagem do Azure.