Blog do Eduardo Costa Meu blog pessoal

21Ago/110

Computação em Nuvem by Google

No início do ano, consegui fazer com que todos os meus serviços pessoais ficassem "na nuvem". Ainda estão, e com muito orgulho. Só que a "fidelidade" aos serviços da Amazon diminuiu. Ainda gosto muito dos serviços deles, mas duas coisas estavam consumindo muito tempo meu: configuração de e-mail e o bendito servidor de aplicações Java. A loja virtual de pronta-entrega Avon que eu fiz requer os dois, e os e-mails de potenciais clientes consomem tempo para responder da forma que um cliente de loja espera.

Além disso, o servidor Java vivia com problemas. No início, pensei que era algo com o Glassfish nas máquinas "micro" da Amazon. Todo dia era necessário reiniciar o servidor, que estourava a memória da máquina no segundo ou terceiro dia de uptime. Tentei trocar por um Tomcat, usando Wicket no lugar de JSF. A memória ficava no mínimo. A produtividade melhorou, graças aos testes unitários. O tempo para restart também melhorou, mas ainda existia. Agora que estou também on-line no BuscaPé, não posso me dar ao luxo de fazer "heartbeat manual" no servidor toda hora. Muito menos parar minhas atividades de funcionário BuscaPé para descobrir que algum bot mal-feito está consumindo 100% dos recursos do sistema.

Bolando um projeto para uma comunidade de divulgação de código, só tive duas escolhas: fazer em outra linguagem (ex: PHP) e consumir um tempo que eu não tinha, ou continuar em Java e achar uma solução para meus problemas. Meu amigo Nelson, que tem seu próprio projeto no Google App Engine, acabou me convencendo da praticidade - principalmente por causa do quesito "custo" (zero, para o tipo de aplicações Java que eu tenho).

Decidi, então, dar uma chance ao App Engine junto com seu tal "BigTables". Tentei inicialmente migrar a loja. O Wicket requer um ou outro truque para funcionar no GAE, mas a parte complicada foi a persistência de dados. JDO, JPA, low-level - tanto faz. O problema real são as limitações impostas pelo Google.

Do ponto de vista de um programador Java clássico (ouso dizer "de mercado"), é um lixo. Muitos recursos sine qua non de nossa vida diária (como o relacionamento MxN de uma "Venda"x"Produto", ou filtros de busca complexos) são bem mais difíceis de implementar.

Entretanto, é perfeitamente compreensível do ponto de vista de alguém que trabalhou até em Mainframes e que passou por uma excelente turma de banco de dados (tópicos avançados) na faculdade. Quando o sistema gerenciador de banco de dados te obriga a pensar um pouco mais, melhores soluções sempre surgem. Meu MxN não é carregado de forma "mágica" pelo JPA e os filtros são melhor pensados. O custo de processamento divide-se entre o banco e a aplicação, ficando mais claro o tamanho do problema que você impõe ao SGBD (ou você acha que "JOINs" e "subqueries" rodam de alguma forma mágica no banco?).

O projeto da comunidade foi, na visão de arquiteto e líder de projetos, um sucesso. Levou pouco tempo para implementar e com pouca chance de falhas, graças a quase 300 casos de teste, que rodam em 30s e cobrem até boa parte da interface (sem usar o Selenium). Mais uma vez, como tudo na solução é deveras simples, fica trivial testar - mesmo com uma arquitetura mais "densa" e com menos camadas.

Com os conhecimentos que obtive nesse projeto, consegui hoje terminar a migração da loja também para o App Engine. Não pude fazer um sistema muito "belo" internamente, por ter sido uma migração delicada (somente tenho uns 90 casos de teste), mas a infra é bem mais estável, e o sistema já ficou mais "mantenível".

De brinde, ao tentar configurar o redirecionamento dos domínios WWW, consegui também migrar o e-mail para o GMail. Não falo de "download POP" que nem o GMail padrão tem. Consegui configurar a conta do "fale conosco" para virar um grupo do domínio, criar uma conta para minha esposa e adicionar nós dois ao grupo. Assim, divide-se o tempo para responder aos potenciais clientes, tudo usando "contas Google Apps", que diferem das contas "Google pessoais", além da interface amigável do GMail (seja pela web - algo que senti falta - ou via IMAP).

Em resumo, tudo muito bem em duas núvens (Google para Java e e-mails, e Amazon para o resto), mas a pergunta: por que não usar o Beanstalk junto com o SDB? Simples: a arquitetura mínima deles requer uma máquina e um "load balancer" - o que significa duplicar meus custos. No Google, com menos de 2000 requisições por dia, fica gratuito. Quando eu superar a faixa de acessos gratuita, posso considerar uma reavaliação.

Comentários (0) Trackbacks (0)

Sem comentários


Leave a comment

(required)


*

Sem trackbacks