SaaS: Single tenant ou Multi-tenant, qual escolher?

Quando desenvolvemos um SaaS (Software as a Service) precisamos escolher a melhor arquitetura para compartilhamento de recursos e dados entre os usuários da aplicação.

Um dos primeiros erros cometidos ao se pensar na arquitetura é imaginar que isso afeta apenas o banco de dados mas os recursos que serão analisados aqui indicam tanto servidor quanto banco de dados.

Nesse artigo vamos discutir sobre as arquitetura Single tenant e Multi-tenant qual o melhor caso para se utilizar cada uma delas dependendo do tipo de software que você está desenvolvendo, tipo de cliente e nível de escala.

Single tenant

A arquitetura Single tenant segue o princípio de alocar uma instância do servidor e da base de dados por cliente, onde o cliente representa a empresa que contratou o software. Em alguns casos a separação é feita apenas na camada de dados mantendo o mesmo servidor para todos clientes.

O principal ponto dessa arquitetura é que ela “parece” mais escalávelapenas pelo tipo de distribuição dos seus recursos, mas não é porque os servidores e dados estão isolados que trará mais performance.

Por outro lado, seguindo essa arquitetura distribuída podemos investir menos tempo otimizando a performance da base de dados para melhorar a parte de balanceamento e escala dos nossos servidores.

Vantagens

Criação de servidores para clientes enterprise com precificação simples já que o serviço está isolado dos demais;
Possibilidade de ter versões diferentes ou testar updates incrementalmente em clientes e obter feedbacks antes de liberar para todo mundo;Alocação geográfica dos servidores a fim de diminuir a latência de conexão dos clientes;
Base de dados do cliente isolada dos demais facilitando o acordo de termos de segurança de dados;
A performance de um cliente jamais será afetada por algum processo executado por usuários de outro time;

Docker para o resgate

Um dos principais desafios para as arquiteturas Single tenant sempre foi a dificuldade para manter essa estrutura distribuída com muitas instâncias de servidores e bases de dados para os clientes.

Com a vinda do Docker e a facilidade de orquestração de containers com sua aplicação e base dados o trabalho para organização e controle de distribuição das instâncias por cliente tornam-se menores.

Ferramentas como Kubernetes estão tornando esse processo cada vez mais simples automatizando processos antes complicados como escalonamento horizontal e alocação de novas instâncias geolocalizadas a partir da origem do cliente.

Multi-tenant

Uma arquitetura Multi-tenant é reconhecida por ter apenas uma aplicação e uma base de dados para todos clientes separando-os apenas com chaves estrangeiras e relacionamentos no banco de dados.

Apesar de parecer menos segura e escalável, a arquitetura Multi-tenant é o melhor caminho para a grande maioria das aplicações SaaS. Isso porque ela oferece uma maneira fácil de iniciar e manter seu software.

Vantagens

Redução de complexidade para hospedagem e distribuição do servidor;
Facilidade para realização de deploy e distribuição de novas versões do código;
Redução de custos já que os recursos são compartilhados entre os clientes;
Fácil fornecer uma versão gratuita ou de testes já que não é necessário alocar uma nova estrutura por cliente;

Escalonamento

Mesmo tendo apenas uma base de dados ainda podemos escalar horizontalmente nossa aplicação criando mais servidores que acessam o mesmo banco utilizando alguma tecnologia como Docker.

O escalonamento horizontal nos permite dividir a carga aplicada em cada servidor através de um load balancer que controla o fluxo de requisição dos clientes entre as instâncias da aplicação.

A hora de decisão

Agora que já temos conhecimento dos dois tipos de arquiteturas para aplicações SaaS precisamos determinar por qual caminho seguir. Eu queria enrolar mais, mas na minha opinião a decisão é simples:

Vá de Single Tenant se você está construindo softwares para empresas públicas ou muito enterprises, a parte de separação dos dados e distribuição de versões com código modificado para cada cliente serão provavelmente impossíveis de evitar.

No restante dos casos, aplicações SaaS comuns com vários tipos de planos, inclusive freemium ou que não exijam diretamente acordos de segurança de dados muito formalizados deverão na maioria das vezes utilizar a arquitetura multi-tenant.

Concluindo

Creio que até aqui você já tenha tomado sua decisão, mas apenas para dar mais algumas palavras de luz para te guiar.

Acreditar que separar a quantidade de dados em várias bases sem relacionamentos vai diretamente impactar positivamente na performance da sua aplicação é um mito. Em boa parte dos casos, otimizar a base de dados é um trabalho mais simples do que escalonar seu servidor.

Dito isso, deixe um comentário se você gostou do post e bora desenvolver sua aplicação SaaS!