Multi-locação ou multi-instância?

Estou tentando criar uma solução SaaS baseada na Web e segui um caminho em que não tenho certeza de usar a multilocação ou a instância múltipla. Vou tentar descrever o que estou tentando alcançar, e cada abordagem tem vantagens e desvantagens (minha opinião, de acordo com o que li). Inclua suas sugestões no caso de eu ter perdido alguma coisa em uma abordagem em relação à outra.

O aplicativo que estou tentando criar é, como mencionei, uma solução SaaS onde as empresas podem criar suas contas, e cada conta / empresa possui seus próprios usuários, clientes, produtos, serviços ... etc. Cada usuário; quem é funcionário da empresa; relacionados a uma conta / empresa terão acesso apenas aos clientes, produtos e serviços de sua empresa. As empresas podem ter um número ilimitado de clientes, produtos e serviços, portanto, cada empresa deve ter seu próprio data center.

Para isso, decidi criar um banco de dados compartilhado (salvando todas as credenciais de usuários para fins de login) e um esquema compartilhado de vários bancos de dados (banco de dados por conta / empresa). Basicamente, multilocação .

Em seguida, alguém sugeriu o uso de várias instâncias , em que cada empresa terá sua própria instância do aplicativo (ou seja, código, bibliotecas, banco de dados, estruturas ... etc) totalmente separada das outras empresas. Isso soa melhor, pois não preciso cuidar de uma camada extra, na qual preciso garantir que os usuários de cada inquilino tenham acesso apenas aos dados da empresa. Eu acho bom mencionar que estou dependendo do Docker para alcançar essa abordagem (nunca a usei antes), mas acho que carece de recursos (mais detalhes sobre isso mais tarde) que precisarei no futuro (pelo menos não encontre-os com um pouco de pesquisa).

No entanto, cada abordagem vem com prós e contras, então não pude tomar uma decisão sobre qual abordagem seguir. Aqui está uma lista, mas exposta comigo, já que não tenho o conhecimento dos dois, para que possa haver algo que eu não conheça, ou uma solução para um problema que não encontrei na web: [Cada abordagem tem uma lista ordenada da qual eu segui uma comparação uma a uma]

Multi-locação :

1. Host / hardware compartilhado, código compartilhado e vários bancos de dados.
2. É mais fácil estender a funcionalidade do código e corrigir bugs (código compartilhado).
3. É mais difícil estender o hardware (poderia usar um serviço de nuvem) ou mover o banco de dados de inquilino individual para outro sistema sem fazer alterações no código.
4. Mais importante, como mencionei antes, preciso adicionar uma camada extra ao sistema para garantir que o usuário realmente pertença à sua empresa e não acesse as informações de outras empresas.

Multi-instância :

1. Host / hardware compartilhado ou não compartilhado, código por instância e banco de dados por instância.
2. É mais difícil estender a funcionalidade ou corrigir erros (não tenho certeza se existe uma maneira de fazê-lo no Docker, onde você pode adicionar funcionalidade / recurso a uma instância ou contêiner do Docker e implantá-lo nas outras).
3. É mais fácil mover a instância inteira para um host / hardware diferente.
4. Como instância, não preciso cuidar dessa camada, pois cada instância terá seu próprio banco de dados.

Todas as vantagens e desvantagens são redundantes, caso eu queira fazer algo manualmente (como criar uma instância para cada inquilino manualmente), e é por isso que duvido da solução Docker, a menos que haja uma maneira de resolver isso, que talvez seja a principal razão da pergunta. Eu apreciaria se você respondesse à pergunta com referências às soluções e por que você acha que essa abordagem é melhor que a outra.

Caso isso ajude (talvez?), Estamos usando o Laravel como a principal estrutura para o back-end (tudo RESTfully).

Estou me perguntando exatamente a mesma pergunta no momento.

Estou inclinado a encontrar uma solução de locação única para várias instâncias, mas ainda não tomei uma decisão definitiva. Deixe-me compartilhar alguns dos meus pensamentos:

A principal vantagem histórica da arquitetura de vários locatários é o melhor uso dos recursos de infraestrutura , por mutualização (SO único, banco de dados único, camada de aplicativo único) e melhor ocupação desses recursos (quando um usuário está ausente, outro pode usar o mesmo recurso) .

Ele também simplifica bastante o ciclo de vida do software : você implanta novas versões em uma instância, todos os clientes são atualizados ao mesmo tempo.

Parece, no entanto, que os recentes avanços na tecnologia de nuvem tornam a primeira classe de vantagens amplamente disponível em uma arquitetura de várias instâncias (instância por cliente) (estou pensando especificamente em uma plataforma como Jelastic aqui, mas tenho certeza de que há outras que fornecer os mesmos recursos):

• PaaS baseado em contêiner
• Provisionamento e dimensionamento automático de contêineres (contêineres elásticos)

Portanto, o gerenciamento de hardware e plataforma não é mais a preocupação do fornecedor de software. Os recursos são mutualizados com muito mais eficiência do que antes nos níveis de infraestrutura e plataforma .

Ainda haverá uma sobrecarga para várias instâncias (alguns aplicativos e middlewares serão executados N vezes em vez de apenas uma), mas muito mais baixos do que quando se usa uma máquina (virtual) separada por instância. O banco de dados pode ser compartilhado de qualquer maneira (um esquema por instância, vários esquemas por servidor de banco de dados)

Além disso :

• É possível automatizar a criação de novas instâncias via API PaaS
• A automação da implantação de novas versões é possível por meio da API PaaS, com tempo de inatividade zero (leva algum trabalho para ser implementado)
• A escala está sempre fora, nunca aumenta. Não precisamos nos preocupar com grandes conjuntos de dados no nível da instância.

Obviamente, precisaríamos de algum tipo de serviço central que gerencia tudo isso automaticamente (por exemplo, criação de instância quando um novo usuário cria uma conta). Isso também gerenciaria problemas de pagamento e licenciamento, interação entre instâncias etc. Esse serviço central pode ser bastante complexo e difícil de desenvolver, mas o bom é que não precisamos implementá-lo antecipadamente (agora que não temos muito recurso), enquanto o multilocatário precisa ser incorporado ao aplicativo desde o início.

O que me leva às vantagens finais do desenvolvimento de um único inquilino para um projeto de inicialização em estágio muito inicial (pré-investimento):

• A mesma versão (ou quase a mesma) do aplicativo pode ser implantada no local como um dispositivo virtual ou contêiner de docker ou até mesmo em uma máquina gerenciada pelo cliente (algumas empresas ainda relutam em relação à nuvem e pode ajudar uma inicialização inicial a não empurrar importantes adotantes iniciais)
• Mais rápido para lançar um produto com recursos limitados (a camada de aplicativos e o esquema do banco de dados é bem menos complexo), pode obter um MVP (MVP) para usuários iniciantes e mostrar o valor comercial do aplicativo potenciais investidores e adicione toda a automação da nuvem mais tarde
• Pode ser visto como um argumento de venda para clientes preocupados com a segurança dos dados : os dados são melhor encapsulados, pois cada cliente possui seu próprio esquema ou mesmo banco de dados. Muito menos risco de "derrame"

NB: Obviamente, estou pensando aqui em um aplicativo de negócios em que os clientes seriam empresas (cada uma com vários usuários individuais) e não indivíduos. Não faria sentido executar uma instância separada de um aplicativo para cada usuário individual (ou seria?)

Também é possível oferecer suporte a ambas as opções (um pool de inquilinos em várias instâncias).

Sou a favor da causa de várias instâncias do isolamento natural. A instância de cada cliente é executada em seus próprios processos e seus dados são isolados em seu próprio banco de dados. Você pode atualizar instâncias para novas versões, por cliente / instância, quando desejado.

Os sistemas baseados em inquilinos têm um risco de segurança da informação. Considere como é fácil esquecer uma cláusula "WHERE tenantId = x". O principal motivo para usar um sistema com capacidade de inquilino seria o desempenho, os processos são pesados, compartilhando um processo que você pode potencialmente obter mais de uma máquina. Acho que isso era mais verdade em um mundo de 32 bits do que hoje em dia em máquinas de 64 bits com muito mais RAM.

Um sistema com várias instâncias talvez precise de um pouco mais de ferramentas para criar e configurar o ambiente, como bancos de dados e instâncias de aplicativos da web. Pode-se argumentar que você precisa ter esse script de qualquer maneira também para implantações de instância única. Isso também tem outras vantagens, como a capacidade de configurar ambientes de desenvolvimento e teste

Deixaria de fora os recursos do inquilino até que você possa justificá-lo (custo de engenharia versus dinheiro economizado na infraestrutura (hardware) por meio do compartilhamento de processos).