Modelos de locação para um aplicativo multi-tenant

Frequentemente ouvimos sobre a importância de criar um aplicativo multi-tenant, especialmente no contexto do desenvolvimento de um Software como Serviço (SaaS).

Há alguma confusão sobre o conceito de um "aplicativo multi-tenant" e os vários modelos usados para desenvolvê-lo. Neste artigo, olhamos mais de perto para esses termos de uma forma mais prática.

Entenda os diferentes modelos de locação de um ponto de vista técnico#

Arquitetura single-tenant#

A arquitetura single-tenant é um modelo de software ou computação em nuvem onde cada cliente ou locatário possui uma instância dedicada de um aplicativo ou serviço. Se olharmos para a origem do modelo de negócios B2B, ele começa com cada instância do software atendendo a apenas um cliente ou organização.

Características#

• Isolamento: Cada cliente ou locatário opera em um ambiente isolado com recursos, bancos de dados e configurações dedicadas.
• Personalização: Arquiteturas single-tenant frequentemente permitem maior personalização e flexibilidade para atender às necessidades específicas do cliente.
• Segurança: Segurança e privacidade de dados aprimoradas, já que os dados dos clientes não são misturados com os de outros locatários.
• Escalabilidade: Escalar recursos e capacidade pode ser mais simples, já que a instância de cada locatário pode ser ajustada de forma independente.
• Manutenção: Manutenção e atualizações independentes, já que mudanças feitas no ambiente de um locatário não afetam outros.
• Custo: Tipicamente custos maiores de infraestrutura e operação devido à necessidade de manter instâncias separadas para cada locatário.

Exemplos#

• Hospedagem dedicada: Provedores tradicionais de hospedagem web oferecem arquiteturas single-tenant, onde cada cliente obtém seus próprios recursos, bancos de dados ou configurações.
• Software on-premises: Alguns aplicativos de software de nível empresarial, como sistemas de gerenciamento de relacionamento com o cliente (CRM) ou sistemas de gerenciamento de recursos humanos (HRMS), oferecem opções de implantação single-tenant para organizações com requisitos rigorosos de segurança de dados e personalização.
• SaaS com camadas premium: Em algumas ofertas de Software como Serviço (SaaS), camadas premium ou empresariais fornecem opções single-tenant para clientes que necessitam de segurança, conformidade ou personalização aprimoradas.

A arquitetura single-tenant é comumente usada em cenários onde a conformidade é fundamental ou há necessidade de requisitos de segurança personalizados. Por exemplo, indústrias como finanças, saúde e governo, que possuem requisitos regulatórios rigorosos, frequentemente preferem soluções single-tenant para garantir conformidade.

No entanto, é importante notar que arquiteturas single-tenant podem ser mais intensivas em recursos e complexas de gerenciar em comparação com arquiteturas multi-tenant, já que cada instância de cliente requer sua própria infraestrutura e manutenção. Como resultado, elas podem ser mais adequadas para aplicativos com menos clientes, mas maiores, ou quando personalização e isolamento são críticos.

Arquitetura multi-tenant#

Multi-tenant em software é uma arquitetura de software na qual uma única instância de software roda em um servidor e serve a múltiplos locatários. Sistemas projetados dessa maneira são "compartilhados" (ao invés de "dedicados" ou "isolados"). Um locatário é um grupo de usuários que compartilha acesso comum com privilégios específicos à instância do software. Com uma arquitetura multi-tenant, um aplicativo de software é projetado para fornecer a cada locatário uma parte dedicada da instância - incluindo seus dados, configuração, gerenciamento de usuários, funcionalidade individual do locatário e propriedades não funcionais. -- Wikipédia

Características#

• Recursos compartilhados: Múltiplos locatários compartilham a mesma infraestrutura, incluindo servidores, bancos de dados e recursos de rede, para otimizar a utilização de recursos.
• Isolamento: Dados e configurações dos locatários são logicamente segregados, garantindo privacidade e segurança dos dados.
• Economias de escala: A multi-tenancy pode ser econômica, pois os custos gerais são distribuídos entre múltiplos usuários, reduzindo custos operacionais e de infraestrutura.
• Escalabilidade: A arquitetura pode escalar horizontalmente ou verticalmente para acomodar números crescentes de locatários e usuários.
• Manutenção: Atualizações e manutenção são simplificadas, pois mudanças se aplicam uniformemente a todos os locatários, facilitando o gerenciamento.
• Personalização: Embora alguma personalização seja possível, normalmente é mais limitada em comparação com arquiteturas single-tenant para manter a consistência do sistema.

Exemplos#

• SaaS baseado em nuvem: A maioria dos aplicativos de Software como Serviço (SaaS), como Google Workspace e Salesforce, empregam multi-tenancy para atender múltiplas organizações ou usuários em uma plataforma compartilhada.
• Hospedagem compartilhada: Em hospedagem web, serviços de hospedagem compartilhada hospedam múltiplos sites no mesmo servidor, cada um pertencente a um cliente ou organização diferente.
• Serviços de nuvem pública: Provedores de nuvem pública, como AWS e Azure, usam multi-tenancy para atender a diversos clientes com recursos virtualizados isolados dentro de data centers compartilhados.
• Soluções de infraestrutura em toda a empresa: Como um cluster Kubernetes compartilhado usado por múltiplas unidades de negócios dentro de uma organização.

Redefinindo apps multi-tenant no mundo real#

Fornecemos definições de uma perspectiva arquitetônica, tornando simples distinguir entre designs multi-tenant e single-tenant. No entanto, isso pende mais para a definição técnica. Se usarmos essas definições em nosso ambiente de desenvolvimento do mundo real ao projetar modelos de locação, essa forma de pensar assume que um app multi-tenant deve ter uma infraestrutura puramente compartilhada e multi-tenant.

No entanto, negócios e produtos variam muito e têm muitos requisitos caso a caso, então não há uma solução única para todos.

Imagine um cenário onde um locatário está utilizando recursos de uma infraestrutura compartilhada, mas devido a necessidades específicas de negócios, eles requerem uma ou duas partes do sistema exclusivamente dedicadas a eles. Essas partes dedicadas poderiam ser o banco de dados, instâncias, ou uma combinação de outros componentes, tudo isso enquanto compartilham a infraestrutura geral. É aqui que a arquitetura de locatário misto entra em ação.

No desenvolvimento prático de produtos SaaS, é comum encontrar um cenário onde um produto é projetado principalmente com um modelo genérico de multi-tenancy. No entanto, certos aspectos da arquitetura ou recursos podem seguir uma abordagem "single-tenancy".

A AWS usou o seguinte caso como exemplo para comunicar este conceito: multi-tenancy é um conceito amplo, e é caso a caso combinar e escolher a estratégia certa para definir o que você quer alcançar com recursos compartilhados e isolamento de dados.

Em outras palavras, às vezes as pessoas ainda chamam esse modelo de “Multi-tenancy”, então na definição mais ampla de multi-tenancy, isso não implica que todos os componentes de uma solução são compartilhados. Em vez disso, implica que pelo menos alguns componentes de uma solução são reutilizados entre múltiplos locatários.

Entender esse termo de forma ampla pode ajudar você a se empatizar melhor com as necessidades de seus clientes e de onde elas vêm.

Em vez de se fixar em um único modelo arquitetônico, a multi-tenancy reflete a praticidade da arquitetura de um produto SaaS no mundo real. Quando nos referimos a um app multi-tenant, isso não significa necessariamente que o app adere a um modelo arquitetônico; ele pode utilizar várias estratégias de locação, indicando que pelo menos alguns de seus componentes são compartilhados.

Considerações importantes para determinar sua estratégia de modelo de locação#

Aqui vem a questão, como eu proponho a estratégia de locação para meu produto? Aqui estão algumas perguntas importantes para pensar:

• Quais são seus objetivos de negócios?
• Uma solução single-tenant pode apoiar seus planos futuros de crescimento?
• Quão grande é sua equipe de operações, e quanto de seu gerenciamento de infraestrutura pode ser automatizado? Você se importa com agilidade e eficiência de custos?
• Seus clientes estão confortáveis com várias opções de multi-tenancy?
• Como cada opção impacta a conformidade, tanto a sua quanto a de seus clientes?
• Você está previsto para cumprir acordos de nível de serviço (SLAs) ou atingir objetivos específicos de nível de serviço (SLOs)?
• Você considerou segurança, custo, desempenho, confiabilidade e capacidade de resposta às necessidades individuais dos locatários como um todo?

Lembre-se de que não há uma divisão rígida em seu produto onde você deve optar por um modelo puramente multi-tenant ou exclusivamente single-tenant. Sua decisão deve se basear em como você divide os componentes arquitetônicos de seu produto e os níveis específicos de isolamento necessários para seus clientes ou negócios. Você pode, então, aplicar diferentes abordagens de acordo.

Próximo#

Falamos sobre a “nova” definição de um app multi-tenant, no entanto, e quanto ao isolamento de locatários, identidades, e como determinar se suas identidades devem ser isoladas ou não? O que significa para identidades serem "isoladas"?

A confusão frequentemente surge ao lidar com situações onde um usuário do mundo real tem duas identidades diferentes. É apropriado rotular essa situação como "identidades isoladas"?

Abordaremos essas perguntas em nossa próxima série de artigos. Fique ligado!