Arquitetura Multi-Tenancy
Já ouviu falar no termo multi-tenant ou multi-tenancy?
Então, conceituando de forma bem simples, multi-tenancy é um estilo de arquitetura onde você tem uma aplicação centralizada que atende a vários clientes. Neste caso, partindo do Inglês tenant, “clientes” significam locatários ou inquilinos.
Vou esclarecer melhor…
Sendo mais específico, multi-tenancy (ou multi-tenant) é um termo utilizado em plataformas SAAS — plataformas que oferecem Software Como Serviço, onde, na maioria das vezes os tenants são clientes corporativos. Ou seja, uma empresa utilizando serviços de outra empresa, numa relação B2B (business to business).
Mas isso não é regra, podem haver muito bem outros cenários com outros tipos de relações, incluindo clientes não corporativos.
Na prática, um exemplo de um contexto onde pode haver uma aplicação multi-tenant, seria uma Loja de departamentos que delega o gerenciamento de seus documentos fiscais à outra empresa especializada em gestão de documentos. Essa empresa, que gerencia os documentos, por sua vez, deve utilizar alguma estratégia de controle que diferencie em sua aplicação e em seu banco de dados uma empresa da outra, de forma que os contextos e, claro, os dados não se misturem.
Modelo single-tenant
É aí que entram as técnicas e conceitos que definem aplicações multi-tenant. Comparando multi-tenant ao estilo de arquitetura tradicional, a Loja de Departamento citada acima no estilo single-tenant teria um servidor próprio local, isolados dos demais clientes, contendo a aplicação da empresa gerenciadora de documentos e o banco de dados. No modelo multi-tenant os servidores são remotos e fazem parte da infra-estrutura da empresa que fornece o serviço SAAS. Tanto a aplicação quanto o banco de dados são, no conceito primário, compartilhados entre as vários empresas (ou tenants). Tudo bem, na prática existem vários estilos de arquitetura multi-tenant onde há diferenças nas estratégias de compartilhamento de base de dados e recursos.
A priori pode parecer estranho, menos performático e menos seguro manter dados de empresas (clientes) distintas na “mesma base de dados” … Mas para aplicações SAAS este é o cenário mais adequado por um série de razões. Vamos à algumas vantagens e desvantagens do modelo single-tenant e multi-tenant.
Ter um servidor isolado no modelo single-tenant requer muito mais custo e exige muito mais trabalho de atualização de aplicação ou de manutenção. Geralmente este custo é repassado para o cliente. Imagine a trabalheira que dá para essa empresa gestora de documentos garantir a atualização de todos os servidores de seus clientes.
“Ah mas é pra isso que tem as tecnologias de deploy”
Exatamente é pra isso que tem as tecnologias, mas você entendeu o que eu quis dizer…
Modelo multi-tenant
Voltando, no modelo multi-tenant atualizar uma aplicação ou fazer uma manutenção é muito mais rápido e prático. Por outro lado, pode haver necessidade de customização de código e exige mais cuidado e complexidade para segregar os dados.
Dependendo da necessidade, na sua aplicação multi-tenant você poderá ter múltiplos servidores de aplicação, sendo gerenciados por um balanceador de cargas e acessando um servidor de dados. Esse servidor de dados pode ser na verdade um cluster.
A nível de aplicação a identificação dos tenants pode ser feita por meio de login, domínio, subdomínio e até mesmo por rotas. A aplicação irá fazer uma checagem para identificar o tenant e após identificação irá direcioná-lo ao seu contexto de aplicação e à sua partição de dados.
Segregação de dados
Para garantir a segregação dos dados existem algumas técnicas e modelos de arquiteturas voltados para aplicações multi-tenant. No modelo single-database, onde se utiliza um único banco de dados ou até mesmo uma única tabela, essa separação pode ser feita por meio de um tenant_ID. Também podem ser utilizados esquemas distintos para cada cliente (ou tenant).
Uma vantagem de utilizar o mesmo banco de dados é que isso facilita a geração de relatórios. Por outro lado, você pode ter clientes que possuem um pequeno volume de dados e clientes que possuem um grande volume de dados, o que pode causar sobrecarga.
Para finalizar, outra opção de separação de dados é o modelo multi-database, neste modelo cada cliente possui o seu próprio banco de dados ou base de dados. Este cenário permite mais segurança na separação dos dados e possibilita realizar com mais facilidade testes específicos para cada cliente. Exportar os dados de um determinado tenent também se torna uma tarefa bem mais simples.
Se a gente ir adiante mais um pouquinho, iremos topar num termo chamado persistência poliglota, que é o conceito da utilização de diferentes bases de dados para atender diferentes necessidades de armazenamento, de acordo com cada lógica de aplicação.
É isso pessoal, espero que tenham gostado do artigo!
