No início de 2009 eu trabalhava em uma startup com Java, utilizando frameworks muito conhecidos da plataforma, como Spring e Hibernate. Decidi então, no fim do ano, construir um site de transmissão de fotos, visando entender todo o processo de desenvolvimento.

No início, comecei a fazer o setup análogo ao que já conhecia: instalei Maven e Nexus, comprei um host Java. Demorei cerca de um mês, utilizando meu tempo livre, para configurar todas ferramentas. Mas a aplicação iria transmitir muitas fotos pelas rede, meu cliente pretendia fazer promoções em sites de compras coletivas. Eu estava certo de que meu servidor não iria aguentar essa carga.

Foi justo nessa época que um amigo me apontou a solução. Ele comentou que o Google tinha criado um serviço, App Engine (GAE), que resolveria meu problema. Ele fornecia um ambiente de desenvolvimento e deploy simples, prometendo escalar sua aplicação automaticamente.

Para me convencer sobre o poder do GAE ele fez uma demonstração: em cinco minutos no almoço criou uma aplicação Hello World do zero e fez o deploy. Realmente fui convencido e, a partir daquele momento, passei a utilizar a plataforma. Nascia assim a primeira versão do site, após três meses de desenvolvimento, que se chamava Revelação Virtual.

O que permitiu o rápido desenvolvimento foram as facilidades que a plataforma possuía. Diferente do ambiente Java comum, toda documentação se encontra centralizada e existe API para resolver vários problemas comuns do desenvolvimento web, como envio de e-mail, upload e download de arquivos, filas de tarefas, entre muitas outras funcionalidades.

Mas como qualquer escolha em tecnologia, sempre existem dificuldades. A maior delas é que o ambiente do GAE é muito particular, impondo restrições para que a plataforma possa realmente escalar de forma automática.

Como maior exemplo de restrição, cito o Big Table, banco de dados NoSQL distribuido. Nele não é possível fazer join e as pesquisas são limitadas. Ou seja, não existem diversas operações comuns aos bancos tradicionais. Sendo assim, para programar nessa plataforma são necessárias várias mudanças de paradigma para quem já programa em um ambiente mais ortodoxo.

E foi por conta dessa forma de funcionamento particular do GAE que me vi obrigado a alterar todo o backend de Java para Python. Por conta do problema de cold start  os clientes sofriam com uma grande latência da aplicação quando uma nova instância era necessária. Acabei testando o Python e resolvendo o problema construindo o microframework Zenwarch para carregar a aplicação web de forma preguiçosa. Mais do que apenas resolver o problema, acabei percebendo que o desenvolvimento em Python era muito mais produtivo e acabei me aprofundando em seu estudo.

Por conta dessa mudança, passei a frequentar a comunidade Python e suas conferências. Para minha surpresa, muitos pythonistas não conhecem a plataforma, sendo poucos os que a usam para sistemas em produção. A maioria usa o framework DJango e servidores linux, sendo necessário instalar toda a base para o website, como NGinx, Gunicorn, SupervisorD e outras ferramentas. Acabei aprendendo um pouco sobre essa estrutura trabalhando na empresa ZNC, justamente para poder compará-la com a estrutura do GAE.

Durante esse período na ZNC, pude constatar o grande poder que o Django fornece ao desenvolvedor, principalmente através dos painel de administração. Contudo, considerei a curva de aprendizado do framework em si relativamente alta. Além disso, as ferramentas necessárias para se poder fazer um deploy com um clique tornam todo o processo muito complexo. Definitivamente a simplicidade da plataforma do Google me deixou “mal acostumado”. Ou melhor, me deixou “bem acostumado”.

Mas além da simplicidade, outro fator fundamental me faz preferir o GAE: o preço. A plataforma oferece uma cota grátis de uso que se renova diariamente. Isso permite que se teste o site sem haver necessidade de investimento, até que ele ganhe tração. Mais do que isso, você paga pelo que realmente utiliza. Ou seja, se o tráfego diminui, também cai o seu custo.

Mas durante minhas discussões com amigos em favor da plataforma, havia sempre um argumento difícil de refutar: o chamado lock in. Ou seja, ao utilizar o serviço do Google, você acaba por se tornar prisioneiro da plataforma por causa do uso de suas bibliotecas e APIs personalizadas. Meu amigos sempre me alertaram que se o Google alterasse sua política de preços, eu ficaria refém do serviço, por não poder portá-lo para outro lugar.

Minha única justificativa, no início, era de que durante esses 3 anos a empresa nunca havia mudado sua política de preços de forma que eu fosse afetado significativamente. Sempre eu comentava sobre o custo irrisório do serviço, respondendo para o pessoal com o título desse post: sou um prisioneiro feliz.

Hoje o lock in não é mais um verdade absoluta. Existe o projeto de código aberto App Scale que permite a migração de sua aplicação para outras infraestruturas. Mas realmente até hoje não portei nenhuma, apesar de saber que já conseguiram portar com sucesso a aplicação do QMagico usando esse projeto. Além dele, existe também o CapeDwarf.

O fato é que em minha última conversa sobre o assunto com amigos me incentivaram a contar mais sobre essa experiência. Decidi então escrever esse post e ir além: no início deste ano farei um curso, com vídeos gratuitos, sob o título “Python e App Engine: você programa e Google escala!”. Quem sabe não consigo outros prisioneiros felizes como companheiros.

Atualização: já iniciei o curso no fim de 2013, confira nessa playlist do Youtube.