Abordagens de arquitetura para a implementação e configuração de soluções multi-inquilino

Independentemente da sua arquitetura e dos componentes que utiliza para a implementar, tem de implementar e configurar os componentes da solução. Num ambiente multi-inquilino, é importante considerar a forma como implementa os seus recursos do Azure, especialmente quando implementa recursos dedicados para cada inquilino ou quando reconfigura recursos com base no número de inquilinos no seu sistema. Nesta página, fornecemos orientações aos arquitetos de soluções sobre a implementação de soluções multi-inquilino e demonstramos algumas abordagens a considerar quando planear a sua estratégia de implementação.

Principais considerações e requisitos

É importante ter uma ideia clara dos seus requisitos antes de planear a sua estratégia de implementação. As considerações específicas incluem o seguinte:

• Escala esperada: Espera suportar um pequeno número de inquilinos (por exemplo, cinco ou menos) ou irá aumentar para um grande número de inquilinos?
• Inclusão automatizada ou suportada: Quando um inquilino estiver pronto para ser integrado, poderá concluir o processo por si mesmo ao seguir um procedimento automatizado? Em alternativa, os novos inquilinos iniciam um pedido e integra-os manualmente depois de receber o pedido? Existem passos de aprovação manuais necessários da sua equipa, tais como para evitar o abuso do seu serviço?
• Tempo de aprovisionamento: Quando um inquilino está pronto para ser integrado, qual é a rapidez com que o processo de integração tem de ser concluído? Se não tiver uma resposta clara, considere se esta deve ser medida em segundos, minutos, horas ou dias.
• Azure Marketplace: Planeia utilizar a Azure Marketplace para iniciar a implementação? Se o fizer, existem requisitos que precisa de cumprir para adicionar novos inquilinos.

Também deve considerar os passos de inclusão e aprovisionamento, a automatização e a responsabilidade de gestão de recursos.

Passos de inclusão e aprovisionamento

Considere tudo o que precisa de fazer ao integrar um inquilino e documente esta lista e fluxo de trabalho, mesmo que seja executado manualmente. Normalmente, o fluxo de trabalho de integração inclui o seguinte:

• Aceitação de contratos comerciais.
• Recolha das informações de que precisa para configurar o sistema para o novo inquilino.
• Passos de aprovação manual, por exemplo, para evitar fraudes ou abusos do seu serviço.
• O aprovisionamento de recursos no Azure.
• Criar ou configurar nomes de domínio.
• Execute tarefas de configuração pós-implementação, tais como criar a primeira conta de utilizador para o inquilino e transmitir as respetivas credenciais de forma segura para o inquilino.
• Alterações de configuração manuais, tais como alterações ao registo DNS.

Documente claramente o fluxo de trabalho necessário para integrar um novo inquilino.

Além disso, considere os recursos específicos do Azure que precisa de aprovisionar para um inquilino. Mesmo que não aprovisione recursos dedicados para cada inquilino, considere se, por vezes, precisa de implementar recursos quando um novo inquilino está integrado. Isto pode ocorrer quando um inquilino requer que os respetivos dados sejam armazenados numa região específica ou quando se aproxima dos limites de um carimbo ou componente na sua solução e precisa de criar outra instância para o próximo lote de inquilinos.

Considere se é provável que o processo de integração seja problemático para outros inquilinos, especialmente para aqueles que partilham a mesma infraestrutura. Por exemplo, se precisar de modificar bases de dados partilhadas, este processo poderá causar um impacto no desempenho que outros inquilinos possam notar? Considere se pode evitar estes efeitos ou mitigá-los ao realizar o processo de integração fora do horário normal de funcionamento.

Automatização

As implementações automatizadas são sempre aconselháveis para soluções alojadas na cloud. Ao trabalhar com soluções multi-inquilino, a automatização da implementação torna-se ainda mais importante pelos seguintes motivos:

• Dimensionar: Os processos de implementação manual tornam-se cada vez mais complexos e morosos, à medida que a sua população de inquilinos aumenta. Uma abordagem de implementação automatizada é mais fácil de dimensionar à medida que o número de inquilinos aumenta.
• Repetível: Num ambiente multi-inquilino, utilize um processo consistente para implementações em todos os inquilinos. Os processos manuais introduzem a possibilidade de erro ou os passos que estão a ser executados para alguns inquilinos e não para outros. Estes processos manuais deixam o seu ambiente num estado inconsistente, o que dificulta a gestão da solução pela sua equipa.
• Impacto das interrupções: As implementações manuais são significativamente mais arriscadas e propensas a falhas do que as implementações automatizadas. Num ambiente multi-inquilino, o impacto de uma falha ao nível do sistema (devido a um erro de implementação) pode ser elevado, uma vez que todos os inquilinos podem ser afetados.

Quando implementa num ambiente multi-inquilino, deve utilizar pipelines de implementação e utilizar a infraestrutura como tecnologias de código (IaC), como o Bicep, os modelos arm JSON, o Terraform ou os SDKs do Azure.

Se planeia oferecer a sua solução através do Azure Marketplace, deve fornecer um processo de integração totalmente automatizado para novos inquilinos. Este processo é descrito na documentação das APIs de cumprimento de SaaS.

Capacidade máxima de recursos

Quando implementar programaticamente recursos de inquilino em recursos partilhados, considere o limite de capacidade para cada recurso. Quando se aproximar desse limite, poderá ter de criar outra instância do recurso para suportar um dimensionamento adicional. Considere os limites de cada recurso que implementar e as condições que o irão acionar para implementar outra instância.

Por exemplo, suponha que a sua solução inclui um servidor lógico SQL do Azure e a sua solução aprovisiona uma base de dados dedicada nesse servidor para cada inquilino. Um único servidor lógico tem limites, que incluem um número máximo de bases de dados que um servidor lógico suporta. À medida que se aproxima destes limites, poderá ter de aprovisionar novos servidores para poder continuar a integrar inquilinos. Considere se automatiza este processo ou monitoriza manualmente o crescimento.

Responsabilidade de gestão de recursos

Em algumas soluções multi-inquilino, implementa recursos dedicados do Azure para cada inquilino, como uma base de dados para cada inquilino. Em alternativa, pode decidir um número definido de inquilinos para alojar numa única instância de um recurso, pelo que o número de inquilinos que tem dita o conjunto de recursos que implementa no Azure. Noutras soluções, implementa um único conjunto de recursos partilhados e, em seguida, reconfigura os recursos quando integra novos inquilinos.

Cada um destes modelos requer que implemente e faça a gestão de recursos de diferentes formas e tem de considerar como irá implementar e gerir o ciclo de vida dos recursos que aprovisiona. Duas abordagens comuns são as seguintes:

• Para tratar os inquilinos como a configuração dos recursos que implementa e utilizar os pipelines de implementação para implementar e configurar esses recursos.
• Para tratar os inquilinos como dados e ter um plano de controlo aprovisionar e configurar a infraestrutura para os inquilinos.

Segue-se uma discussão mais aprofundada sobre estas abordagens.

Testar

Planeie testar cuidadosamente a sua solução durante e após cada implementação. Pode utilizar testes automatizados para verificar o comportamento funcional e não funcional da sua solução. Certifique-se de que testa o modelo de isolamento de inquilinos e considere utilizar ferramentas como o Azure Chaos Studio para introduzir deliberadamente falhas que simulam falhas no mundo real e verificar se a solução funciona mesmo quando um componente está indisponível ou com mau funcionamento.

Abordagens e padrões a considerar

Vários padrões de conceção do Centro de Arquitetura do Azure e da comunidade em geral são relevantes para a implementação e configuração de soluções multi-inquilino.

Padrão de Selos de Implementação

O padrão de Selos de Implementação envolve a implementação de uma infraestrutura dedicada para um inquilino ou grupo de inquilinos. Um único selo pode conter vários inquilinos ou pode ser dedicado a um único inquilino. Pode optar por implementar um único selo ou pode coordenar uma implementação em vários selos. Se implementar selos dedicados para cada inquilino, também pode considerar implementar carimbos inteiros programaticamente.

Anéis de implementação

As cadumas de implementação permitem-lhe implementar atualizações para diferentes grupos de infraestrutura em alturas diferentes. Esta abordagem é frequentemente utilizada com o padrão Selos de Implementação e os grupos de selos podem ser atribuídos a anéis distintos com base nas preferências de inquilino, tipos de cargas de trabalho e outras considerações. Para obter mais informações, veja Anéis de implementação.

Sinalizadores de funcionalidades

Os sinalizadores de funcionalidades permitem-lhe expor progressivamente novas funcionalidades ou versões da sua solução a diferentes inquilinos, enquanto mantém um único código base. Considere utilizar Azure App Configuration para gerir os sinalizadores de funcionalidades. Para obter mais informações, veja Sinalizadores de funcionalidades.

Por vezes, tem de ativar seletivamente funcionalidades específicas para determinados clientes. Por exemplo, poderá ter diferentes escalões de preço que permitem o acesso a determinadas capacidades. Normalmente, os sinalizadores de funcionalidades não são a escolha certa para estes cenários. Em vez disso, considere criar um processo para controlar e impor as elegibilidades de licença que cada cliente tem.

Antipadrões a evitar

Quando implementa e configura soluções multi-inquilino, é importante evitar situações que inibam a sua capacidade de dimensionamento. Estes incluem o seguinte:

• Implementação e teste manuais. Conforme descrito acima, os processos de implementação manual adicionam riscos e atrasam a sua capacidade de implementação. Considere a utilização de pipelines para implementações automatizadas, criação programática de recursos a partir do código da solução ou uma combinação de ambos.
• Personalizações especializadas para inquilinos. Evite implementar funcionalidades ou uma configuração que se aplique apenas a um único inquilino. Esta abordagem adiciona complexidade às suas implementações e processos de teste. Em vez disso, utilize os mesmos tipos de recursos e base de código para cada inquilino e utilize estratégias como sinalizadores de funcionalidades para alterações temporárias ou para funcionalidades que são implementadas progressivamente ou utilize diferentes escalões de preço com direitos de licença para ativar seletivamente funcionalidades para inquilinos que os exijam. Utilize um processo de implementação consistente e automatizado, mesmo para inquilinos que tenham recursos isolados ou dedicados.

Listas de inquilinos como configuração ou dados

Pode considerar as duas abordagens seguintes ao implementar recursos numa solução multi-inquilino:

• Utilize um pipeline de implementação automatizado para implementar todos os recursos. À medida que são adicionados novos inquilinos, reconfigure o pipeline para aprovisionar os recursos para cada inquilino.
• Utilize um pipeline de implementação automatizado para implementar recursos partilhados que não dependem do número de inquilinos. Para os recursos que são implementados para cada inquilino, crie-os na sua aplicação.

Ao considerar as duas abordagens, deve distinguir entre tratar a sua lista de inquilinos como uma configuração ou como dados. Esta distinção também é importante quando se considera como criar um plano de controlo para o seu sistema.

Lista de inquilinos como configuração

Quando trata a sua lista de inquilinos como configuração, implementa todos os seus recursos a partir de um pipeline de implementação centralizado. Quando os novos inquilinos são integrados, reconfigura o pipeline ou os respetivos parâmetros. Normalmente, a reconfiguração ocorre através de alterações manuais, conforme ilustrado no diagrama seguinte.

O processo para integrar um novo inquilino pode ser semelhante ao seguinte:

1. Atualize a lista de inquilinos. Normalmente, isto acontece manualmente ao configurar o próprio pipeline ou ao modificar um ficheiro de parâmetros incluído na configuração do pipeline.
2. Acione a execução do pipeline.
3. O pipeline reimplementa o conjunto completo de recursos do Azure, incluindo quaisquer novos recursos específicos do inquilino.

Esta abordagem tende a funcionar bem para um pequeno número de inquilinos e para arquiteturas onde todos os recursos são partilhados. É uma abordagem simples porque todos os seus recursos do Azure podem ser implementados e configurados através de um único processo.

No entanto, quando se aproxima de um número maior de inquilinos, por exemplo, de 5 a 10 ou mais, torna-se complicado reconfigurar o pipeline à medida que adiciona inquilinos. O tempo que demora a executar o pipeline de implementação também aumenta significativamente. Esta abordagem também não suporta facilmente a criação de inquilinos self-service e o tempo de execução antes de um inquilino ser integrado pode ser maior porque tem de acionar o pipeline para ser executado.

Lista de inquilinos como dados

Quando trata a sua lista de inquilinos como dados, continua a implementar os seus componentes partilhados através de um pipeline. No entanto, para recursos e definições de configuração que precisam de ser implementados para cada inquilino, implemente ou configure os seus recursos de forma imperativa. Por exemplo, o plano de controlo pode utilizar os SDKs do Azure para criar um recurso específico ou para iniciar a implementação de um modelo parametrizado.

O processo de integração de um novo inquilino pode ser semelhante ao seguinte e ocorreria de forma assíncrona:

1. Peça que um inquilino seja integrado, como ao iniciar um pedido de API para o plano de controlo do seu sistema.
2. Um componente de fluxo de trabalho recebe o pedido de criação e orquestra os restantes passos.
3. O fluxo de trabalho inicia a implementação de recursos específicos do inquilino no Azure. Isto pode ser conseguido com um modelo de programação imperativo, como através da utilização dos SDKs do Azure ou ao acionar imperativamente a implementação de um modelo bicep ou terraform.
4. Quando a implementação estiver concluída, o fluxo de trabalho guarda os detalhes do novo inquilino no catálogo de inquilinos central. Os dados armazenados para cada inquilino podem incluir o ID do inquilino e os IDs de recursos para todos os recursos específicos do inquilino que o fluxo de trabalho criou.

Ao fazê-lo, pode aprovisionar recursos para novos inquilinos sem reimplementar toda a solução. É provável que o tempo envolvido no aprovisionamento de novos recursos para cada inquilino seja mais curto, porque apenas esses recursos têm de ser implementados.

No entanto, esta abordagem é muitas vezes muito mais demorada para criar e o esforço que gasta tem de ser justificado pelo número de inquilinos ou pelos períodos de tempo de aprovisionamento que precisa de cumprir.

Para obter mais informações sobre esta abordagem, veja Considerações para planos de controlo multi-inquilino.

Exemplo

A Contoso executa uma solução multi-inquilino para os clientes. Atualmente, têm seis inquilinos e esperam crescer para 300 inquilinos nos próximos 18 meses. A Contoso segue a aplicação Multi-inquilino com bases de dados dedicadas para cada abordagem de inquilino. Implementaram um único conjunto de recursos Serviço de Aplicações e um servidor lógico SQL do Azure que são partilhados entre todos os inquilinos e implementam uma base de dados SQL do Azure dedicada para cada inquilino, conforme mostrado no diagrama seguinte.

A Contoso utiliza o Bicep para implementar os respetivos recursos do Azure.

Opção 1 – Utilizar pipelines de implementação para tudo

A Contoso poderá considerar implementar todos os recursos através de um pipeline de implementação. O pipeline implementa um ficheiro Bicep que inclui todos os recursos do Azure, incluindo as bases de dados SQL do Azure para cada inquilino. Um ficheiro de parâmetros define a lista de inquilinos e o ficheiro Bicep utiliza um ciclo de recursos para implementar uma base de dados para cada um dos inquilinos listados, conforme mostrado no diagrama seguinte.

Se a Contoso seguir este modelo, terá de atualizar o respetivo ficheiro de parâmetros como parte da integração de um novo inquilino. Em seguida, têm de executar novamente o pipeline. Além disso, têm de controlar manualmente se estão perto de limites, como se crescessem a uma taxa inesperadamente elevada e se aproximassem do número máximo de bases de dados suportadas num único servidor lógico SQL do Azure.

Opção 2 – Utilizar uma combinação de pipelines de implementação e criação imperativa de recursos

Em alternativa, a Contoso poderá considerar separar a responsabilidade pelas implementações do Azure.

A Contoso utiliza um ficheiro Bicep que define os recursos partilhados que devem ser implementados. Os recursos partilhados suportam todos os respetivos inquilinos e incluem uma base de dados de mapa de inquilinos, conforme mostrado no diagrama seguinte.

Em seguida, a equipa da Contoso cria um plano de controlo que inclui uma API de inclusão de inquilinos. Quando a equipa de vendas tiver concluído a venda a um novo cliente, o Microsoft Dynamics aciona a API para iniciar o processo de integração. A Contoso também fornece uma interface Web self-service para os clientes utilizarem, o que também aciona a API.

A API inicia de forma assíncrona um fluxo de trabalho que integra os novos inquilinos. O fluxo de trabalho inicia a implementação de uma nova base de dados SQL do Azure, o que pode ser feito por uma das seguintes abordagens:

• Utilize o SDK do Azure para iniciar a implementação de um segundo ficheiro Bicep que define a base de dados SQL do Azure.
• Utilize o SDK do Azure para criar imperativamente uma base de dados SQL do Azure com a biblioteca de gestão.

Após a implementação da base de dados, o fluxo de trabalho adiciona o inquilino à base de dados da lista de inquilinos, conforme mostrado no diagrama seguinte.

As atualizações do esquema de base de dados em curso são iniciadas pelo escalão da aplicação.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• John Downs | Engenheiro Principal de Clientes, FastTrack para o Azure

Outros contribuidores:

• Bohdan Cherchyk | Engenheiro Sénior de Clientes, FastTrack para o Azure
• Arsen Vladimirskiy | Engenheiro Principal de Clientes, FastTrack para o Azure

Para ver perfis do LinkedIn não públicos, inicie sessão no LinkedIn.

Passos seguintes

• Reveja as considerações para atualizar uma solução multi-inquilino.
• Considere abordagens de arquitetura para armazenamento e dados.
• Considere como utilizar o Azure Resource Manager numa solução multi-inquilino.