Abordagens arquitetônicas para a implantação e configuração de soluções multilocatárias

Independentemente da sua arquitetura e dos componentes que você usa para implementá-la, você precisa implantar e configurar os componentes da sua solução. Em um ambiente multilocatário, é importante considerar como você implanta seus recursos do Azure, especialmente quando implanta recursos dedicados para cada locatário ou quando reconfigura recursos com base no número de locatários em seu sistema. Nesta página, fornecemos aos arquitetos de soluções orientações sobre a implantação de soluções multilocatárias e demonstramos algumas abordagens a serem consideradas ao planejar sua estratégia de implantação.

Principais considerações e requisitos

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

• Escala esperada: Você espera suportar um pequeno número de inquilinos (como cinco ou menos) ou vai crescer para um grande número de inquilinos?
• Integração automatizada ou suportada: Quando um locatário estiver pronto para ser integrado, ele será capaz de concluir o processo por conta própria seguindo um procedimento automatizado? Ou os novos locatários iniciam uma solicitação e você os integra manualmente depois de receber a solicitação? Existem etapas de aprovação manual necessárias da sua equipe, como para evitar o abuso do seu serviço?
• Tempo de provisionamento: quando um locatário está pronto para ser integrado, com que rapidez o processo de integração precisa ser concluído? Se você não tiver uma resposta clara, considere se isso deve ser medido em segundos, minutos, horas ou dias.
• Azure Marketplace: planeia utilizar o Azure Marketplace para iniciar a implementação? Se você fizer isso, há requisitos que você precisa atender para adicionar novos locatários.

Você também deve considerar as etapas de integração e provisionamento, automação e responsabilidade de gerenciamento de recursos.

Etapas de integração e provisionamento

Considere tudo o que você precisa fazer ao integrar um locatário e documente essa lista e fluxo de trabalho, mesmo que seja executado manualmente. O fluxo de trabalho de integração normalmente inclui o seguinte:

• Aceitação de acordos comerciais.
• Coleta das informações necessárias para configurar seu sistema para o novo locatário.
• Etapas de aprovação manual, por exemplo, para evitar fraudes ou abuso do seu serviço.
• O provisionamento de recursos no Azure.
• Criação ou configuração de nomes de domínio.
• Execute tarefas de configuração pós-implantação, como criar a primeira conta de usuário para o locatário e transmitir suas credenciais com segurança para o locatário.
• Alterações manuais de configuração, como alterações de registro DNS.

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

Além disso, considere os recursos específicos do Azure que você precisa provisionar para um locatário. Mesmo que você não provisione recursos dedicados para cada locatário, considere se, às vezes, é necessário implantar recursos quando um novo locatário é integrado. Isso pode ocorrer quando um locatário exige que seus dados sejam armazenados em uma região específica ou quando você se aproxima dos limites de um carimbo ou componente em sua solução e precisa criar outra instância para o próximo lote de locatários.

Considere se o processo de integração provavelmente será perturbador para outros locatários, especialmente para aqueles que compartilham a mesma infraestrutura. Por exemplo, se você precisar modificar bancos de dados compartilhados, esse processo pode causar um impacto no desempenho que outros locatários podem notar? Considere se você pode evitar esses efeitos ou mitigá-los executando o processo de integração fora do horário normal de funcionamento.

Automatização

Implantações automatizadas são sempre aconselháveis para soluções hospedadas na nuvem. Ao trabalhar com soluções multilocatário, a automação da implantação torna-se ainda mais importante pelos seguintes motivos:

• Escala: os processos de implantação manual tornam-se cada vez mais complexos e demorados, à medida que a população de locatários aumenta. Uma abordagem de implantação automatizada é mais fácil de dimensionar à medida que o número de locatários cresce.
• Repetível: em um ambiente multilocatário, use um processo consistente para implantações em todos os locatários. Processos manuais introduzem a chance de erro, ou de etapas sendo executadas para alguns inquilinos e não para outros. Esses processos manuais deixam seu ambiente em um estado inconsistente, o que torna mais difícil para sua equipe gerenciar a solução.
• Impacto das interrupções: as implantações manuais são significativamente mais arriscadas e propensas a interrupções do que as implantações automatizadas. Em um ambiente multilocatário, o impacto de uma interrupção em todo o sistema (devido a um erro de implantação) pode ser alto, já que todos os locatários podem ser afetados.

Ao implantar em um ambiente multilocatário, você deve usar pipelines de implantação e usar a infraestrutura como tecnologias de código (IaC), como Bicep, modelos JSON ARM, 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. Esse processo é descrito na documentação das APIs de atendimento SaaS.

Capacidade máxima de recursos

Ao implantar programaticamente recursos de locatário em recursos compartilhados, considere o limite de capacidade para cada recurso. Quando você se aproxima desse limite, talvez seja necessário criar outra instância do recurso para oferecer suporte a uma escala adicional. Considere os limites de cada recurso que você implanta e as condições que o acionarão para implantar outra instância.

Por exemplo, suponha que sua solução inclua um servidor lógico SQL do Azure e provisione um banco de dados dedicado nesse servidor para cada locatário. Um único servidor lógico tem limites, que incluem um número máximo de bancos de dados suportados por um servidor lógico. À medida que se aproxima desses limites, talvez seja necessário provisionar novos servidores para continuar a integrar locatários. Considere se você automatiza esse processo ou monitora manualmente o crescimento.

Responsabilidade pela gestão de recursos

Em algumas soluções multilocatário, você implanta recursos dedicados do Azure para cada locatário, como um banco de dados para cada locatário. Ou, você pode decidir sobre um número definido de locatários para abrigar em uma única instância de um recurso, de modo que o número de locatários que você tem dita o conjunto de recursos que você implanta no Azure. Em outras soluções, você implanta um único conjunto de recursos compartilhados e, em seguida, reconfigura os recursos quando integra novos locatários.

Cada um desses modelos exige que você implante e gerencie recursos de maneiras diferentes, e você deve considerar como implantará e gerenciará o ciclo de vida dos recursos provisionados. Duas abordagens comuns são as seguintes:

• Para tratar locatários como configuração dos recursos que você implanta e usar seus pipelines de implantação para implantar e configurar esses recursos.
• Para tratar locatários como dados e ter um plano de controle provisionar e configurar a infraestrutura para seus locatários.

Apresenta-se seguidamente um debate mais aprofundado sobre estas abordagens.

Testar

Planeje testar completamente sua solução durante e após cada implantação. Você pode usar testes automatizados para verificar o comportamento funcional e não funcional da sua solução. Certifique-se de testar seu modelo de isolamento de locatário e considere o uso de ferramentas como o Azure Chaos Studio para introduzir deliberadamente falhas que simulam interrupções do mundo real e verificar se sua solução funciona mesmo quando um componente está indisponível ou funcionando mal.

Abordagens e padrões a considerar

Vários padrões de design do Centro de Arquitetura do Azure e da comunidade em geral são relevantes para a implantação e configuração de soluções multilocatário.

Padrão de selos de implantação

O padrão de Carimbos de Implantação envolve a implantação de infraestrutura dedicada para um locatário ou grupo de locatários. Um único carimbo pode conter vários locatários ou ser dedicado a um único locatário. Você pode optar por implantar um único carimbo ou coordenar uma implantação entre vários carimbos. Se você implantar carimbos dedicados para cada locatário, também poderá considerar a implantação de carimbos inteiros programaticamente.

Anéis de implantação

Os anéis de implantação permitem que você distribua atualizações para diferentes grupos de infraestrutura em momentos diferentes. Essa abordagem é comumente usada com o padrão Selos de Implantação, e grupos de carimbos podem ser atribuídos a anéis distintos com base nas preferências do locatário, tipos de carga de trabalho e outras considerações. Para obter mais informações, consulte Anéis de implantação.

Marcas de funcionalidades

Os sinalizadores de recursos permitem que você exponha progressivamente novos recursos ou versões de sua solução para diferentes locatários, enquanto você mantém uma única base de código. Considere usar a Configuração de Aplicativo do Azure para gerenciar seus sinalizadores de recursos. Para obter mais informações, consulte Sinalizadores de recursos.

Às vezes, você precisa habilitar seletivamente recursos específicos para determinados clientes. Por exemplo, você pode ter diferentes níveis de preços que permitem o acesso a determinados recursos. Os sinalizadores de recursos geralmente não são a escolha certa para esses cenários. Em vez disso, considere criar um processo para controlar e aplicar os direitos de licença que cada cliente tem.

Antipadrões a evitar

Ao implantar e configurar soluções multilocatário, é importante evitar situações que inibem sua capacidade de escala. Estes incluem:

• Implementação e testes manuais. Conforme descrito acima, os processos de implantação manual adicionam riscos e diminuem sua capacidade de implantação. Considere o uso de pipelines para implantações automatizadas, a criação programática de recursos a partir do código da sua solução ou uma combinação de ambos.
• Personalizações especializadas para inquilinos. Evite implantar recursos ou uma configuração que se aplique apenas a um único locatário. Essa abordagem adiciona complexidade às suas implantações e processos de teste. Em vez disso, use os mesmos tipos de recursos e base de código para cada locatário e use estratégias como sinalizadores de recursos para alterações temporárias ou para recursos que são implantados progressivamente, ou use diferentes níveis de preços com direitos de licença para habilitar seletivamente recursos para locatários que os exigem. Use um processo de implantação consistente e automatizado, mesmo para locatários que tenham recursos isolados ou dedicados.

Listas de locatários como configuração ou dados

Você pode considerar as duas abordagens a seguir ao implantar recursos em uma solução multilocatário:

• Use um pipeline de implantação automatizado para implantar todos os recursos. À medida que novos locatários são adicionados, reconfigure seu pipeline para provisionar os recursos para cada locatário.
• Use um pipeline de implantação automatizado para implantar recursos compartilhados que não dependem do número de locatários. Para recursos implantados para cada locatário, crie-os em seu aplicativo.

Ao considerar as duas abordagens, você deve distinguir entre tratar sua lista de locatários como uma configuração ou como dados. Essa distinção também é importante quando você considera como construir um plano de controle para o seu sistema.

Lista de locatários como configuração

Ao tratar sua lista de locatários como configuração, você implanta todos os seus recursos a partir de um pipeline de implantação centralizado. Quando novos locatários são integrados, você reconfigura o pipeline ou seus parâmetros. Normalmente, a reconfiguração acontece através de alterações manuais, como ilustrado no diagrama a seguir.

O processo para integrar um novo locatário pode ser semelhante ao seguinte:

1. Atualize a lista de inquilinos. Isso normalmente acontece manualmente, configurando o próprio pipeline ou modificando um arquivo de parâmetros incluído na configuração do pipeline.
2. Acione o pipeline para ser executado.
3. O pipeline reimplanta seu conjunto completo de recursos do Azure, incluindo quaisquer novos recursos específicos do locatário.

Essa abordagem tende a funcionar bem para um pequeno número de locatários e para arquiteturas onde todos os recursos são compartilhados. É uma abordagem simples porque todos os seus recursos do Azure podem ser implantados e configurados usando um único processo.

No entanto, quando você aborda um número maior de locatários, digamos 5 a 10 ou mais, torna-se complicado reconfigurar o pipeline à medida que você adiciona locatários. O tempo necessário para executar o pipeline de implantação também costuma aumentar significativamente. Essa abordagem também não oferece suporte fácil à criação de locatários de autoatendimento, e o tempo de espera antes de um locatário ser integrado pode ser maior porque você precisa acionar seu pipeline para ser executado.

Lista de inquilinos como dados

Quando você trata sua lista de locatários como dados, ainda implanta seus componentes compartilhados usando um pipeline. No entanto, para recursos e definições de configuração que precisam ser implantados para cada locatário, você implanta ou configura imperativamente seus recursos. Por exemplo, seu plano de controle pode usar os SDKs do Azure para criar um recurso específico ou para iniciar a implantação de um modelo parametrizado.

O processo para integrar um novo locatário pode ser semelhante ao seguinte e aconteceria de forma assíncrona:

1. Solicite que um locatário seja integrado, por exemplo, iniciando uma solicitação de API no plano de controle do sistema.
2. Um componente de fluxo de trabalho recebe a solicitação de criação e orquestra as etapas restantes.
3. O fluxo de trabalho inicia a implantação de recursos específicos do locatário no Azure. Isso pode ser alcançado usando um modelo de programação imperativo, como usando os SDKs do Azure, ou acionando imperativamente a implantação de um modelo Bicep ou Terraform.
4. Quando a implantação é concluída, o fluxo de trabalho salva os detalhes do novo locatário no catálogo do locatário central. Os dados armazenados para cada locatário podem incluir a ID do locatário e as IDs de recurso para todos os recursos específicos do locatário que o fluxo de trabalho criou.

Ao fazer isso, você pode provisionar recursos para novos locatários sem reimplantar toda a solução. O tempo envolvido no provisionamento de novos recursos para cada locatário provavelmente será menor, porque apenas esses recursos precisam ser implantados.

No entanto, essa abordagem geralmente é muito mais demorada para criar, e o esforço gasto precisa ser justificado pelo número de locatários ou pelos prazos de provisionamento que você precisa cumprir.

Para obter mais informações sobre essa abordagem, consulte Considerações para planos de controle multilocatário.

Exemplo

A Contoso executa uma solução multilocatária para seus clientes. Atualmente, eles têm seis inquilinos e esperam crescer para 300 inquilinos nos próximos 18 meses. A Contoso segue o aplicativo Multilocatário com bancos de dados dedicados para cada abordagem de locatário . Eles implantaram um único conjunto de recursos do Serviço de Aplicativo e um servidor lógico SQL do Azure que são compartilhados entre todos os seus locatários e implantam um banco de dados SQL do Azure dedicado para cada locatário, conforme mostrado no diagrama a seguir.

A Contoso usa o Bicep para implantar seus recursos do Azure.

Opção 1 - Usar pipelines de implantação para tudo

A Contoso pode considerar a implantação de todos os seus recursos usando um pipeline de implantação. Seu pipeline implanta um arquivo Bicep que inclui todos os seus recursos do Azure, incluindo os bancos de dados SQL do Azure para cada locatário. Um arquivo de parâmetro define a lista de locatários e o arquivo Bicep usa um loop de recursos para implantar um banco de dados para cada um dos locatários listados, conforme mostrado no diagrama a seguir.

Se a Contoso seguir esse modelo, precisará atualizar seu arquivo de parâmetros como parte da integração de um novo locatário. Em seguida, eles precisam executar novamente seu pipeline. Além disso, eles precisam controlar manualmente se estão perto de quaisquer limites, como se crescem a uma taxa inesperadamente alta e se aproximam do número máximo de bancos de dados com suporte em um único servidor lógico SQL do Azure.

Opção 2 - Usar uma combinação de pipelines de implantação e criação de recursos imperativos

Como alternativa, a Contoso pode considerar separar a responsabilidade pelas implantações do Azure.

A Contoso usa um arquivo Bicep que define os recursos compartilhados que devem ser implantados. Os recursos compartilhados suportam todos os seus locatários e incluem um banco de dados de mapa de locatário, conforme mostrado no diagrama a seguir.

Em seguida, a equipe da Contoso cria um plano de controle que inclui uma API de integração de locatário. Quando a equipe de vendas conclui a venda para um novo cliente, o Microsoft Dynamics aciona a API para iniciar o processo de integração. A Contoso também fornece uma interface Web de autoatendimento para os clientes usarem, e isso também aciona a API.

A API inicia de forma assíncrona um fluxo de trabalho que integra seus novos locatários. O fluxo de trabalho inicia a implantação de um novo banco de dados SQL do Azure, o que pode ser feito por uma das seguintes abordagens:

• Use o SDK do Azure para iniciar a implantação de um segundo arquivo Bicep que define o banco de dados SQL do Azure.
• Use o SDK do Azure para criar imperativamente um banco de dados SQL do Azure, usando a biblioteca de gerenciamento.

Depois que o banco de dados é implantado, o fluxo de trabalho adiciona o locatário ao banco de dados da lista de locatários, conforme mostrado no diagrama a seguir.

As atualizações contínuas do esquema de banco de dados são iniciadas pela camada de aplicativo.

Contribuidores

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

Autor principal:

• John Downs - Brasil | Engenheiro de Software Principal

Outros contribuidores:

• Bohdan Cherchyk - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

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

Próximos passos

• Analise as considerações para atualizar uma solução multilocatário.
• Considere abordagens arquitetônicas para armazenamento e dados.
• Considere como usar o Azure Resource Manager em uma solução multilocatário.