Abordagens de arquitetura para a implantação e a configuração de soluções de 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 você implanta os recursos do Azure, principalmente quando implanta recursos dedicados para cada locatário ou quando reconfigura recursos com base no número de locatários no sistema. Nesta página, oferecemos aos arquitetos de soluções as diretrizes para implantação de soluções multilocatário e demonstramos algumas abordagens a serem consideradas ao planejar a estratégia de implantação.

Considerações e requisitos

É importante ter uma ideia clara dos requisitos antes de planejar a estratégia de implantação. Veja algumas considerações específicas:

• Escala esperada: você espera dar suporte a um número pequeno 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ê faz a integração manual depois de receber a solicitação? Há etapas de aprovação manuais exigidas da equipe, 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: você planeja usar o Azure Marketplace para iniciar a implantação? Se sim, 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 realizado manualmente. O fluxo de trabalho de integração costuma incluir o seguinte:

• Aceitação de contratos comerciais.
• Coleta das informações necessárias para configurar o sistema para o novo locatário.
• Etapas de aprovação manual, para evitar fraudes ou abusos do seu serviço.
• O provisionamento de recursos no Azure.
• Criação ou configuração de nomes de domínio.
• Execução das tarefas de configuração pós-implantação, como criar a primeira conta de usuário do locatário e transmitir as credenciais com segurança para o locatário.
• Alterações de configuração manuais, 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 vá provisionar recursos dedicados a cada locatário, considere se poderá ser necessário implantar recursos quando um novo locatário for integrado. Isso pode ocorrer quando um locatário exige que os dados sejam armazenados em uma região específica ou quando os limites de um stamp ou de um componente na solução estão se aproximando, exigindo a criação de outra instância para o próximo lote de locatários.

Considere se o processo de integração poderá causar interrupção a outros locatários, principalmente aos que compartilham a mesma infraestrutura. Por exemplo, se você precisar modificar bancos de dados compartilhados, esse processo poderá causar um impacto no desempenho que seja perceptível para os outros locatários? Considere se você pode evitar esses efeitos ou atenuá-los executando o processo de integração fora do horário comercial normal.

Automação

As implantações automatizadas são sempre recomendadas para soluções hospedadas na nuvem. Ao trabalhar com soluções multilocatário, a automação da implantação é ainda mais importante pelos seguintes motivos:

• Escalar: Os processos de implantação manual ficam 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 escalar à 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 apresentam chance de erro ou de executar certas etapas 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: as 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 todos os locatários podem ser afetados.

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

Se você planeja oferecer a solução pelo Azure Marketplace, será necessário criar um processo de integração totalmente automatizado para os novos locatários. Esse processo está descrito na documentação das APIs de processamento de SaaS.

Capacidade máxima de recurso

Ao implantar recursos de locatário programaticamente em recursos compartilhados, considere o limite de capacidade de cada recurso. Quando esse limite se aproximar, poderá ser necessário criar outra instância do recurso para dar suporte ao aumento de escala. Considere os limites de cada recurso implantado e as condições de gatilho para a implantação de outra instância.

Por exemplo, suponha que a solução inclua um SQL Server lógico do Azure e provisione um banco de dados dedicado nesse servidor para cada locatário. Um servidor lógico individual tem limites, que incluem um número máximo de bancos de dados compatíveis com um servidor lógico. À medida que esses limites se aproximam, pode ser necessário provisionar novos servidores para continuar a integrar locatários. Considere se você vai automatizar esse processo ou monitorar o crescimento manualmente.

Responsabilidade de gerenciamento 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 definir um determinado número de locatários a serem hospedados em uma instância individual de um recurso, para que o número de locatários determine o conjunto de recursos implantados no Azure. Em outras soluções, você implanta um só 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 diferentes maneiras e considere como vai implantar e gerenciar o ciclo de vida dos recursos provisionados. Duas abordagens comuns para isso são:

• Tratar os locatários como uma configuração dos recursos implantados e usar os pipelines de implantação para implantar e configurar esses recursos.
• Tratar os locatários como dados e fazer com que o painel de controle provisione e configure a infraestrutura dos locatários.

Veja abaixo mais discussões sobre essas abordagens.

Testando

Planeje testar a solução completamente durante e após cada implantação. Você pode usar os testes automatizados para verificar o comportamento funcional e não funcional da solução. Teste o modelo de isolamento de locatário e considere usar ferramentas como o Azure Chaos Studio para introduzir falhas propositais que simulem interrupções reais e verifiquem se a solução funciona mesmo quando um componente não está disponível ou está com defeito.

Abordagens e padrões a serem considerados

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

Padrão de Carimbos de Implantação

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

Anéis de implantação

Os anéis de implantação permitem que você distribua atualizações a diferentes grupos de infraestrutura em momentos diferentes. Essa abordagem costuma ser usada com o padrão de Carimbos de Implantação, e os grupos de stamps podem ser atribuídos a diferentes anéis com base nas preferências do locatário, nos tipos de carga de trabalho e em outras considerações. Para saber mais, confira Anéis de implantação.

Sinalizadores de recurso

Os sinalizadores de recurso permitem expor novos recursos ou versões da solução a diferentes locatários progressivamente, mantendo uma só base de código. Considere usar a Configuração de Aplicativos do Azure para gerenciar os sinalizadores de recursos. Para obter mais informações, confira Sinalizadores de recurso.

Às vezes, você precisa habilitar seletivamente recursos específicos para determinados clientes. Por exemplo, é possível que haja diferentes tipos de preço que permitem acesso a determinadas funcionalidades. Os sinalizadores de recurso não são uma boa opção para esses cenários. Nesses casos, considere criar um processo para acompanhar e impor os direitos de licença que cada cliente tem.

Antipadrões a serem evitados

Ao implantar e configurar soluções multilocatário, é importante evitar situações que dificultem a capacidade de dimensionamento. Elas incluem o seguinte:

• Implantação e teste manuais. Conforme a descrição acima, os processos de implantação manuais apresentam riscos e desaceleram a capacidade de implantação. Considere usar pipelines para implantações automatizadas, criar recursos com o código da sua solução programaticamente ou uma combinação dessas duas opções.
• Customizações especializadas para locatários. Evite implantar recursos ou uma configuração que se aplique apenas a um só locatário. Essa abordagem traz complexidade aos processos de teste e implantações. Nesse caso, use os mesmos tipos de recurso e a mesma base de código para cada locatário e aplique estratégias como sinalizadores de recurso para alterações temporárias ou recursos que são distribuídos progressivamente ou que usam diferentes tipos de preço com direitos de licença para habilitar recursos seletivamente nos locatários que os exigem. 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 estas duas abordagens 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 em cada locatário.
• Use um pipeline de implantação automatizado para implantar recursos compartilhados que não dependem do número de locatários. Os recursos implantados em cada locatário devem ser criados no seu aplicativo.

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

Lista de locatários como configuração

Ao tratar a lista de locatários como uma configuração, você implanta todos os recursos do pipeline centralizado de implantação. Quando novos locatários são integrados, você reconfigura o pipeline ou os respectivos parâmetros. A reconfiguração costuma ocorrer por meio de alterações manuais, conforme a ilustração no diagrama a seguir.

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

1. Atualizar a lista de locatários. Isso costuma acontecer manualmente configurando o pipeline em si ou modificando um arquivo de parâmetros incluído na configuração do pipeline.
2. Disparar a execução do pipeline.
3. O pipeline reimplanta o conjunto completo de recursos do Azure, incluindo os novos recursos específicos do locatário.

Essa abordagem tende a funcionar bem com um número pequeno 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 só processo.

No entanto, quando o número de locatários começa a chegar perto de cinco, dez ou mais, fica complicado reconfigurar o pipeline à medida que os locatários são adicionados. O tempo necessário para executar o pipeline de implantação também aumenta significativamente. Essa abordagem também não facilita a criação de locatário de autoatendimento, e o prazo de entrega até que um locatário seja integrado pode aumentar porque a execução do pipeline precisa ser disparada.

Lista de locatários como dados

Ao tratar a lista de locatários como dados, você também implanta componentes compartilhados usando um pipeline. No entanto, para recursos e definições de configuração que precisam ser implantadas em cada locatário, você implanta ou configura os recursos de modo imperativo. Por exemplo, seu painel 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 modo assíncrono:

1. Solicite que um locatário seja integrado, por exemplo, 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 realizado usando um modelo de programação imperativo, por exemplo, usando os SDKs do Azure, ou disparando a implantação de modo imperativo usando um modelo do Bicep ou do Terraform.
4. Quando a implantação é concluída, o fluxo de trabalho salva os detalhes do novo locatário no catálogo central de locatários. Os dados armazenados para cada locatário podem incluir a ID do locatário e as IDs de recurso de todos os recursos específicos do locatário que o fluxo de trabalho criou.

Dessa forma, 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 será menor, pois somente esses recursos precisarão ser implantados.

No entanto, o desenvolvimento dessa abordagem costuma ser muito mais demorado, e o esforço aplicado precisa ser justificado pelo número de locatários ou pelos períodos de provisionamento que precisam ser cumpridos.

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ário para os clientes. No momento, eles têm seis locatários e esperam crescer para 300 locatários nos próximos 18 meses. A Contoso segue a abordagem Aplicativo multilocatário com bancos de dados dedicados para cada locatário. Eles implantaram um só conjunto de recursos do Serviço de Aplicativo e um SQL Server lógico do Azure que são compartilhados entre todos os locatários e um banco de dados SQL do Azure dedicado para cada locatário, conforme mostra o diagrama a seguir.

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

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

A Contoso pode considerar a implantação de todos os recursos usando um pipeline de implantação. O pipeline 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 recurso para implantar um banco de dados para cada um dos locatários listados, conforme mostra o diagrama a seguir.

Se a Contoso seguir esse modelo, eles precisarão atualizar o arquivo de parâmetro durante a integração de um novo locatário. Depois, precisarão executar o pipeline novamente. Além disso, eles precisarão controlar manualmente se algum limite está se aproximando. Por exemplo, se crescerem inesperadamente a uma taxa muito alta e se aproximarem do número máximo de bancos de dados com suporte em um só SQL Server lógico do Azure.

Opção 2 – Usar uma combinação entre pipelines de implantação e criação imperativa de recursos

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

Nesse caso, é usado 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 mostra o 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 a um novo cliente, o Microsoft Dynamics dispara a API para iniciar o processo de integração. A Contoso também oferece uma interface Web de autoatendimento para os clientes usarem, que também dispara a API.

A API inicia de modo assíncrono um fluxo de trabalho que integra os novos locatários. O fluxo de trabalho inicia a implantação de um novo banco de dados SQL do Azure, o que pode ocorrer seguindo uma destas abordagens:

• Usar o SDK do Azure para iniciar a implantação de um segundo arquivo Bicep que define o banco de dados SQL do Azure.
• Usar o SDK do Azure para criar um banco de dados SQL do Azure de modo imperativo 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 mostra o diagrama a seguir.

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

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• John Downs | Engenheiro de software principal

Outros colaboradores:

• Bohdan Cherchyk | Engenheiro de Cliente Sênior da 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

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