Neste artigo veremos o que é e quais são os modelos arquiteturais aplicados ao Multitenancy, que trata do compartilhamento de uma instância de uma aplicação ou banco de dados para múltiplos clientes. Será demonstrado como seu uso tornou-se importante por causa do cenário favorável que o SaaS (Software as a Service) proporcionou à indústria de TI. Finalmente, exemplificaremos o seu uso com o foco voltado para a modelagem de dados, utilizando para isso o framework Hibernate Shards.
Para que serve:
A construção de um SaaS não pode ser baseada somente em modelos arquiteturais convencionais. O SaaS possui características que exigem modelos adequados. Este artigo demonstra quais são e como construir tais modelos Multitenancy com o Hibernate Shards.
Em que situação o tema útil:
Além de ser um tema fundamental na carta de conhecimentos de qualquer arquiteto ou desenvolvedor na atualidade, o artigo é útil para aqueles que já trabalham ou pretendem trabalhar com a construção de SaaS. O mesmo auxiliará na tomada de decisões sobre o modelo arquitetural Multitenancy e o uso do Hibernate Shards como ferramenta de implementação.
Resumo DevMan:
Devido ao custo/benefício do SaaS e suas possibilidades de economia em termos e infraestrutura e software, ele ganhou um grau de importância significativo no mercado. Por isso, trabalhar com os melhores modelos arquiteturais para atender a esse tipo de abordagem é algo fundamental para arquitetos e desenvolvedores.
O Multitenancy é uma estratégia que através de seus modelos arquiteturais consegue fazer com que uma instância de aplicação ou banco de dados rode sobre um servidor sendo compartilhado entre vários clientes. Assim, é possível oferecer estabilidade, eficiência, segurança e escalabilidade individualizada para os clientes de um serviço.
O Hibernate Shards é o framework que pode auxiliar na diminuição do grau de complexidade de uma modelagem de dados Multitenancy. Adequando-se às estratégias arquiteturais adotadas pela equipe de desenvolvimento, o Hibernate Shards contribui significativamente para a construção de aplicativos SaaS utilizando particionamento horizontal.
O software como serviço, do inglês Software as a Service (ou SaaS), tornou-se um instrumento de grande importância para o fluxo de bens e serviços do produtor para o consumidor, devido ao seu custo/benefício. Por isso, elaborar os melhores modelos arquiteturais para atender a esse tipo de abordagem é algo fundamental.
Muitos arquitetos de software acostumados à construção de modelos arquiteturais que rodam sobre servidores locais, com infraestrutura própria, quando se vêem diante do desafio da construção de um SaaS pensam que esse mesmo tipo ao qual estão acostumados pode ser utilizado para sua construção. Isso é um erro, pois um SaaS possui diferenças de infraestrutura, software e dados que devem ser levados em consideração e exigem modelagens arquiteturais adequadas.
Tendo em vista esse cenário, conceituaremos neste artigo um modelo arquitetural conhecido como Multitenancy e exemplificaremos seu uso através do framework Hibernate Shards. Multitenancy não é um modelo que abrange somente a Arquitetura de Software, mas também a Arquitetura de Dados. Desta forma, ambas as arquiteturas não poderiam ser tratadas em um único artigo, por se tratarem de assuntos muito extensos. Por isso, concentraremos nossos esforços em cima da Arquitetura de Dados para abordar o modelo Multitenancy. A Arquitetura de Software será vista nesse artigo de uma maneira superficial, apenas para fins de compreensão.
Multitenancy refere-se a um modelo arquitetural onde uma instância de uma aplicação ou banco de dados que roda sobre um servidor pode ser compartilhada entre múltiplos inquilinos (do inglês, tenants), sem que um tenha conhecimento do outro. Apesar deste modelo arquitetural se tratar de uma estratégia bastante adotada na década de 60 por organizações que alugavam espaço e poder de processamento em mainframes para reduzir gastos computacionais, este conceito veio à tona com o advento do modelo de Software as a Service (SaaS) em nuvem.
Desde o momento em que as aplicações passaram a ser oferecidas como serviços a muitas organizações, começaram a surgir necessidades de tecnologias e modelos arquiteturais que fossem especificamente voltados para operar em nuvem, visando fornecer uma oferta escalável em SaaS. Apoiado por essas necessidades, o sucesso do modelo em nuvem tem sido cada vez maior, e com isso, muitas opções em soluções arquiteturais são apresentadas à indústria de TI. Por conta dessa variedade, vemos os modelos arquiteturais on-premise sendo utilizados de forma secundária e os modelos off-premise se tornando uma solução primária.
O termo On-premise é utilizado para designar os softwares que são instalados e rodam sobre servidores locais. O modelo Off-premise baseia-se no acesso remoto de um software que pode estar rodando em qualquer lugar na nuvem.
O modelo On-premise foi amplamente utilizado como primeira opção dos profissionais de TI e organizações para projetos de software até a primeira década do século XXI, quando o modelo Off-premise começou a ser amplamente utilizado com o advento da computação em nuvem.
Organizações versus Fornecedores SaaS
Em 30 de julho de 2008, a Gartner – mais importante empresa de pesquisa de Tecnologia da Informação e consultoria do mundo – informou que 90% dos sites de E-commerce usariam pelo menos um serviço baseado em SaaS até 2013. Como podemos perceber, nunca se falou tanto em SaaS como na atualidade, mas apesar de toda atenção dada ao tema, o desconhecimento de que o SaaS representa um novo paradigma de fornecimento de software, um modelo arquitetural que deve fornecer estabilidade e eficiência para os seus utilizadores, gerou certa falta de confiança por parte das organizações, se tornado um fator de indecisão sobre sua adoção.
Devido ao grau de importância que os dados possuem aos olhos das organizações, podemos afirmar que eles são o mais importante acervo de qualquer negócio, por exemplo: os dados sobre clientes, fornecedores, vendas, compras, etc. No que se refere ao que chamamos de “Santo Graal” do SaaS, os dados ganham merecidamente esse posto. Por essa conclusão, verifica-se muitas vezes que uma organização prefere manter seus softwares e bancos de dados instalados em um hardware que pertence à própria organização, com redes de dados muitas vezes limitadas, do que permitir que a segurança e controle contra acessos indevidos de seus dados sejam confiados a um fornecedor SaaS. Essa desconfiança impede que as organizações usufruam de todas as vantagens de custo/benefício que um fornecedor SaaS possa oferecer, tais como: poder de processamento por demanda, capacidade de armazenamento expansível e, principalmente, não precisar investir em uma caríssima infraestrutura para manter disponibilidade e escalabilidade, caso haja uma necessidade maior dos utilizadores do serviço.
...
