Venho observando que o conceito de cloud
computing vem amadurecendo a cada dia. Passamos pela
empolgação inicial e já começamos a entender que existem muitas coisas
boas, mas que também existem algumas restrições. Quando
falamos em nuvens públicas, alguns dos principais receios e
questionamentos referem-se à questão da segurança e da disponibilidade
dos serviços. A segurança, por exemplo, pode muitas vezes
ser endereçada com o uso de nuvens privadas, desde, é claro, que a
empresa tenha uma política de segurança aprimorada. Mas,
existe um aspecto preocupante nas nuvens públicas que ainda não tem sido
considerada com a devida atenção, que é o alto risco de aprisionamento
forçado ou “cloud lock-in“.

O lock-in em nuvens públicas aparece
porque cada provedor implementa seu próprio conjunto de APIs e muitas
vezes seu próprio banco de dados e ambiente de programação.
O resultado é que o usuário acaba ficando aprisionado na nuvem deste
provedor, uma vez que o trabalho de mover suas aplicações para outras
nuvens não será muito simples e nem será barato. Por que isso acontece?
Uma característica diferenciadora do ambiente de cloud computing com
relação ao ambiente tradicional é que a infraestrutura em cloud, por si,
é programável. Por exemplo, para usarmos os serviços S3 ou
SimpleDB, da Amazon, usa-se um conjunto
de APIs próprias. O mesmo acontece quando usamos o GAE
(Google Application Engine) e seus recursos proprietários de banco de
dados (BigTable). O problema é que essas APIs implementam
acesso a recursos específicos e proprietários e não são padronizados.
Migrar de uma nuvem como a da Amazon para a do Google ou do Azure da
Microsoft para o Google demandará um belo trabalho de conversão.

Observamos um fato interessante: quanto
maior o nível de abstração da nuvem, maior seu potencial de lock-in.
Ou seja, uma nuvem SaaS oferece maior risco de lock-in que um PaaS e,
este, maior potencial que uma nuvem IaaS. Exemplo prático: o
Force.com cria um lock-in bastante intenso, pois as aplicações devem ser
desenvolvidas na linguagem proprietária do Salesforce que é o Apex, que
não está disponível em outros ambientes de nuvem. Já no
GAE, você pode pegar seu código Java ou Python e usar o programa em
outra nuvem, mas caso use (e acaba-se usando) os recursos proprietários
como o banco de dados BigTable, tem-se o lock-in.

O que fazer? Bem,
já existe uma alternativa a este aprisionamento, que foi a
criação das chamadas Open APIs, como as criadas pela
RedHat (Deltacloud, que pode ser acessada em http://deltacloud.org/),
Apache (Libcloud acessado em http://incubator.apache.org/projects/libcloud.html)
e Zend SimpleCloud API (http://www.simplecloud.org/).
Outra proposta é a da OGF (Open Grid Forum) Open Cloud Computing
Interface, que pode ser vista em http://www.occi-wg.org/doku.php?id=start).
Essas APIs criam uma camada de abstração permitindo que o desenvolvedor
não tenha que se preocupar com APIs de nuvens específicas. A
proposta é que uma OpenAPI se encarregue de fazer automaticamente a
tradução para as APIs específicas. As suas limitações são
ainda o fato que continua persistindo o problema da interoperabilidade
entre as nuvens públicas (uma aplicação rodando na nuvem EC2 da Amazon
não fala com a nuvem Azure da Microsoft) e obriga a que o desenvolvedor
aprenda esse novo conjunto de APIs. Mas, é um bom primeiro passo.

E o futuro? Creio que o modelo de aprisionamento atual
é decorrente de um conceito e de tecnologias que estão na sua infância e,
portanto, ainda na fase dos provedores desses serviços buscarem
consolidar seu espaço no mercado. Historicamente, novas tecnologias e
mercados na Internet evoluem da seguinte maneira:

a) Um novo mercado ou tecnologia surge
baseado no modelo fechado e proprietário.

b) Por pressão de um mercado em
crescimento, começam os primeiros sinais de abertura.

c) Quando o mercado ou tecnologia já está
maduro, torna-se aberto (open) ou “open enough”.

Na verdade, o conceito de aberto tem perspectivas
diferentes quando falamos em serviços, como as nuvens públicas e quando
falamos em software. A essência de uma nuvem pública é que o
usuário está alugando os recursos computacionais de outra empresa, o
provedor de serviços em nuvem. Claro que, em um contexto
desses, o usuário não poderá ter 100% de controle, e os serviços de nuvem
continuarão fechados (infraestruturas, métodos e práticas
proprietários).

Mas, nuvens não interoperáveis serão uma limitação
muito grande à própria expansão do  mercado
de public clouds. A pressão do próprio mercado e a
tendência para sistemas abertos vai obrigar a que no futuro essas nuvens
públicas sejam realmente abertas. Será absolutamente
essencial permitir interoperabilidade entre todas elas. Uma aplicação
rodando no Azure deverá demandar acesso a outra que esteja rodando no
GAE ou no EC2, sem limitações. Portanto,
na minha opinião será questão de tempo vermos APIs abertas
e a interoperabilidade entre nuvens.

Para fechar, vale a pena lembrar a
iniciativa chamada Open Cloud Manifesto, que mostra a preocupação do
mercado com esse risco de lock-in. O Open Cloud Manifesto
pode ser lido em www.opencloudmanifesto.org) e se propõe a aglutinar
empresas que oferecem tecnologias e serviços de cloud em torno da
especificação de um padrão aberto.

O manifesto estabelece um conjunto de
diretrizes, denominados princípios para nuvens abertas, que asseguram que as organizações que
usarem nuvens computacionais não ficarão restritas a padrões fechados,
mas terão liberdade de escolha, flexibilidade e abertura para não
ficarem aprisionadas a nenhuma nuvem. Dezenas
de empresas já fazem parte desse manifesto, como IBM, CA e EMC, mas
algumas outras como Microsoft, Google e Amazon ainda não acordaram
nenhum compromisso com esta proposta. Pena, pois padrões
abertos são garantia de interoperabilidade entre nuvens.

*

Artigo publicado no My developerWorks. Cadastre-se e participe!