Recentemente almocei com um executivo de uma empresa que produz e comercializa softwares aplicativos. O assunto foi SaaS e se ele 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 compartilhada por centenas ou milhares de empresas clientes (tenants) é obviamente o custo, embora, seja claro, que este modelo traz consigo diversas vantagens como economia de escala, menor custo operacional e gerenciamento de upgrades. Upgrade é um bom exemplo. No mundo SaaS muitas vezes ocorrem 3 ou 4 upgrades por ano, com mudanças incrementais sendo incorporadas logo que estejam disponíveis. No modelo tradicional, estas mudanças tem 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. Tem que cuidar do seu negócio!
Já com SaaS, o upgrade é feito nos servidores da nuvem que opera o aplicativo e todos os clientes tem acesso a estas novas funcionalidades, ao mesmo tempo. O que não acontece no modelo tradicional, onde 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 aplicativo.
Por outro lado, existe um caminho alternativo que é usar provedores de nuvens IaaS e instalar neles seu aplicativo, com uma máquina virtual para cada cliente. Para o cliente, o efeito é 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 si. Mas pode ser uma etapa intermediária antes de se chegar a um “full multitenancy”. Este modelo pode ser chamado de multitenancy via shared hardware, pois o servidor é compartilhado por várias maquinas virtuais, cada uma com sua propria instância do aplicativo. Não permite de forma automática a elasticidade total, 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, para que seja possível explorar a escalabilidade horizontal. Escalabilidade horizontal é aumentar ou diminuir o número de máquinas virtuais alocadas a uma única instância. Neste 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á benefício 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, este 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 este modelo. Demanda, obviamente, skills que não são muito comuns hoje em dia… 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 “
Cezar Taurion é head de Digital Transformation da Kick Ventures e autor de nove livros sobre Transformação Digital, Inovação, Open Source, Cloud Computing e Big Data.
You must be logged in to post a comment.
