Aprofundando-se na noção de "multi-tenant" e compartilhando nossos insights sobre como o percebemos.
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.
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.
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.
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
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.
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:
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.
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!