O Google lançou nesta semana o Google App Engine que é uma plataforma de Cloud Computing para qualquer desenvolvedor realizar o deploy da sua aplicação de forma simples num ambiente escalável. A novidade já está causando burburinhos lá fora e realmente tem motivos para tal.

Você já imaginou desenvolver uma aplicação e oferecê-la ao mundo com a estrutura do Google?

Esta é a proposta! Entenda mais abaixo por que fiquei surpreendido com o App Engine.

Recentemente, escrevendo sobre Arquitetura de servidores para aplicações Rails, citei o Amazon EC2, serviço de virtualização da Amazon Webservices. Quando conheci o EC2 fiquei bastante impressionado em ver como esse tipo de recurso está cada vez mais fácil de ser contratado e utilizado. Como previsto pelo pessoal do MIT TI vai se tornar uma commodity como água e luz. A Amazon foi pioneira no serviço e Cloud Computing e fez um ótimo trabalho.

O EC2 é realmente um caso de sucesso e está bastante consolidado, mas o App Engine sai muito na frente nessa corrida justamente por causa da amplitude dos serviços do Google.

Em termos técnicos poderíamos dizer que a Amazon e o Google são excelentes e ambos estão fornecendo serviços de infra-estrutura para o desenvolvedor, mas por que o App Engine sai muito na frente?

Além de oferecer máquinas virtuais, o App Engine oferece a estrutura da tecnologia desenvolvida e usada pelo Google nos seus aplicativos para qualquer desenvolvedor.

Está incluso no “pacote” do App Engine:

• Framework de desenvolvimento – Bibliotecas e frameworks para facilitar a programação.
• Datastore – Mesma tecnologia usada pelo Gmai
• Google Accounts – Seu usuário poderá ser autenticado para usar sua aplicação com a conta do Google
• Relatórios – Um sistema similar ao Google Analytics que informaŕa sobre as estatísticas do servidor, ou seja, uso de banda, processamento, memória e demais recursos.
• Conta Grátis – Você poderá utilizar gratuitamente com limite de uso para 5 milhoões de pageviews/mês e 500 MB

Estes são os aspectos que diferenciam o App Engine do EC2. O principal deles é a conta grátis, pois na Amazon, mesmo o valor sendo baixo, você já começa pagando e  apelo de não pagar NADA é de fato bem mais forte do que o utilizado pela Amazon no seu lançamento de que você paga MUITO POUCO.

Eu tenho algumas restrições quanto ao uso de alguns recursos do App Engine, mas dependendo de como as coisas caminharem, pode ser que este serviço se torne irresistível, como é o caso do próprio Analytics, que todo mundo usa.

Depois dessa análise, arrisco dizer que ambos os serviços não são concorrentes diretos. Acho que a tendência é que o App Engine abocanhe apenas as aplicações web enquanto o EC2 tome conta do resto de aplicativos e processamento que não estejam ligados à sites. Embora a Amazon estivesse caminhando para atender fortemente as aplicações we.

Vamos esperar para ver qual vai ser o resultado de mais uma briga de gigantes!

Abraços e até a próxima.

Utilizar web-services é muito bom, mas exige alguns cuidados. Nesta semana tive um problema que nunca imaginei que pudesse acontecer.

A conexão do meu servidor com o servidor do web service foi interrompida de uma hora pra outra.

Demorou um tempo para acharmos a causa e até agora o problema não foi resolvido por completo. Já conseguimos uma solução paleativa, mas de qualquer forma ainda preciso investigar o por quê do problema ter ocorrido.

Depois de muito chat com os donos do web service, detectamos que o firewall deles começou a bloquear as minhas conexões pois estava entendendo como sendo um ataque hacker. Muito estranho, mas o que acontecia é que o meu servidor começou a abrir quatro sockets para cada conexão sendo todos eles com a mesma “source port”. Por este motivo que o firewal começou a bloquear as conexões.

Agora, por que isso começou a acontecer ninguém sabe. Os possíveis motivos seriam: a) atualização de algum pacote no meu servidor, b) alteração na configuração do gateway do meu datacenter, c) mudança de regras no firewall do web service.

Das duas uma, ou meu servidor sempre mandou os sockets desta maneira e o firewall do web service não detectava antes, ou ele passou a mandar a partir de uma atualização de pacote no meu servidor ou a partir de uma mudança no gateway do datacenter.

Como eu não realizei nenhuma atualização no servidor, só restam as opções do datacenter ter alterado alguma configuração no gateway ou o web service ter alterado as regras no firewal.

O problema é que ambos dizem que não realizaram nenhuma alteração!

A solução paleativa, foi utilizar o servidor secundário do web service. Eles me passaram o ip e eu configurei no hosts para que o domínio do web service fosse atendido primeiramente pelo ip secundário. Isso resolveu o problema, mas não corrigiu a causa.Já apliquei um patch do grsecurity no kernel, que corrigiria uma possível falha. Não adiantou. Neste final de semana irei atualizar todos os pacotes do servidor, como solicitado pelo meu datacenter, e verei se isso resolve.

Estou acreditando que meu datacenter forçou essa configuração, para poder monitorar as conexões, uma vez que o meu servidor fazia muitas conexões por minuto ao servidor do web service. Mas só poderei cair em cima deles depois que atualizar meu sistema.

Situação delicada e neste caso o melhor é prevenir. Por isso o motivo deste post. Eu não imaginava que isso pudesse acontecer e me pegou de surpresa… Agora já estou me mexendo para evitar que isso aconteça novamente.

Ai vão algumas dicas para evitar este tipo de problema com conexões à web services.

• Primeiramente é interessante que você tenha ao menos dois servidores de aplicação, neste caso se der problema em um, você terá o outro de backup. O ideal é que cada um destes servidores estejam em datacenters diferentes, pois caso um datacenter aplique uma política de segurança que cause este problema, você terá tempo de tentar resolver o problema e até configurar um terceiro servidor, enquanto o de backup fica em produção.
• Comunique ao web service que você pretende fazer diversas conexões ao serviço deles. Pergunte sobre a política de segurança e sobre as regras do firewall. Se possível passe o IP do seu servidor para que eles possam colocar numa “white list”
• Comunique seu datacenter sobre o número de conexões que serão feitas á um mesmo IP (do web service). Pergunte sobre as políticas de segurança. Solicite que não haja nenhum tipo de interferência nos pacotes enviados do seu servidor para o servidor do web service.
• Prepare um túnel reverso de SSH, desta maneira, caso você não consiga realizar a conexão, você consegue roteá-la por outro servidor, chamado de “middle”, de forma que seu servidor se conecte ao middle e o middle se conecte ao web service.

Bem, espero poder ajudar com a experiência que tive. Deixem seus comentários caso tenham alguma sugestão para este caso.

Abraços e até a próxima.

Eu estudei ontem várias opções de arquitetura para aplicações web, focando um pouco em Rails. Eu queria chegar há uma opção econômica que tivesse alta performance, alta disponibilidade e fosse altamente escalável.

Encontrei este excelente slide entitulado How to build a state-of-art rails cluster.

Tendo em mãos as informações do slide, entrei no site do Datacenter Cari.net e montrei uma cesta de compras com 5 servidores sendo 2 load balancers (web), 2 de aplicação (app) e um de banco de dados (db).

Não saiu caro, fiquei empolgado com a solução. Se eu não me engano algo em torno de $550/mês e um setup de $1.000.

Depois disso continuei lendo sobre outras opções e cai no Amazon Elastic Compute Cloud ou Amazon EC2 ou só EC2. Eles disponibilizam máquinas virtuais dedicadas por $0,10 por máquina por minuto + uma micharia por consumo de banda, ou seja, você pode ter o equivalente a um processador 1.7gh com 1.75GB RAM 160GB RAM e 250Mb/s de Banda por apenas $72/mês.

Com a grana da primeira opção é possível pagar tranqüilamente 7 máquinas virtuais na Amazon e sem custo de setup.

Encontrei o projeto EC on Rails que é uma imagem para o EC2 que já vem com tudo instalado para você hospedar um site em Rails. Já vem inclusive com os gems e rake tasks que facilitam o deploy e gerenciamento da máquina virtual.

Fique mais empolgado ainda, mas como nem tudo é mágica, não demorou muito para eu encontrar as restrições. O EC2 não possui IP fixo nem storage persistente. Isso quer dizer que toda vez que a máquina virtual for reiniciada ela terá um novo IP e o disco estará “vazio”, ou seja, somente com a imagem, sem nenhum arquivo criado durante a utilização anterior.

O problema do IP fixo pode ser contornado com o WeoCEO, sistema de load balancing e escalonamento para EC2. Não deixe de ver o vídeo. Este custa $0,05 por máquina por minuto de uso.

A questão da falta de storage permanente a princípio pode ser contornada com o S3, web service da Amazon para storage.  Este slide mostra algumas opções para o banco de dados, que é o problema maior. Todas elas ainda são experimentais. Por enquanto a solução é copiar o banco de dados todo para o S# de tempos em tempos, mas usando esta opção, em caso de falhas, você perde tudo que foi feito do momento do último backup até o momento da falha, o que é inaceitável para sistemas em produção.

Resumindo, o EC2 é uma grande promessa para arquiteturas de aplicações web em produção, mas por enquanto é aconselhável utilizar apenas para ambientes de qualidade (staging).

A princípio o uso do EC2 deve ser realizado apena para processamento, ou seja, recebe dados, processa e joga pra fora. Caso você precise hospedar uma solução database-driven, procure os servidores dedicados.

Este foi um resumo do que estudei ontem, espero que possa ser útil de alguma forma.