No futuro, O modelo SaaS vai requerer tecnologias e arquiteturas especificamente desenhadas para operar em nuvem. Entretanto, essas novas arquiteturas e tecnologias vão aparecer a 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.

Atualmente, a maioria dos softwares existentes foi desenhada para operar nos data centers das empresas, sujeitos a 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 a muitas organizações. Para os provedores desses serviços, é imprescindível 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 às suas características específicas.

Porém as arquiteturas de software atuais não atendem a esse 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 aos múltiplos 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 múltiplos inquilinos (empresas/clientes) compartilhem os mesmos recursos físicos como um aplicativo ERP, mas permaneçam logicamente isolados.

Os modelos multi-inquilino são:

1. 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 múltiplos clientes a partir do mesmo data center, este modelo não é multi-inquilino. É similar ao modelo tradicional de hosting (hospedagem), no qual 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 de elasticidade, porque adicionar um novo inquilino requer o provisionamento de sua própria instância de hardware e de software. Também 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 nessa direção, oferecendo como atrativo a facilidade de uma rápida oferta para SaaS.
2. Multi-inquilino via hardware compartilhado (virtualização): Neste modelo, cada inquilino tem seu próprio stack de tecnologia, mas o hardware é alocado dinamicamente 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 forma 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.
3. 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 é a mesma. A premissa do modelo é que o isolamento do banco de dados garante integridade dos dados dos inquilinos, ao mesmo tempo em que o container de execução, por ser compartilhado, oferece as vantagens de elasticidade e de 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.
4. 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 (02), 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 (03) e (04) implementam um nível bem mais avançado de SaaS e provavelmente serão os modelos dominantes no longo prazo. Mas, atualmente, é 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 níveis elevados de flexibilidade e de 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 (03) e (04) vão prevalecer.

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 (02), mas incentivando uma evolução posterior para os modelos (03) e (04), à medida que o mercado e as tecnologias disponíveis forem amadurecendo o suficiente para suportarem clientes corporativos de grande porte.