Suporte à multilocação

Quais são os desafios típicos que surgem ao converter um aplicativo de locatário único em um aplicativo de vários locatários? Segurança e isolamento de dados me parecem os mais significativos. Quais são alguns outros?

Sou um dos arquitetos de um esforço de automação bastante significativo e, historicamente, é apenas a nossa empresa que o utiliza. Queremos tornar possível que outras pessoas o usem também. Toda vez que falamos em "tornar o multitenant", a conversa gira em torno de manter os usuários com um inquilino longe dos dados de outro inquilino e garantir que os usuários com um inquilino não possam (intencionalmente ou inadvertidamente) criar impactos em outro ambientes do inquilino. O que me pergunto é se o isolamento de segurança / dados é realmente a única grande preocupação aqui ou se existem outras preocupações importantes em que não estamos pensando.

architecture multitenancy

— Grant Palin
fonte

A solução mais fácil? Uma nova instância de todo o sistema, incluindo hardware, vazio, do zero, um novo sistema por inquilino. Se o sistema e os dados forem bastante valiosos, essa pode ser uma boa opção. Se você não gosta de novo hardware para cada instância - use a virtualização. Pode não ser mais eficiente, mas certamente economizará uma tonelada de dores de cabeça.

— SF.

Provavelmente, do ponto de vista do design, é o mais fácil, mas do ponto de vista administrativo, não parece ser. Pelo menos nossos administradores de sistema não estão muito animados com esta proposta. (E sim, estamos usando VMs.) Muito mais instâncias para gerenciar (monitoramento, implantação etc.) Na verdade, estamos procurando maneiras de tornar isso mais gerenciável para obter algum isolamento físico aqui, mas, aparentemente, isso abordagem parece trocar simplicidade do desenvolvedor pela simplicidade do administrador ...?

Respostas:

Além do silenciamento de dados, você pode ter problemas com

Disponibilidade - com um único inquilino, eles só podem fazer DoS eles mesmos, mas mesmo quando os dados são devidamente isolados, um inquilino ainda pode esgotar os recursos.
Log - todas as mensagens de log assumiram um único inquilino. A menos que você faça o silo de logs por inquilino, suas mensagens de log poderão se tornar menos úteis.
Simultaneidade - os aplicativos de inquilino único podem ser executados com carga moderada ou a alta contenção de alguns bloqueios pode serializar efetivamente determinadas operações. Se os bloqueios forem multiplicados por inquilino, você poderá começar a ver a intercalação de operações que não aconteceram antes. As condições de corrida que eram muito improváveis de se manifestar agora podem agora se manifestar.
Novas fontes de contenção de recursos - onde antes você pode ter n soquetes e m identificadores de arquivo, agora multiplique esse inquilino.
Compensações de configurabilidade / compatibilidade com versões anteriores - onde antes que você possa obsoleta um componente ao implantar uma substituição, agora você pode ter um inquilino exigindo um componente e um inquilino exigindo que o componente antigo que ele substitui permaneça indefinidamente.
Alvo de intimação - atualmente você é um alvo de intimação para problemas relacionados à sua empresa. Com vários inquilinos, pode ser necessário responder a solicitações de intimação mesmo quando você não é parte da ação legal.

Alguns deles assumem que você está executando todos os inquilinos no mesmo espaço de endereço (máquina ou cluster). Se cada inquilino estiver executando seu software em seu hardware, você pode discutir algumas das opções acima e adicionar:

Dificuldades ao acessar máquinas para depuração.
Solicitações de suporte para versões mais antigas.
Solicitações para permitir que contratados de terceiros configurem.
Menos controle sobre o hardware em que é executado.
Menos controle sobre o ciclo de correção / atualização do sistema operacional em que é executado.

— Mike Samuel
fonte

O maior problema na multilocação na minha opinião é a personalização. Isso acontece rotineiramente se você estiver vendendo um aplicativo de negócios para empresas. Pode variar de algo tão simples quanto todo cliente que deseja sua própria aparência à capacidade de configurar campos, regras, formulários e relatórios adicionais. O nível de personalização que você precisa suportar desempenha um papel crítico na arquitetura.

— Sriram
fonte

A resposta de Mike é muito boa, e muitos dos pontos por lá quase subestimam sua complexidade devido à sua falta, então leve isso a sério.

Um ponto que eu acrescentaria é que você deve ter boas ferramentas de gerenciamento para criar (e mais tarde gerenciar) novos inquilinos. Dependendo da arquitetura física que você utiliza, isso pode estar longe de ser trivial e é algo que geralmente é esquecido. Os benefícios de um software como produto de serviço realmente só entram em jogo quando há um grande número de inquilinos; portanto, uma quantidade razoável de esforço deve ser utilizada para atender a isso.

Estender a resposta de Sriram; a personalização por inquilino é praticamente proibida, tudo o que um inquilino queira alterar deve ser configurável . Por exemplo, se sua solução não atender à adição dinâmica de campos de dados em pelo menos algumas áreas importantes, você provavelmente será inundado de solicitações de personalização. É um dos poucos casos em que um pouco adiantado complexidade adicional que realmente pagam off (digamos que ele vai contra YAGNI, ou, pelo menos, este nível de configuração é quase um requisito fundamental, para que você está vai precisar dele).

— Daniel B
fonte

Por que a personalização é "proibida"? É certamente tecnicamente viável. Existem muitos padrões diferentes que permitiriam a reutilização do sistema principal para vários inquilinos, enquanto ainda forneciam peças personalizadas para inquilinos individuais. Se um cliente estiver disposto a pagar pela personalização, seria razoável considerá-la. Existem muitos produtos multitenant que possuem personalizações por cliente por esse motivo. É mais do espírito da YAGNI IMO permitir a extensibilidade e não o padrão para tornar tudo configurável.

— RationalGeek

Bem, estou me referindo a implementações de software como serviço, em geral (de "multilocação"). Claro, é tecnicamente viável, mas vai contra os fundamentos do SaaS. Em termos financeiros, você está obtendo custos mais baixos compartilhando a implementação e provavelmente a infraestrutura de muitos inquilinos. Isso permite que você ofereça seu produto a um preço mais baixo, capturando assim a "cauda longa" do mercado (um grande número de pessoas dispostas a pagar apenas uma pequena quantia). Você pode manter talvez 5 ramos de um sistema, mas não 15000, e é para isso que o SaaS se destina.

— Daniel B

No nível corporativo, vejo frequentemente fornecedores de SaaS dispostos a fazer personalizações significativas em seus códigos para conseguir um cliente. Quando um cliente está pagando 6 ou 7 números pelo serviço, esse provavelmente é um modelo de negócios razoável.

— RationalGeek

Sim, nesses casos, acho que sim. A maioria das alterações que vi foram implementadas como novos recursos configuráveis que, por padrão, foram desativados para clientes existentes. O problema, penso eu, é quando os primeiros 3 ou 4 clientes recebem tratamento especial, porque a solução ainda está para decolar. A solução acaba sendo muito específica e cria uma cultura de "OK, vamos invadir". Mas sim, concordo com o seu comentário sobre grandes clientes.

— Daniel B

Esta é uma distinção útil que vocês estão fazendo em torno da personalização. Eu acho que o mesmo conceito também se aplica à capacidade de gerenciamento. Nossa multilocação provavelmente visa relativamente menos clientes maiores do que clientes de cauda longa. Se o principal objetivo da multitenancy é capturar cauda longa, pode não ser a abordagem certa para nós. Obrigado por essas reflexões.