Lock-in em Cloud Computing

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 a 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 aprisonado 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. Porque isto acontece? Uma caracteristica 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 estas APIs implementam acesso a recursos especificos 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 nivel 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á disponivel em outros ambientes de nuvem. Já no GAE, voce 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). Estas APIs criam uma camada de abstração permitindo que o desenvolvedor não tenha que se procupar com APIs de nuvens específicas. A proposta é que uma OpenAPI se encarregue de fazer automáticamente a tradução para as APIs especificas. 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 este novo conjunto de APIs. Mas, é um bom primeiro passo.

 E o futuro? Creio que o modelo de aprisionamento atual é decorrente de um conceito e tecnologias que estão na sua infância e portanto ainda na fase dos provedores destes serviços buscarem consolidar seu espaço no mercado. Históricamente 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 destes 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 estas 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 este 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 deste manifesto, como a 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.

2 Respostas to “Lock-in em Cloud Computing”

  1. andre uebe Says:

    Taurion

    A Nexedi, empresa francesa, projetou o TioLive: https://www.tiolive.com/ um ERP 5, em nuvem.

    Achei interessante a questão da mesma ser Open Source (será que adota estes conceitos de Open API?)

    Outro detalhe interessante é um projeto delhes chamado de Tio Live Grid que permitirá uma infraestrutura de P2P para processamento em nuvem, nos moldes do que existe no armazenamento com Torrent.

    Abs

    Andre Uebe

    PS: Senti tua falta no Cloud Computing 2010 que ocorreu na UFRJ dia 27.

  2. Giovanni Cândido Says:

    Muito interessante esse post.
    Estou pesquisando sobre cloud computing e a interoperabilidade entre nuvens é uma questão crítica. Imagine desenvolver ferramentas de automação para ambientes em nuvem, e ter que preocupar com todas as apis disponíveis dos principais desenvolvedores.

    Se as apis de desenvolvimento em cloud seguirem a filosofia do Java que é “escreva uma vez, rode em qualquer lugar” temos um ganho enorme.

    Seu post me ajudou também pois estava querendo desenvolver uma aplicação para automação da criação de infraestruturas em nuvem, a partir por exemplo de um diagrama de implantação, para meu trabalho de conclusão de curso, vou pesquisar as iniciativas Delta Cloud, Lib Cloud e SimpleCloud Api.

    Obrigado

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s


%d blogueiros gostam disto: