O modelo SaaS vai, no futuro, requerer tecnologias e arquiteturas especificamente desenhadas para operar em nuvem. Entretanto, estas novas arquiteturas e tecnologias vão aparecer no longo prazo, com modelos intermediários e transitórios surgindo no curto e médio prazo, fazendo a ponte entre os modelos computacionais existentes hoje e os futuros modelos em nuvem.
A maioria dos softwares existentes hoje foi desenhada para operar nos data centers das empresas, sujeitos à contratos específicos de licença de uso. As próprias plataformas de aplicação como Java e .Net foram desenhadas para operarem no modelo on-premise.
Em um modelo SaaS em nuvem, as aplicações podem ser oferecidas como serviços à muitas organizações. Para os provedores destes serviços, é imprescindivel que os recursos computacionais a serem oferecidos sejam o mais amplamente compartilhados. Para os usuários, é fundamental que uma falha de um software na operação para um outro usuário não o afete. Além disso, cada usuário gostaria de adaptar, na medida do possível, a aplicação à suas características específicas.
Mas, as arquiteturas de software atuais não atendem a este novo cenário. É necessário um novo modelo arquitetônico de software, chamado de multitenancy ou multi-inquilino.
A proposta do modelo SaaS é ter uma aplicação atendendo a multiplos clientes, chamados de tenants ou inquilinos. Inquilinos não são usuários individuais, mas empresas clientes do software. Uma arquitetura multi-inquilinos (em alguns casos a literatura fala em multi-arrendatário, mas eu prefiro usar o termo multi-inquilino) é uma arquitetura essencial para um ambiente em nuvem pois permite que multiplos inquilinos (empresas clientes) compartilhem os mesmos recursos fisicos como um aplicativo ERP, mas permanecendo logicamente isolados.
Os modelos multi-inquilino são:
a) Inquilino isolado. Neste modelo, cada inquilino tem seu próprio stack de tecnologia, não havendo compartilhamento de recursos. Na prática, embora o usuário sinta a experiência de multi-inquilino, pois a aplicação é oferecida a multiplos clientes, a partir do mesmo data center, este modelo não é multi-inquilino. É similar ao modelo tradicional de hosting (hospedagem), onde cada usuário tem seu próprio conjunto de recursos computacionais e sua própria instância da aplicação. Para a uma oferta SaaS, este modelo carece de agilidade e elasticidade, porque adicionar um novo inquilino requer o provisionamento de sua própria instância de hardware e software. Tambem não permite economia de escala. Os provedores que comercializam softwares no modelo tradicional podem oferecer esta opção, sem alterar sua aplicação. Embora não seja verdadeiramente Computação em Nuvem é um passo nesta direção, oferecendo como atrativo a facilidade de uma rapida oferta para SaaS.
b) Multi-inquilino via hardware compartilhado (virtualização). Neste modelo, cada inquilino tem seu próprio stack de tecnologia, mas o hardware é alocado dinâmicamente a partir de um pool de recursos, via mecanismos de virtualização. Bastante similar ao modelo anterior, mas permitindo elasticidade na camada do hardware. Elasticidade é fundamental ao modelo de Computação em Nuvem, que demanda mecanismos de alocação e liberação de recursos de foma dinâmica. Este modelo permite uma entrada rápida na Computação em Nuvem, principalmente por provedores de aplicações e de infraestrutura, porque não demanda redesenho da aplicação. Entretanto, apresenta limitações, pois a unidade de alocação e liberação de recursos é a maquina virtual onde aplicação vai operar.
c) Multi-inquilino via container. Neste modelo vários inquilinos são executados na mesma instância de um container de aplicação (um servidor de aplicações), mas cada inquilino está associado a uma instância separada do software de banco de dados. O ambiente de execução é compartilhado entre vários inquilinos, mas a plataforma de dados é mesma. A premissa do modelo é que o isolamento do banco de dados garante integridade dos dados dos inquilinos, ao mesmo tempo que o container de execução, por ser compartilhado, oferece as vantagens de elasticidade e customização. Para garantir o isolamento dos inquilinos dentro de uma única instância do container ou servidor de aplicações, este deve ser desenhado com funcionalidade para gerenciar a alocação de recursos aos seus inquilinos.
d) Multi-inquilino via todo o stack de software compartilhado. É uma evolução do modelo anterior, agora com todo o stack de software sendo compartilhado. Neste modelo além do container da aplicação, também uma única instância do banco de dados é compartilhada por todos os inquilinos.
O modelo (b), multi-inquilino por compartilhamento de hardware, permite uma transição para SaaS, com baixo custo e baixo impacto. A razão é simples: preservam os modelos de programação e tecnologia já conhecidos.
Os modelos (c) e (d) implementam um nivel bem mais avançado de SaaS e provavelmente serão os modelos dominantes no longo prazo. Mas hoje, é implementado apenas por empresas de software que não possuem legado para sustentar e portanto podem romper com os modelos tradicionais, como por exemplo, a Salesforce. Como são nativos ao modelo em nuvem, oferecem niveis elevados de flexibilidade e elasticidade, mas ao custo de disrupção nos modelos atuais de programação.
Nos próximos anos veremos um intenso debate sobre os prós e contras dos vários modelos de multi-inquilinos, mas no longo prazo os modelos (c) e (d) prevalecerão. Empresas de software que precisam suportar sua imensa base de clientes com sistemas legados, estão optando por uma evolução gradual, adotando inicialmente o modelo (b), mas incentivando uma evolução posterior para os modelos (c) e (d), à medida que o mercado e as tecnologias disponíveis forem amadurecendo o suficiente para suportarem clientes corporativos de grande porte.
Nas Nuvens 