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

Azure

Azure DevOps

Azure Pipelines

Azure Marketplace

GitHub

Independentemente da arquitetura e dos componentes usados para implementá-la, você precisa implantar e configurar os componentes da solução. Em um ambiente multilocatário, é importante considerar como implantar seus recursos do Azure, especialmente quando você 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 como implantar soluções multilocatários e demonstramos algumas abordagens a serem consideradas quando você planeja sua estratégia de implantação.

Considerações e requisitos

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

• Escala esperada: Você espera dar suporte a um pequeno número de locatários (como cinco ou menos) ou aumentará para um grande número de locatários?
• Integração automatizada ou com suporte: Quando um locatário estiver pronto para ser integrado, ele poderá concluir o processo por conta própria seguindo um procedimento automatizado? Ou, os novos locatários iniciam uma solicitação e você as integra manualmente depois de receber a solicitação? Há etapas de aprovação manuais necessárias da sua equipe, como evitar o abuso de seu serviço?
• Tempo de provisionamento: Quando um locatário está pronto para ser integrado, a rapidez com que 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: Você planeja usar o Azure Marketplace para iniciar a implantaçã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 o fluxo de trabalho, mesmo que ele seja executado manualmente. O fluxo de trabalho de integração normalmente inclui o seguinte:

• Aceitação de acordos comerciais.
• Coleção das informações que você precisa para configurar seu sistema para o novo locatário.
• Etapas manuais de aprovação, por exemplo, para evitar fraudes ou abusos de seu serviço.
• O provisionamento de recursos no Azure.
• Criando ou configurando 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 com segurança suas credenciais 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 você precisa 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 selo 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 causará interrupções para outros locatários, especialmente para aqueles que compartilham a mesma infraestrutura. Por exemplo, se você precisar modificar bancos de dados compartilhados, esse processo poderá causar um impacto no desempenho que outros locatários podem notar? Considere se você pode evitar esses efeitos ou atenuá-los executando o processo de integração fora do horário operacional normal.

Automação

Implantações automatizadas são sempre aconselháveis para soluções hospedadas na nuvem. Ao trabalhar com soluções multilocatários, a automação de 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 aumenta.
• Repetível: Em um ambiente multilocatário, use um processo consistente para implantações em todos os locatários. Os processos manuais introduzem a possibilidade de erro ou de etapas que estão sendo executadas para alguns locatários 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: Implantações manuais são significativamente mais arriscadas e propensas a interrupções do que 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, pois cada locatário pode ser afetado.

Ao implantar em um ambiente multilocatário, você deve usar pipelines de implantação e usar tecnologias de IaC (infraestrutura como código), como Bicep, modelos do ARM JSON, Terraform ou os SDKs do Azure.

Se você planeja oferecer sua solução por meio do Azure Marketplace, deverá fornecer um processo de integração totalmente automatizado para novos locatários. Esse processo é descrito na documentação de APIs de atendimento de SaaS.

Capacidade máxima de recursos

Ao implantar recursos de locatário programaticamente 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 dar suporte a uma escala adicional. Considere os limites de cada recurso que você implanta e as condições que dispararão você para implantar outra instância.

Por exemplo, suponha que sua solução inclua um servidor lógico do SQL do Azure e sua solução 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 compatíveis com um servidor lógico. À medida que você se aproxima desses limites, talvez seja necessário provisionar novos servidores para que você possa continuar a integrar locatários. Considere se você automatiza esse processo ou monitora manualmente o crescimento.

Responsabilidade de gerenciamento de recursos

Em algumas soluções multilocatários, 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 a serem hospedados 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 reconfigura os recursos ao integrar 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 os 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 provisionado e configurar a infraestrutura para seus locatários.

Mais discussões sobre essas abordagens são fornecidas abaixo.

Teste

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 solução. Verifique se você testa seu modelo de isolamento de locatário e considere usar ferramentas como o Azure Chaos Studio para introduzir deliberadamente falhas que simulam interrupções do mundo real e verificar se a solução funciona mesmo quando um componente está indisponível ou com defeito.

Abordagens e padrões a serem considerados

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

Padrão de Carimbos de Implantação

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

Anéis de implantação

Os anéis de implantação permitem distribuir 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 selos podem ser atribuídos a anéis distintos com base em preferências de locatário, tipos de carga de trabalho e outras considerações. Para obter mais informações, veja Anéis de implementação.

Sinalizadores de recursos

Os sinalizadores de recursos permitem que você exponha progressivamente novos recursos ou versões de sua solução para locatários diferentes, enquanto você mantém uma única base de código. Considere usar a Configuração de Aplicativos 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 tipos de preço que permitem o acesso a determinados recursos. 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 impor os direitos de licença que cada cliente tem.

Antipadrões a serem evitados

Ao implantar e configurar soluções multilocatários, é importante evitar situações que inibam sua capacidade de dimensionar. Estes incluem o seguinte:

• Implantação e teste manuais. Conforme descrito acima, os processos de implantação manuais adicionam riscos e reduzem sua capacidade de implantação. Considere o uso de pipelines para implantações automatizadas, a criação programática de recursos do código da solução ou uma combinação de ambos.
• Personalizações especializadas para locatários. Evite implantar recursos ou uma configuração que se aplique apenas a um único locatário. Essa abordagem adiciona complexidade aos processos de teste e implantações. 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 distribuídos progressivamente ou use tipos de preços diferentes com direitos de licença para habilitar seletivamente recursos para locatários que exigem eles. Use um processo de implantação consistente e automatizado, mesmo para locatários que têm 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 o 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 criar um plano de controle para 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 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 ocorre por meio de alterações manuais, conforme ilustrado no diagrama a seguir.

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

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

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

No entanto, quando você se aproxima de 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 aumenta significativamente. Essa abordagem também não dá suporte facilmente à criação de locatário de autoatendimento e o tempo de entrega antes de um locatário ser integrado pode ser maior porque você precisa disparar o pipeline para ser executado.

Lista de locatários como dados

Ao tratar sua lista de locatários como dados, você ainda implantará seus componentes compartilhados usando um pipeline. No entanto, para recursos e configurações que precisam ser implantados para cada locatário, você implanta ou configura seus recursos de forma imperativa. 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 ocorreria de forma assíncrona:

1. Solicite que um locatário seja integrado, como iniciando uma solicitação de API para o 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 para o Azure. Isso pode ser feito usando um modelo de programação imperativo, como usando os SDKs do Azure ou disparando 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 de locatários 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, pois somente esses recursos precisam ser implantados.

No entanto, essa abordagem geralmente é muito mais demorada para ser criada, e o esforço gasto precisa ser justificado pelo número de locatários ou pelos períodos de tempo de provisionamento que você precisa atender.

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

Observação

As operações de implantação e configuração do Azure geralmente levam tempo para serem concluídas. Certifique-se de usar um processo apropriado para iniciar e monitorar essas operações de execução prolongada. Por exemplo, você pode considerar seguir o padrão de Request-Reply assíncrono. Use tecnologias projetadas para dar suporte a operações de execução longa, como Aplicativos Lógicos do Azure e Funções Duráveis.

Exemplo

A Contoso executa uma solução multilocatário para seus clientes. Atualmente, eles têm seis locatários e esperam aumentar para 300 locatários 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 do 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. O pipeline deles implanta um arquivo Bicep que inclui todos os 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, eles precisarão atualizar o arquivo de parâmetro como parte da integração de um novo locatário. Em seguida, eles precisam executar novamente o pipeline. Além disso, eles precisam acompanhar manualmente se estão próximos a quaisquer limites, como se crescessem a uma taxa inesperadamente alta e se aproximassem do número máximo de bancos de dados com suporte em um único servidor lógico do 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 a separação da responsabilidade pelas implantações do Azure.

A Contoso usa um arquivo Bicep que define os recursos compartilhados que devem ser implantados. Os recursos compartilhados dão suporte a todos os 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 sua equipe de vendas concluir a venda para um novo cliente, o Microsoft Dynamics disparará 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 dispara a API também.

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, 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 um banco de dados SQL do Azure de forma imperativa 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 por sua camada de aplicativo.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• John Downs | Engenheiro de Software Principal

Outros colaboradores:

• Bohdan Cherchyk | Engenheiro sênior de clientes, FastTrack para Azure
• Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

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

Próximas etapas

• Examine 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.

Independentemente da arquitetura e dos componentes usados para implementá-la, você precisa implantar e configurar os componentes da solução. Em um ambiente multilocatário, é importante considerar como implantar seus recursos do Azure, especialmente quando você 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 como implantar soluções multilocatários e demonstramos algumas abordagens a serem consideradas quando você planeja sua estratégia de implantação.

Considerações e requisitos

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

• Escala esperada: Você espera dar suporte a um pequeno número de locatários (como cinco ou menos) ou aumentará para um grande número de locatários?
• Integração automatizada ou com suporte: Quando um locatário estiver pronto para ser integrado, ele poderá concluir o processo por conta própria seguindo um procedimento automatizado? Ou, os novos locatários iniciam uma solicitação e você as integra manualmente depois de receber a solicitação? Há etapas de aprovação manuais necessárias da sua equipe, como evitar o abuso de seu serviço?
• Tempo de provisionamento: Quando um locatário está pronto para ser integrado, a rapidez com que 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: Você planeja usar o Azure Marketplace para iniciar a implantaçã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 o fluxo de trabalho, mesmo que ele seja executado manualmente. O fluxo de trabalho de integração normalmente inclui o seguinte:

• Aceitação de acordos comerciais.
• Coleção das informações que você precisa para configurar seu sistema para o novo locatário.
• Etapas manuais de aprovação, por exemplo, para evitar fraudes ou abusos de seu serviço.
• O provisionamento de recursos no Azure.
• Criando ou configurando 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 com segurança suas credenciais 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 você precisa 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 selo 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 causará interrupções para outros locatários, especialmente para aqueles que compartilham a mesma infraestrutura. Por exemplo, se você precisar modificar bancos de dados compartilhados, esse processo poderá causar um impacto no desempenho que outros locatários podem notar? Considere se você pode evitar esses efeitos ou atenuá-los executando o processo de integração fora do horário operacional normal.

Automação

Implantações automatizadas são sempre aconselháveis para soluções hospedadas na nuvem. Ao trabalhar com soluções multilocatários, a automação de 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 aumenta.
• Repetível: Em um ambiente multilocatário, use um processo consistente para implantações em todos os locatários. Os processos manuais introduzem a possibilidade de erro ou de etapas que estão sendo executadas para alguns locatários 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: Implantações manuais são significativamente mais arriscadas e propensas a interrupções do que 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, pois cada locatário pode ser afetado.

Ao implantar em um ambiente multilocatário, você deve usar pipelines de implantação e usar tecnologias de IaC (infraestrutura como código), como Bicep, modelos do ARM JSON, Terraform ou os SDKs do Azure.

Se você planeja oferecer sua solução por meio do Azure Marketplace, deverá fornecer um processo de integração totalmente automatizado para novos locatários. Esse processo é descrito na documentação de APIs de atendimento de SaaS.

Capacidade máxima de recursos

Ao implantar recursos de locatário programaticamente 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 dar suporte a uma escala adicional. Considere os limites de cada recurso que você implanta e as condições que dispararão você para implantar outra instância.

Por exemplo, suponha que sua solução inclua um servidor lógico do SQL do Azure e sua solução 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 compatíveis com um servidor lógico. À medida que você se aproxima desses limites, talvez seja necessário provisionar novos servidores para que você possa continuar a integrar locatários. Considere se você automatiza esse processo ou monitora manualmente o crescimento.

Responsabilidade de gerenciamento de recursos

Em algumas soluções multilocatários, 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 a serem hospedados 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 reconfigura os recursos ao integrar 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 os 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 provisionado e configurar a infraestrutura para seus locatários.

Mais discussões sobre essas abordagens são fornecidas abaixo.

Teste

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 solução. Verifique se você testa seu modelo de isolamento de locatário e considere usar ferramentas como o Azure Chaos Studio para introduzir deliberadamente falhas que simulam interrupções do mundo real e verificar se a solução funciona mesmo quando um componente está indisponível ou com defeito.

Abordagens e padrões a serem considerados

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

Padrão de Carimbos de Implantação

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

Anéis de implantação

Os anéis de implantação permitem distribuir 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 selos podem ser atribuídos a anéis distintos com base em preferências de locatário, tipos de carga de trabalho e outras considerações. Para obter mais informações, veja Anéis de implementação.

Sinalizadores de recursos

Os sinalizadores de recursos permitem que você exponha progressivamente novos recursos ou versões de sua solução para locatários diferentes, enquanto você mantém uma única base de código. Considere usar a Configuração de Aplicativos 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 tipos de preço que permitem o acesso a determinados recursos. 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 impor os direitos de licença que cada cliente tem.

Antipadrões a serem evitados

Ao implantar e configurar soluções multilocatários, é importante evitar situações que inibam sua capacidade de dimensionar. Estes incluem o seguinte:

• Implantação e teste manuais. Conforme descrito acima, os processos de implantação manuais adicionam riscos e reduzem sua capacidade de implantação. Considere o uso de pipelines para implantações automatizadas, a criação programática de recursos do código da solução ou uma combinação de ambos.
• Personalizações especializadas para locatários. Evite implantar recursos ou uma configuração que se aplique apenas a um único locatário. Essa abordagem adiciona complexidade aos processos de teste e implantações. 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 distribuídos progressivamente ou use tipos de preços diferentes com direitos de licença para habilitar seletivamente recursos para locatários que exigem eles. Use um processo de implantação consistente e automatizado, mesmo para locatários que têm 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 o 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 criar um plano de controle para 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 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 ocorre por meio de alterações manuais, conforme ilustrado no diagrama a seguir.

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

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

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

No entanto, quando você se aproxima de 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 aumenta significativamente. Essa abordagem também não dá suporte facilmente à criação de locatário de autoatendimento e o tempo de entrega antes de um locatário ser integrado pode ser maior porque você precisa disparar o pipeline para ser executado.

Lista de locatários como dados

Ao tratar sua lista de locatários como dados, você ainda implantará seus componentes compartilhados usando um pipeline. No entanto, para recursos e configurações que precisam ser implantados para cada locatário, você implanta ou configura seus recursos de forma imperativa. 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 ocorreria de forma assíncrona:

1. Solicite que um locatário seja integrado, como iniciando uma solicitação de API para o 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 para o Azure. Isso pode ser feito usando um modelo de programação imperativo, como usando os SDKs do Azure ou disparando 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 de locatários 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, pois somente esses recursos precisam ser implantados.

No entanto, essa abordagem geralmente é muito mais demorada para ser criada, e o esforço gasto precisa ser justificado pelo número de locatários ou pelos períodos de tempo de provisionamento que você precisa atender.

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

Observação

As operações de implantação e configuração do Azure geralmente levam tempo para serem concluídas. Certifique-se de usar um processo apropriado para iniciar e monitorar essas operações de execução prolongada. Por exemplo, você pode considerar seguir o padrão de Request-Reply assíncrono. Use tecnologias projetadas para dar suporte a operações de execução longa, como Aplicativos Lógicos do Azure e Funções Duráveis.

Exemplo

A Contoso executa uma solução multilocatário para seus clientes. Atualmente, eles têm seis locatários e esperam aumentar para 300 locatários 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 do 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. O pipeline deles implanta um arquivo Bicep que inclui todos os 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, eles precisarão atualizar o arquivo de parâmetro como parte da integração de um novo locatário. Em seguida, eles precisam executar novamente o pipeline. Além disso, eles precisam acompanhar manualmente se estão próximos a quaisquer limites, como se crescessem a uma taxa inesperadamente alta e se aproximassem do número máximo de bancos de dados com suporte em um único servidor lógico do 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 a separação da responsabilidade pelas implantações do Azure.

A Contoso usa um arquivo Bicep que define os recursos compartilhados que devem ser implantados. Os recursos compartilhados dão suporte a todos os 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 sua equipe de vendas concluir a venda para um novo cliente, o Microsoft Dynamics disparará 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 dispara a API também.

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, 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 um banco de dados SQL do Azure de forma imperativa 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 por sua camada de aplicativo.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• John Downs | Engenheiro de Software Principal

Outros colaboradores:

• Bohdan Cherchyk | Engenheiro sênior de clientes, FastTrack para Azure
• Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

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

Próximas etapas

• Examine 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.