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

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 disponiveis. No modelo tradicional, estas mudanças tem que ser agrupadas e disponibilizadas em conjunto em um novo release, que é então distribuído ao 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 varias 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 possivel explorar a escalabilidade horizontal. Escalabilidade horizontal é aumentar ou diminuir o numero de maquinas 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 maquinas virtuais. Se ela tiver sido desenhada para rodar um um único servidor, sem nenhuma capacidade de paralelismo, alocar mais maquinas 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, 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 varias 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 “The force.com multitenant architecture”, acessivel em http://tinyurl.com/cat7hb . Outro paper muito legal é “Best practices for cloud computing multitenancy” disponivel em http://www.ibm.com/developerworks/cloud/library/cl-multitenantcloud/index.html . Aliás, acessando a comunidade developerWorks (https://www.ibm.com/developerworks/ ) e pesquisando pela keyword multitenancy você obterão excelentes papers que os ajudarão a entender melhor o conceito. Vale a pena o esforço.

Nuvens públicas: selecionando o melhor provedor

Quando ouvimos o termo “Cloud Computing” fazemos de imediato uma associação com o conceito de nuvem publica, baseada em IaaS. Esta percepção começou quando a Amazon anunciou o seu serviço AWS. Claro que ainda é um mercado que não está maduro e nem poderia, pois é muito jovem ainda (o AWS surgiu em 2002, ou seja, apenas dez anos), mas este processo de amadurecimento está se acelerando rapido. Se consolida mais quando empresas como a IBM também lançam sua nuvem publica, esta chamada de SCE (Smarter Cloud Enterprise). Para conhecer melhor o SCE acessem http://www-935.ibm.com/services/br/pt/cloud-enterprise/index.html .

Vamos lembrar que uma nuvem é basicamente a combinação de virtualização + padronização + automação, o que permite oferecer portais de acesso self-service aos usuários. No modelo IaaS o provedor fornece basicamente servidores virtuais e seus sistemas operacionais. A partir daí a responsabilidade de conteúdo, como middleware e aplicativos continua com a empresa que contrata a nuvem. Não é responsabilidade do provedor. Portanto, IaaS é um serviço bem diferente do PaaS e SaaS. Não podem e nem devem ser considerados como serviços similares. Ou seja, uma nuvem não é igual a outra nuvem…

Usar nuvem publica começa aos poucos ficar lugar comum, mas ainda encontramos alguns receios e mesmo desinformações circulando pelo mercado. Muita gente pensa que uma nuvem publica é para ser usada apenas para coisas meio periféricas, como web sites e aplicações que não sejam críticas às empresas. Mas, já vemos muitos negócios baseados inteiramente em nuvens publicas, como o Peixe Urbano aqui no Brasil e Netflix e FourSquare nos EUA, para citar apenas alguns exemplos. E são negócios que dependem de TI para funcionarem. Demonstram na prática que uma nuvem publica é confiável. Empresas de pequeno a médio porte tendem naturalmente a colocar seus data centers em nuvens publicas, não só por razões de custo, mas pela própria necessidade do negócio. Porque gastar recursos que são escassos como tempo e dinheiro mantendo servidores dentro de casa se existe uma outra opção mais adequada? Na verdade, uma nuvem pública pode oferecer um nivel de segurança e disponibilidade bem maior que a oferecida hoje em muitos dos data centers das pequenas e médias empresas.

O que começa a mudar? Adotar uma nuvem publica IaaS deixa de ser uma discussão técnica para ser uma decisão estratégica, de negócios. Mas, ao subirmos o patamar das decisões, a escolha do provedor de nuvem torna-se algo mais complexo. Além disso, a governança de TI da empresa continua com a empresa. Não é terceirizada totalmente!

O modelo IaaS tende aos poucos a se tornar comoditizado, pois as ofertas, com o amadurecimento do mercado, tenderão a se tornar bastante similares em termos de segurança, disponibilidade, desempenho e suporte. Uma analogia simplista é o com o mercado de PCs, quando praticamente não vemos diferenças marcantes entre os varios PCs disponives no mercado.
Mas, hoje, com um mercado ainda em fase de amadurecimento, as ofertas dos diversos provedores são diferentes e portanto a escolha do provedor de nuvem não pode ser feita de forma superficial.

O que verificar quando analisando provedores? Primeiro, se você for colocar seu negócio em uma nuvem é importante que o provedor tenha um ou mais data centers que sejam adequados aos seus requisitos de segurança, disponibilidade, desempenho e suporte. A primeira vista todos oferecem, mas quando olhando com mais profundidade vemos que a localização do data center de um provedor pode não ser a mais adequada em termos de garantir segurança e acesso em momentos críticos. Também a questão do suporte. Um bom suporte exige uma equipe técnica treinada e eficiente. Custa dinheiro para manter. Além disso, a nuvem tem que dispor de ferramentas tecnológicas que garantam a excelência na automação da operação. E, claro, para sustentar o crescimento de sua base de clientes, sem afetar os já existentes, precisa ter condições de escalabilidade. Novamente entram em cena os requisitos de expertise e capital.

Bem, vamos listar alguns requisitos que devem ser considerados quando analisando potenciais provedores de nuvens publicas:
a) Disponibilidade e SLA (Service Level Agreement). Qual o nivel de disponibilidade oferecido? Quando analisamos em mais detalhes o portfólio de aplicações de uma empresa observamos que a maioria delas não é estratégica ou crítica, com um perfil de dados que não é sensível em termos de segurança. Também observamos que a maioria destas aplicações pode operar em um ambiente de disponibilidade menor que 95%. Ora, estas aplicações podem ser deslocadas para nuvens públicas sem maiores sustos. Mas, se as aplicações precisarem de 99,9% de disponibilidade? O provedor oferece este nivel de disponibilidade?
b) Politica de preços. O custo de hora de computação tende a ser bem barato mas olhe com atenção os custos de armazenamento e comunicações. Veja também o nivel de flexibilidade da politica de preços. Por hora? Por dia? Contratos mensais? Veja quanto custa capacidade adicional a que você inicialmente requisitou.
c) Em uma nuvem publica IaaS, você continua responsavel pela governança da sua TI, mas veja o que o provedor pode oferecer em termos de serviços adicionais como backup, ferramentas de monitoramento do desempenho, planejamento de capacidade, etc. Estas ferramentas estão disponiveis para você analisar o desempenho dos seus servidores virtuais?
d) Quais são os recursos de segurança implementados pelo provedor? Por exemplo, eles tem defesa contra ataques tipo DoS (Denial of Service)? O provedor está compliance com certificações como PCI, SAS 70, SSAE 16, ISO 27001 e FISMA, apenas para citar as mais comuns? Tem um estudo muito interessante que aborda segurança em provedores de nuvem, que pode ser acessado em http://www.ca.com/~/media/Files/IndustryResearch/security-of-cloud-computing-providers-final-april-2011.pdf .
e) O data center está localizado no território brasilerio? Se não, a que leis ele estará sujeito? Em caso de auditoria e eventual investigação forense, como você terá acesso a seus dados?
f) Qual o background do fornecedor em lidar com clientes corporativos? O mercado voltado para usuário final e o corporativo são bem diferentes em demandas de suporte e preparo da equipe técnica. Um provedor que não tenha fortes raizes no atendimento ao mercado corporativo poderá encontrar muita dificuldade em atender às demandas específicas dos seus clientes.
g) Suporte. Como é o suporte? 24 x7? Via email, telefone ou chat? Qual a politica de preços para niveis de suporte diferenciados?
h) Billing. A fatura é fácil de entender e abrangente o suficiente para não gerar duvidas?
i) Contrato. Quais são as garantias contratuais? Como é a rescisão? Existem facilidades para você migrar para outro provedor? Quais e quanto custam? Existe garantia de que os dados sejam apagados após encerrar o contrato? Além disso observe que na maioria das empresas a auditoria exige um contrato, diferente de uma nuvem de uso pessoal onde com um simples cartão de crédito você abre uma conta e obtém servidores virtuais.
j) O provedor é financeiramente estável? Tem condições de investir e acompanhar a evolução do mercado e das tecnologias de cloud? Tem condições de ampliar sua capacidade?
k) Qual é a estratégia de cloud do provedor? Quão importante é para o negócio dele?
l) Existe um ecossistema em torno do provedor, que ofereça aplicatvos, educação e consultoria, que podem ajudá-lo a usar melhor a computação em nuvem?

Como vemos existem vários requisitos que devem ser analisados. Fale com os representantes de vendas do provedor, visite o data center, ligue para outros clientes e veja o grau de satisfação deles. E não esqueça que a governança de TI continua com você. Assim, analise as licenças de software que você tem e valide-as com relação ao seu uso na nuvem. Mantenha uma equipe que interaja com o provedor para resolver problemas e manter um SLA adequado às suas necessidades. E concentre-se no seu negócio, deixando tarefa de gerenciar servidores e seus sistemas operacionais (puro overhead, que não agrega um centavo ao seu faturamento) por conta do provedor. Bem vindo às nuvens!