Ser ou não ser multitenancy: eis a questão!

Recentemente, almocei com um executivo de uma empresa que produz e comercializa softwares. A nossa conversa girou em torno de SaaS e ele, o executivo, deveria redesenhar seu produto para funcionar no modelo multitenancy. Como quase todos os aplicativos atuais, ele opera no modelo on-premise, ou seja, comercializa uma cópia que é instalada nos servidores dos seus clientes.

A dificuldade de evoluir para multitenancy, com uma única instância lógica e compartilhada por centenas, ou milhares, de empresas clientes (tenants), é o custo. Mas esse modelo traz consigo diversas vantagens, como economia de escala, menor custo operacional e gerenciamento de upgrades. O upgrade é um bom exemplo. No mundo SaaS, muitas vezes, ocorrem três ou quatro upgrades por ano, com mudanças incrementais sendo incorporadas logo que estejam disponíveis. No modelo tradicional, essas mudanças têm que ser agrupadas e disponibilizadas em conjunto em um novo release, que é então distribuído aos clientes. As empresas clientes não podem perder tempo fazendo upgrades periódicos. Têm que cuidar do seu negócio!

Já com SaaS, o upgrade é feito nos servidores da nuvem que opera o aplicativo, e todos os clientes têm acesso a essas novas funcionalidades ao mesmo tempo. O que não acontece no modelo tradicional, no qual os upgrades são efetuados de acordo com as prioridades de cada empresa. É comum vermos, então, dezenas de versões, cada uma com recursos de funcionalidades diferentes. É, sem duvida, um tormento para o suporte técnico do provedor do software.

Por outro lado, existe um caminho alternativo que se baseia em usar provedores de nuvens IaaS e instalar neles seu aplicativo, com uma máquina virtual para cada cliente. O efeito, para o cliente, é SaaS, embora para o provedor os custos sejam mais elevados que multitenancy, pois cada máquina virtual tem uma cópia do aplicativo, que deve ser gerenciada por ela mesma. Mas essa pode ser uma etapa intermediária antes de se chegar a um “full multitenancy”. Esse modelo pode ser chamado de “multitenancy via shared hardware”, pois o servidor é compartilhado por várias máquinas virtuais, cada uma com sua própria instância do software.

Esse modelo não permite a elasticidade total de forma automática, pois para isso seria necessário alterar o código do aplicativo ou do servidor de aplicações que o rodeia para entender as APIs da nuvem onde ele reside. Só assim será explorar a escalabilidade horizontal, que é a possibilidade de aumentar ou diminuir o número de máquinas virtuais alocadas a uma única instância. Nesse modelo, a unidade de provisionamento e alocação é a máquina virtual. Um exemplo é o Amazon Auto Scaling Service.

Claro que a aplicação também tem que ter sido projetada para aproveitar mais máquinas virtuais. Se ela tiver sido desenhada para rodar um único servidor, sem nenhuma capacidade de paralelismo, alocar mais máquinas virtuais não trará beneficio nenhum.

Qualquer que seja a estratégia SaaS, é importante que o cliente se sinta seguro e que os demais clientes que compartilham a infraestrutura não interfiram em sua operação. Por exemplo: se um determinado cliente está no seu momento de maior utilização, gerando muita demanda computacional, esse fato não pode afetar a performance dos demais clientes. Portanto, ir para SaaS demanda que a infraestrutura em nuvem do provedor consiga manter o isolamento entre as várias instâncias compartilhadas.

O modelo “full multitenancy” deverá, aos poucos, se disseminar e provavelmente começaremos a ver as novas aplicações sendo escritas para rodar em ambiente de nuvem (SaaS), explorando esse modelo. Hoje um exemplo clássico de full multitenancy é o salesforce.

Um documento que recomendo como apoio ao entendimento do conceito multitenncy e seu uso prático é o “The force.com multitenant architecture”. Outro paper muito legal é “Best practices for cloud computing multitenancy”. Você também encontra material muito interessante na comunidade developerWorks, que vai ajudar a entender melhor o conceito. Vale a pena o esforço!