A Caelum.com.br roda agora no cloud. Por que? Vale a pena? Temos tantos acessos assim?

Entre os exemplos clássicos do bom uso do cloud temos o sucesso do New York Times: eles conseguiram digitalizar em PDF mais de 4 terabytes de edições do jornal muito antigas (1851-1922) usando 100 máquinas e gastando apenas 240 dólares! O cloud é perfeito para situações em que você precisa de muito desempenho e recursos por um curto período de tempo.

Essa definitivamente não é a necessidade da Caelum em rodar em um cloud. Qual seria então?

Temos várias opções para você ter seu próprio cloud: através do TerraCotta, pelo VMWare ou pelo Grid Gain. Usando esses softwares você mesmo precisa prover sua infraestrutura de máquinas, o que pode ser trabalhoso. Um nível mais abstrato e encapsulado seria usar o EC2 da Amazon: ele já fornece as máquinas, facilitando muito a manutenção, e cobra por tempo de processamento (eliminando o gasto inerente ao tempo ocioso que suas máquinas poderiam ficar). No Brasil, a Locaweb foi a pioneira ao oferecer esse serviço.

Por último, temos hosts que já provêm tudo para você: a infraestrutura e o software para permitir a escalabilidade. O Google App Engine é um desses hosts.

Aqui, sim, entra a Caelum e entra também o interesse das empresas de hosting: se o cloud é mais barato para os fornecedores por compartilhar recursos ociosos, e ainda oferece altíssima escalabilidade e disponibilidade para os clientes, temos então um casamento de interesses. Essa relação ganha-ganha fortalece muito a tendência da adoção de uma arquitetura mais elástica. Os clientes também ganham uma enorme independência de hardware, terceirizando os grandes problemas que acabam acontecendo quando temos servidores dedicados: esses servidores não são à prova de bala. Para a Caelum, mesmo sem necessidade de rodar em 100 servidores, é interessante ter o poder de fazer o deploy de nossas aplicações Web sem ter de nos preocupar se “é suficiente X micros e Y de RAM para esta aplicação?”, por menor que ela seja.

O site da Caelum usava VRaptor 3 como controlador, JSP e taglibs na visualização e Hibernate para persistência. Para colocá-lo no cloud do Google App Engine, a única grande mudança que fizemos foi migrar a camada de persistência para o BigTable. Trata-se de um banco de dados não relacional proprietário, que possui uma API específica, mas também há uma implementação (não completa) de JPA para ele, o que facilita bastante a migração.

Desvantagens? O Google App Engine ainda está em beta, e já ficou fora do ar alguns momentos, em especial o serviço do DataStore (o BigTable). Há também o problema do cold start e do plugin para o Eclipse, que é um pouco lento para iniciar o servidor de testes: falaremos com detalhes sobre ambos em um outro post. Outra desvantagem é a dependência ao BigTable: como é um serviço proprietário, migrar para qualquer outro cloud vai necessitar de ajustes, mesmo que usando a JPA.

Respondendo o título do post: independente se o seu cloud é Amazon EC2, Google App Engine ou GridGain, algo é certo: ele traz vantagens tanto para os desenvolvedores quanto para o host, mostrando que a estratégia do cloud está cada vez mais solidificada.

Agradecimentos ao Pedro Matiello, Guilherme Silveira e Sérgio Lopes pela migração do site. Em breve, postaremos detalhes de como trabalhar na Google App Engine. Teremos uma palestra sobre Cloud computing no CaelumDay no Rio de Janeiro, esse 7 de novembro!