Assim, uma aplicação multi-tenant é aquela capaz de administrar essa infraestrutura com o menor custo possível, sem que isso afete a performance, a escalabilidade ou a segurança da solução como um todo. Em outras palavras, a aplicação consegue gerenciar a adesão de novos Clientes enquanto garante a segurança dos dados (para que um Cliente não acesse os dados dos outros), a escalabilidade (para que a infraestrutura suporte o aumento de carga inerente a novas adesões) e a responsividade do serviço (para que os acessos dos Clientes ao serviço sejam atendidos num tempo adequado).
Tendo tais considerações em mente, a primeira característica de uma solução SaaS multi-tenant é que ela deve ter um única instalação no servidor, com todos os Clientes compartilhando o mesmo ponto de entrada para a aplicação. Do ponto de visto do fornecedor da aplicação, há uma implicação muito importante para essa decisão: é preciso manter apenas uma instalação, o que reduz custos com espaço (hardware) e simplifica a criação do ambiente inicial para novos Clientes. Do ponto de vista do usuário, a simplificação garante agilidade para que o serviço esteja plenamente disponível logo após a adesão dele ter sido efetivada. Isto é, nenhuma outra providência tem que ser tomada pelo Cliente ou pelo Fornecedor para que todo o ambiente esteja pronto para operação. Esta é uma característica marcante de soluções SaaS.
Isso nos remete à segunda parte da definição: como garantir segurança, escalabilidade e responsividade da solução ? Obviamente, é preciso começar com o planejamento de uma boa infraestrutura de hardware que comporte o movimento esperado para o site. Mas não só. É nescessário ainda ter seu projeto de software preparado adequadamente, mesclando técnicas de programação com uma implementação apropriada do banco de dados. A implementação do banco de dados, aliás, merece uma atenção extra para que se possa equilibrar os requisitos já citados com a facilidade de criação do ambiente para cada novo Cliente.
Uma proposta é manter uma única base de dados que diferencie quais registros pertencem a qual Cliente. Isto pode ser feito através de um código de identificação que seja único por Cliente, o que implica necessariamente que cada tabela do sistema deve guardar essa identificação e que todas as operações devem ser levadas a cabo informando-se esse código. Caso contrário, o sistema teria uma grave falha de segurança, com Clientes enxergando dados uns dos outros. Esse tipo de solução é retratada na figura abaixo:
Porém, esse solução embute algumas restrições. Como todos os Clientes compartilham o mesmo banco de dados, fica difícil entregar uma cópia isolada dos dados de um Cliente caso ele solicite. Pela mesma razão, se torna complexo dispor de ferramentas que deem muita liberdade ao Cliente - como um construtor de relatórios ou algo que permita a ele submeter consultas diretamente ao banco.
Um outro aspecto importante pra se preocupar nesta solução é o modo como as consultas (queries) são montadas. Um sistema como um ERP costuma ter operações que envolvem grande massa de dados - cálculo de custos ou execução do MRP, por exemplo. Dependendo de como as consultas são montadas, a tabela pode entrar em lock, comprometendo a experiência dos demais usuários da aplicação Web. Por isso, para esse cenário a melhor opção é a criação de um banco de dados separado para cada novo Cliente.
Com o banco isolado, podemos facilmente enviar ao Cliente um cópia de backup apenas com os dados específicos dele. Ferramentas mais elaboradas também se tornam mais simples de se implementar pois não precisam embutir inteligência extra para bloquear o acesso a dados de outros Clientes que estejam na mesma tabela. Criar um novo banco para cada Cliente não é um processo complexo, podendo ser executado automaticamente com scripts. Por fim, essa é uma solução escalável pois o próprio gerenciador de banco de dados pode ser preparado para fazer o balanceamento de carga, inclusive alocando novos bancos em locais distintos se isso for necessário.
A imagem abaixo ilustra essa nova abordagem:
Uma vez que o ponto de entrada é o mesmo pra todos os Clientes, um pequeno banco auxiliar (ou outro mecanismo semelhante) tem que ser implementado para direcionar as requisições ao banco de dados correto. Mas isso praticamente não causa impacto na performance da solução.
Após essa discussão, podemos considerar que o contrário de multi-tenant é algo com um multi-instance, onde cada novo Cliente é associado a um ambiente completo exclusivo para si. Isto é, ele acessa sua própria instalação do sistema, com sua própria versão da aplicação, configurações, pastas e banco de dados. Em um ambiente SaaS, este tipo de solução de infraestrutura pode rapidamente tornar o negócio inviável já que ela implica em custo maior para comportar instalações de todos os Clientes. Além disso, o multi-instance não escala tão bem.
Todas as variáveis apresentadas aqui foram levadas em conta quando a ABC71 planejou sua solução SaaS. Os links abaixo nos forneceram outras informações sobre o conceito de multi-tenant e uma visão mais abrangente sobre estratégias de planejamento do banco de dados :
8 comentários :
Pelo que entendi, seria um banco pra cada cliente e uma versão do sistema pra cada cliente, também.
Tem como eu utilizar o mesmo core, mudando apenas o banco ?
Você falou que acha inviável utilizar o multi tenant. Tem alguma sugestão melhor? Por quê estou querendo fazer um sistema desse modo, cada cliente com seu banco e acessando o mesmo core. Ai descobri sobre o multi tenant. E estava pensando em implementar ele.
Gabriel
Acho que houve algum ruído na comunicação ... Acredito que o uso de um único core é a melhor arquitetura para uma solução SaaS. Como eu disse no final do post, a arquitetura multi-instance pode inviabilizar o negócio por apresentar custos crescentes de manutenção das instalações, que têm que ser distintas para cada Cliente.
O que eu disse preferir é a solução multi-tenant onde cada Cliente possui seu próprio banco de dados. A outra opção, onde todos os Clientes compartilham o mesmo banco de dados, introduz uma complexidade na aplicação que a torna mais difícil de se gerenciar.
Excelente post, hj tenho um sistema no padrao mult-instance e com o tempo acabei achando inviável essa solução pela demanda grande de hardware e espaço em disco (utilizamos o MongoDB)..meus planos para o futuro é reescrever nossa app baseado no multi-tenant utilizando um banco de dados relacional, minha dúvida é, como isso funciona juridicamente, já que os dados estão misturados entre os clientes. Isso pode trazer algum tipo de problema, mesmo fornecendo backups via CSV, etc....
Obrigado!
Samir
Embora eu não tenha conhecimentos jurídicos, acredito que o fato de os dados de todos os Clientes estarem no mesmo banco não constitui um problema em si. Mas, provavelmente seu contrato garante que as informações poderão ser vistas ou manipuladas apenas por usuários autorizados; falhar de alguma forma nessa garantia (ou qualquer outra contratual) certamente trará dores de cabeça.
Por isso, sua aplicação deve estar muito bem amarrada para garantir continuamente a segurança das informações, ainda mais nesse cenário de BD único.
[]s
Olá,
Esse post é um pouco antigo, mas gostaria de apresentar uma dúvida talvez um pouco difícil de resumir:
Primeiramente parabéns pelo post, bastante didático.
Em segundo lugar, considerando:
-Que eu tenha uma máquina virtual(MV) rodando o servidor de aplicação(SA) de core único
-Outra MV rodando servidor de Bando de Dados (BD) onde cada cliente possui seu próprio BD
Se houver uma atualização que envolva alterações no SA e no BD eu poderia:
1. Criar uma nova MV com nova versão do SA e ir redirecionando os clientes para a nova MV com a nova versão aos poucos.
Porém, ao redirecionar um cliente para nova MV eu terei que parar toda empresa de cada cliente para fazer atualização no BD e redirecionar todos funcionários ao mesmo tempo para nova versão.
Isso realmente me encomoda, pois há empresas com muitos funcionários e isso trás um inconveniente(=custos) muito grande para o fornecedor da empresa do sistema e para o cliente tb.
Uma forma ideal, não necessariamente possível, cada funcionário receberia uma notificação de atualização, que poderia ser atendida em momento oportuno, de forma que aos que optam por atualizar em outro momento, continuam acessando versão do sistema antigo, com versão do BD antigo, e os que optam por atualizar acessam a nova versão do sistema, com a nova versão do BD, sem haver qualquer comprometimento nos dados.
Minha pergunta é: Existe alguma forma de se aproximar desse modelo que eu vejo como ideal?
Rafael
Em relação ao BD, não há muito o que fazer. Mesmo que a solução fosse local (e não via internet), reorganizar a base de dados exigirá que os funcionários deixem de usar o sistema durante o processo. Para minimizar o impacto, escolha uma hora em que menos usuários estejam acessando. Também agende a mudança com antecedência, notificando os usuários sobre o período em que a aplicação ficará fora do ar "para manutenção". Com isso, eles poderão se planejar para o evento.
Quanto ao Client da aplicação, uma boa política de atualização é mesmo criar um redirecionamento intermediário. Isto é, você mapeia o cliente (talvez pelo IP externo) e redireciona suas requisições para o SA correto, dependendo se a versão que ele deve enxergar é nova ou ainda é a antiga. Não conheço o IIS o suficiente para dizer se você pode fazer o redirecionamento por lá. No caso da ABC71, nós optamos por criar uma aplicação para controlar esse redirecionamento pois já tinhamos um BD intermediário para controlar outras informações.
[]s
Muito obrigado pelo esclarecimento.
Perguntei na esperança que existisse alguma maneira ou ferramenta que eu desconhecesse.
Sucesso!
Boa tarde Luís Gustavo, ótimo texto/explicação. Muito obrigado pela contribuição. Forte abraço!
Postar um comentário
OBS: Os comentários enviados a este Blog são submetidos a moderação. Por isso, eles serão publicados somente após aprovação.
Observação: somente um membro deste blog pode postar um comentário.