Esse modelo de oferta é conhecido como SaaS (Software as a Service). Muitas vezes, o desenvolvedor empreendedor até já comercializa uma solução de software no mercado como um “produto de prateleira” (vendendo uma única instância do software para cada cliente), mas deseja adaptá-la ao modelo de SaaS.
Para isso, é necessário realizar algumas modificações no código fonte do produto para permitir que uma única instância seja usada por múltiplos clientes. Tais modificações podem ser feitas usando estratégias chamadas de “arquiteturas multi-tenants”.
Neste contexto, este artigo aborda a aplicação de uma destas estratégias em um software existente de duas maneiras diferentes: usando múltiplas instâncias de objetos da classe SessionFactory do Hibernate; e empregando um recurso nativo da versão 4 do Hibernate que foi construído justamente para atender esse tipo de situação.
Grande parte do progresso do mercado de software desta última década foi delineado pelo desenvolvimento da Cloud Computing (Computação em Nuvem). Este desenvolvimento alavancou a oferta de software por centenas de empresas que não dispunham de altos investimentos para montar e gerenciar datacenters.
Entre elas está, por exemplo, o Instagram, que iniciou suas atividades usando a Cloud da Amazon (AWS) em outubro de 2010. Este aumento da oferta de softwares baseados na nuvem ocorreu, principalmente, devido ao benefício do provisionamento elástico de recursos, também chamado de “Elastic Computing”.
Este provisionamento permite que sejam alocados, de forma dinâmica, os recursos de processamento, memória e armazenamento para uma determinada infraestrutura, conforme a demanda requisitada por ela.
Desse modo é possível aumentar automaticamente os recursos de uma infraestrutura, a qual suportava cem usuários simultâneos, para mil usuários simultâneos, com o objetivo, por exemplo, de atender uma demanda ocasional.
Da mesma forma, é possível reduzir tais recursos conforme a demanda de acessos cai. Todo esse aumento e redução de recursos é gerenciado por programas que decidem tais ações com base no monitoramento da demanda.
Essa flexibilidade resulta em uma significativa redução de custos e elimina consideravelmente os desperdícios de recursos computacionais.
Diante de toda esta evolução, novas formas de negócio proporcionadas pela flexibilidade da Computação Elástica se solidificaram. Entre elas, podemos citar a IaaS (Infrastructure as a Service), PaaS (Platform as a Service), CaaS (Communication as a Service), e finalmente o SaaS (Software as a Service).
De forma simplificada, o SaaS é um modelo de negócios onde o direito de uso do software é cedido através de uma assinatura, geralmente mensal. Este modelo era conhecido antigamente como ASP (Application Service Provider). O SaaS é uma evolução do ASP, já que no ASP os assinantes geralmente detinham uma instância dedicada do software, enquanto no modelo SaaS é oferecida a mesma instância da aplicação para todos os assinantes.
O termo SaaS foi usado pela primeira vez em um artigo publicado pela divisão de e-Business da SIIA (Software & Information Industry Association's), em fevereiro de 2001. Isso foi bem antes do primeiro uso do termo “Computação em Nuvem”, em 2006, numa palestra de Eric Schmidt (CEO do Google na época).
Porém, nos dias de hoje, não há como falar de SaaS sem pensar em Computação em Nuvem, já que este último favorece o ecossistema ideal para a entrega de soluções no modelo SaaS. Por esse motivo, o avanço da Cloud Computing vem possibilitando que muitas empresas de software entreguem os seus produtos neste modelo.
Para se ter uma ideia, de acordo com o relatório Global 100 Software Leaders, divulgado em março pela PwC, houve um aumento de 60% no último ano da receita das empresas que oferecem SaaS, chegando a um total de 20 bilhões de dólares.
Isto mostra o quanto é um bom negócio oferecer produtos como um serviço na nuvem, e que o número de empresas que estão migrando os seus sistemas para soluções SaaS vem aumentando bastante.
Pensando nisso, neste artigo iremos adequar o código de um software existente para que este possa ser entregue no modelo SaaS. É claro que, a decisão de converter um software “de prateleira” em uma solução na plataforma SaaS exige a consideração de uma série de variáveis do ponto de vista de negócio.
Tais considerações são muito bem apresentadas no capítulo 13 do livro “Cloud Computing – Computação em Nuvem”, de Cezar Taurion (Brasport). Entretanto, o escopo deste artigo limita-se somente às variáveis do ponto de vista técnico para adequação de um produto em um modelo para ser entregue como um serviço na nuvem.
A arquitetura Multi-tenant
Devido ao crescimento acelerado do modelo SaaS, surgiram algumas técnicas para criar ou adequar uma solução de software a ser oferecida como um serviço na nuvem. Tais técnicas são conhecidas como arquiteturas “multi-tenant”, ou “multi-inquilino”. Um inquilino, ou tenant, é a entidade que será proprietária de uma parte dos dados do software e terá o direito ao uso de suas funcionalidades.
As arquiteturas multi-tentant têm como principal característica o uso da mesma instância do software para todos os tentants, o que muda de uma para outra é o grau de isolamento dos dados.
Este grau de isolamento pode ser viabilizado em três níveis: alto, no qual há uma instância do banco de dados para cada tenant; médio, no qual uma instância do banco de dados é compartilhada para todos os tenants, havendo um esquema de tabelas para cada tenant; e baixo, que disponibiliza uma única instância do banco de dados e um único esquema de tabelas para todos os tenants.
A primeira estratégia, que oferece uma instância de banco de dados para cada tenant, possibilita um maior grau de isolamento, pois cada inquilino terá os seus dados completamente isolados dos outros. A segurança no nível do banco impedirá que um tenant acesse de forma acidental ou maliciosa os dados de outro.
Além disso, fica mais fácil estender o modelo de dados para um determinado tenant, no caso de surgir a necessidade de customização. Em contrapartida, o custo de gerenciamento tende a aumentar, devido a uma maior utilização dos recursos do servidor e um maior esforço na manutenção de múltiplos bancos de dados.
Em geral, esta estratégia é indicada para inquilinos que detêm informações extremamente críticas e sigilosas, e por isso concordam em ter um custo maior para garantir a segurança do isolamento e a flexibilidade para customizações.
Já a terceira abordagem, que consiste em uma única instância do banco de dados e um único esquema de tabelas compartilhados para todos os tenants, possui o menor grau de isolamento. Como todos os inquilinos compartilharão as mesmas tabelas do esquema, os seus dados devem ser separados logicamente, através de um campo identificador, denominado “discriminator-value” (valor discriminatório), que fará a referência ao proprietário do dado.
Por isso essa estratégia também é conhecida como “discriminator-based multi-tenancy”, que significa “locação múltipla baseada em um discriminador”.
Nesta solução, embora os custos dos recursos, do gerenciamento e da manutenção sejam bem menores que os das outras estratégias, o custo no desenvolvimento do software é maior, principalmente devido ao esforço para garantir a segurança e prevenção de falhas, procurando reduzir os riscos de um tenant acessar os dados de outro.
Por sua vez, a segunda estratégia consiste no “meio-termo”, com um grau de isolamento médio. Tal opção também utiliza uma única instância de banco de dados, mas oferece um esquema de tabelas para cada inquilino.
A desvantagem desta opção em relação à primeira é o esforço necessário para a recuperação dos dados de um inquilino em caso de desastres. Restaurar um único esquema de tabelas é mais trabalhoso do que restaurar um banco de dados inteiro.
Fora isso, todas as vantagens da primeira abordagem com relação à segurança e flexibilidade também se aplicam a esta solução. Entretanto, embora essa estratégia exija um custo maior de manutenção e um consumo mais elevado de recursos se comparada à terceira estratégia, a sua aplicação no código é muito menos trabalhosa.
O Hibernate
Fica fácil notar, frente a essas três
estratégias multi-tenant, que todas elas ...
