“Cloud” é uma buzzword que vem causando frisson já há algum tempo. Complica muito o fato de o termo ser muito amplo: “Você trabalha com Cloud” está virando equivalente a “Conserta aqui minha impressora, você não trabalha com informática? ”. Neste artigo, pretendo descrever os desafios para escrever uma aplicação que seja “cloudable” (desculpem, certas coisas não traduzem bem). Mas, primeiro, vamos entender o quero dizer por cloudable.

Uma das frases que mais ouço nas minhas visitas a clientes é: “Eu já uso Cloud! Tenho aqui o virtualizador XPTO que resolveu essa questão”. Como anteriormente citei sobre a amplitude do termo “Cloud”, não é que a frase anterior esteja incorreta: ela simplesmente é limitante.

O que eu acho mais interessante sobre essa figura é que ela deixa claro que não existe um modelo de adoção correto. O que existe é o modelo que mais se aplica ao problema de negócio que estamos tentando resolver!

Por exemplo, vamos usar IaaS (ou Infraestrutura como Serviço) como um ponto de partida: a grande sacada de IaaS é que você pode migrar praticamente qualquer aplicação existente sem impacto nela, uma vez que é possível reproduzir fielmente um ambiente “tradicional” (clusters de servidores de aplicação, de banco de dados etc.) nesse mundo. É um modelo de adoção que permite, com baixo investimento, adicionar flexibilidade e escalabilidade à uma aplicação existente.

Mudando o foco para PaaS (Plataforma como Serviço), vemos que nesse modelo o cliente não tem controle sobre a infraestrutura; ele tem gerência apenas do código de sua aplicação e seus dados. Portanto, não é possível se apoiar em funcionalidades de infraestrutura (como cluster de servidor de aplicação) para que a aplicação tenha sua operação básica garantida e, além disso, o princípio básico de escalabilidade desse modelo é o horizontal.

O problema é que a grande maioria das aplicações não foi escrita pensando em escalabilidade horizontal. Historicamente, endereçamos problemas de performance de sistemas na força bruta, adicionando processadores e memória para aumentar a capacidade de processamento.

Há algum tempo, o termo “Micro Serviços” vem sendo utilizado. Conforme disse Martin Fowler em seu artigo a respeito do tema, embora não haja uma definição formal sobre ele, há um senso comum sobre características e práticas que cercam esse estilo arquitetural, como: especialização em capacidades de negócio, deployment automatizado e independência de linguagens de programação/tecnologia, entre outros.

Ora, no mundo de micro-serviços, não existe o conceito de escalabilidade vertical: um serviço deve ser capaz de ser replicado (escalado) horizontalmente quantas vezes for necessário, até que a carga recebida seja atendida com o nível de serviço esperado (em geral, medido em termos de tempo de resposta), e é nesse jogo que PaaS cai como uma luva!

Idealmente, uma aplicação cloudable deve ser construída como um conjunto de micro-serviços, com escalabilidade, ciclo de vida e métricas de performance independentes, e um grande guia para criar esse tipo de aplicação é seguir os preceitos 12Factor.

Utilizando como exemplo uma aplicação instalada no Bluemix: ao se associar um serviço a ela, automaticamente é injetado no environment dessa aplicação uma variável chamada VCAP_SERVICES, que nada mais é do que um objeto JSON que contém todos os dados de acesso ao serviço (URL, usuário, senha etc.).

Já existem alguns projetos, como o spring-cloud, que permitem que o parse dessa variável seja feito de forma transparente e o serviço disponibilizado para a aplicação através de injeção de dependências, sendo apenas necessário o uso de anotações para acessar o serviço.

O código-fonte de uma aplicação que exemplifica esses princípios pode ser baixado da minha conta no Bluemix DevOps Services; lá você encontrará um “Readme” que explica como testá-la no Bluemix, para validar os princípios aqui demonstrados. Bom divertimento e até a próxima!