Editar

Share via


Abordagens de arquitetura para uma solução de multilocatário

Azure

Há várias maneiras diferentes de projetar e criar soluções multilocatário no Azure. Em um extremo, você pode compartilhar todos os recursos em sua solução entre todos os seus locatários. No outro extremo, você pode implantar recursos isolados para cada locatário. Pode parecer simples implantar recursos separados para cada locatário e isso pode funcionar para um pequeno número de locatários. No entanto, normalmente não fornece eficiência de custo e pode se tornar difícil gerenciar seus recursos. Há também várias abordagens que se ajustam entre esses extremos e todas elas têm compensações, como escala, isolamento, eficiência de custo, desempenho, complexidade da implementação e capacidade de gerenciamento.

Ao longo desta seção, discutiremos as principais categorias dos serviços do Azure que compõem uma solução, incluindo computação, armazenamento e dados, rede, implantação, identidade, mensagens, inteligência artificial e aprendizado de máquina e IoT. Para cada categoria, descrevemos os principais padrões e abordagens que você pode considerar ao criar uma solução multilocatário e alguns antipadrões a serem evitados.

Padrão de Carimbos de Implantação

O padrão Carimbos de Implantação é frequentemente usado em soluções multilocatário. Ele envolve a implantação de infraestrutura dedicada para um locatário ou para um grupo de locatários. Um único carimbo pode conter vários locatários ou pode ser dedicado a um único locatário.

Diagram showing the Deployment Stamps pattern. Each tenant has their own stamp containing a database.

Ao usar selos de locatário único, o padrão Selos de Implantação tende a ser simples de implementar, pois é provável que cada carimbo não tenha conhecimento de nenhum outro, portanto, nenhuma lógica de multilocatário ou funcionalidades precisam ser incorporadas à camada do aplicativo. Quando cada locatário tem o próprio carimbo dedicado, esse padrão fornece o maior grau de isolamento e atenua o problema do Vizinho Barulhento. Ele também fornece a opção para que os locatários sejam configurados ou personalizados de acordo com seus próprios requisitos, como estar localizados em uma região geopolítica específica ou ter requisitos específicos de alta disponibilidade.

Ao usar carimbos multilocatário, outros padrões precisam ser considerados para gerenciar a multilocação dentro do carimbo, e o problema do Vizinho Barulhento ainda pode ser aplicado. No entanto, usando o padrão Carimbos de Implantação, você pode continuar a ser dimensionado à medida que sua solução aumenta.

O maior problema com o padrão Carimbos de Implantação, ao ser usado para atender a um único locatário, tende a ser o custo da infraestrutura. Ao usar carimbos de locatário único, cada carimbo precisa ter o próprio conjunto separado de infraestrutura, que não é compartilhado com outros locatários. Você também precisa garantir que os recursos implantados para um carimbo sejam suficientes para atender à carga de pico para a carga de trabalho desse locatário. Verifique se o modelo de preços compensa o custo de implantação da infraestrutura do locatário.

Os carimbos de locatário único geralmente funcionam bem quando você tem um pequeno número de locatários. À medida que seu número de locatários aumenta, é possível, mas cada vez mais difícil, gerenciar uma frota de carimbos (confira este estudo de caso como um exemplo). Você também pode aplicar o padrão Carimbos de Implantação para criar uma frota de carimbos multilocatário, o que pode fornecer benefícios para o compartilhamento de recursos e custos.

Para implementar o padrão Carimbos de Implantação, é importante usar abordagens de implantação automatizadas. Dependendo de sua estratégia de implantação, você pode considerar gerenciar seus carimbos em seus pipelines de implantação usando a infraestrutura declarativa como código, como Bicep, modelos do ARM ou modelos do Terraform. Como alternativa, você pode considerar a criação de código personalizado para implantar e gerenciar cada carimbo, como o uso de SDKs do Azure.

Público-alvo

Os artigos nesta seção destinam-se a ser úteis para arquitetos de soluções e desenvolvedores líderes de aplicativos multilocatário, incluindo ISVs (fornecedores de software independentes) e startups que desenvolvem soluções de SaaS. Grande parte das diretrizes nesta seção é genérica e se aplica a vários serviços do Azure dentro de uma categoria.

Próximas etapas

Recomendamos que você examine as abordagens para a organização de recursos em uma solução multilocatário antes de examinar as diretrizes sobre categorias específicas dos serviços do Azure.