A ABC71 está finalizando uma versão SaaS de seu ERP e um parceiro interessado nos perguntou se tínhamos estruturado uma solução multi-tenant, já que para ele esta era uma questão importante. No contexto de aplicações publicadas como serviço na internet – o SaaS – “tenant” diz respeito a infraestrutura alocada num servidor e que é destinada a suprir a demanda de cada cliente da aplicação web.
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 uma única instalação no servidor, com todos os Clientes compartilhando o mesmo ponto de entrada para a aplicação. Do ponto de vista 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ó. É necessá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 envolve 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 que se seguem 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 :
Fonte : Balaio Tecnológico
1 Comentários
Obrigado pelo ótimo artigo, me ajudou muito..