Blog do Eduardo Costa Meu blog pessoal

29Out/120

Atualização do Servidor

Depois de meses sem publicar nada, verifiquei que meu servidor usava uma versão realmente antiga do Amazon AMI, datada de novembro de 2010. Existiam duas opções: atualizar na própria máquina, ou criar uma nova do zero. Optei pela segunda pois a máquina nova fica mais limpa, usando o NGINX no lugar do Apache, e com uma partição específica para módulos Perl (muito importante para meus futuros projetos Catalyst).

A Amazon facilitou horrores minha vida: bastou instalar tudo como qualquer outro linux, tirar snapshots aqui e acolá, e mover o Elastic IP de uma máquina para a outra. Pronto! Sem dores de cabeça.

O NGINX usei pois promete ser mais leve e escalável que o Apache. Talvez seja, mas os CGIs integrados do Apache fazem uma boa diferença. O FastCGI é uma promessa muito interessante, mas consome uma quantidade razoável de memória.

Já a partição Perl foi uma idéia doida que tive. Tenho um ou outro script utilitário rodando, e gostaria muito de não levar horas instalando módulos novos. Explicação: uso a "t1.micro", a máquina mais barata de todas, que funciona bem para minhas necessidades, mas tem uma penalidade para processos que consomem CPU. Instalar módulos Perl requer compilação e testes, que consomem CPU.

O truque que bolei foi pegar um snapshot da partição Perl (configurada com o CPAN-mini), anexar em uma máquina mais cara e sem os limites de CPU, instalar os módulos lá, depois fazer um hotswap na máquina de produção. Isso só daria certo se a arquitetura das duas máquinas fossem similares (ou seja, mesma distro e mesma arquitetura) - o que não era verdade na antiga máquina 32bits e nas novas 64bits.

Em resumo, tudo funcionou magnificamente (apenas consumindo um tempinho para migrar manualmente as configurações do Apache para NGINX). Não tenho nenhuma saudade da época em que esse tipo de procedimento era um parto que durava semanas.

Categorias: cloud Sem Comentários
9Nov/111

Segurança na Nuvem

Segurança na nuvem é um mito clássico. Vamos do básico: o que diferencia um serviço de cloud de um serviço de datacenter ou até uma solução "in-house"? Segundo os descrentes, ter uma equipe de infra e poder "tocar" fisicamente nos servidores é algo imprescindível. Mas, no fundo, é tudo igual. Veja o porquê nessa lista de problemas clássicos:

  • Perda de dados: muitos se borram de medo da nuvem, achando que é possível perder os dados. Alguém ouviu falar em backups? Pode ser um servidor na mesa do dono da empresa ou uma máquina virtualizada na Amazon. Se você não faz cópias de segurança, o risco de perder os dados é o mesmo. Se seu site está disponível em apenas uma máquina, sem nenhuma redundância (load balancing, cluster, etc), você tem apenas um ponto de falha - mais uma vez independente de onde sua máquina está.
  • Segurança: tem medo de alguém roubar seus dados? Persisto em dizer que uma máquina na nuvem é igual a qualquer outra - use criptografia e firewall. O Jet Propulsion Labs da NASA tem toda uma massa de dados sensível, e tudo na Amazon. Colocaram criptografia onde precisava e até um software de firewall customizado para fazer VPN com clientes externos. E sua rede interna? Vai bem? Firewall bem configurado, NAT correta, dados críticos criptografados? E-mail com algum sistema anti-vírus? Acredite se quiser, mas já recebi vírus em e-mail corporativo - o que não acontece nos meus e-mails hospedados no Google Apps.
  • Confiabilidade do provedor: segue a mesma regra da perda de dados - backup, redundância, segurança, etc. Se tem medo do provedor cair, sumir ou roubar seus dados, por que escolheu ele, então? O mesmo que escolher um provedor web de R$ 5/mês: assumir o risco da empresa prestar um péssimo serviço, sumir com os dados ou até te infectar com vírus (já fui infectado em um provedor barato da época de pós-adolescente sem grana). Ou ainda, é o mesmo risco do estagiário mal-remunerado que cuida do servidor fazer um "format c:" ou queimar uma placa.
Em resumo, note que esses mitos na computação em nuvem não são diferentes dos problemas que soluções "in-house" enfrentam. Meu blog está na nuvem e eu tenho as mesmas preocupações de segurança e afins que eu teria se estivesse na sala de casa ou num provedor web. Com a vantagem que não preciso me preocupar com a Eletropaulo faltando com a qualidade de serviço ou em sofrer na mão de suporte que configura mal o host e todos os clientes passam a ter acesso a tudo (sim, já aconteceu comigo - também na época "poor-guy").
Categorias: cloud 1 Comentário
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.

Categorias: cloud Sem Comentários
29Jan/111

100% Cloud Computing

[Cloud Server]Conheci Cloud Computing com Davi, na época diretor de TI da empresa na qual eu trabalhava. Desde então, tenho me interessado no assunto. Na época, acho que o exemplo mais sério que havia era o Google App Engine. Não vi muito retorno em uma nuvem que só provê o servidor de aplicação. Hoje também existe o BigTables para a base de dados, e meu ex-padawan Nelson tem usufruído bem da infraestrutura de Cloud da Google.

Eu, por outro lado, fiquei fiel aos serviços de Cloud Computing da Amazon. Meu primeiro contato foi com o Amazon Simple Storage Service (S3), que utilizei para guardar versões digitais dos meus principais documentos. Custou apenas US$ 0.01 por mês para ter uma cópia com garantia de 99.999999999% de durabilidade, e disponibilidade de 99.99% do tempo.

Algum tempo após, conheci o Amazon Elastic Cloud Computing. Custou US$ 0.10 por hora para ter uma máquina completa, com IP público, Linux com acesso root, totalmente irrestrito. Nessa época, gastar tanto assim não compensava, pois hospedagens Linux custavam R$ 5 ao mês, para alguém com minhas poucas necessidades. Além disso, o site Assembla provinha SVN gratuito e privado sem custo.

A vida era boa, mas os tempos mudaram. Assembla começou a cobrar para manter a privacidade. As hospedagens web começaram a contratar pessoas sem qualificação alguma. Até meus interesses mudaram: eu precisava de algum jeito melhor para fazer backup, armazenamento de arquivos, e, o principal: eu precisava de um computador novo.

Com minha esposa fazendo faculdade, fez-se necessário ter dois computadores em casa. Aproveitei a oportunidade para testar um conceito: "cloud desktop", reaproveitando um velho notebook K6-III que eu tenho para emergências. Na época, o Chrome OS ainda era embrionário, então adotei uma medida mais extrema: levantei uma máquina no EC2 e instalei um desktop remoto (nesse caso, o NoMachine). Funcionou com uma maestria incrível! Eu tinha o poder de uma máquina de 1.7GHz em uma máquina de 0.5Ghz.

Em pouco tempo, meus serviços secundários migraram para o EC2. Primeiro, claro, arquivos pessoais. Planilhas, projetos, entre outros foram para discos EBS, facilmente acessíveis onde eu estivesse. Logo após, migrei meus repositórios SVN e abandonei a Assembla. Mesmo depois de comprar um NetBook, esses dados ainda ficaram na nuvem.

[Custo Cloud]Máquinas eram levantadas e terminadas com um clique. Rotinas de backup ficaram cada vez mais práticas e robustas. Só meus blogs ficaram de fora da evolução. Até hoje.

Finalmente, mais de dois anos depois, com conhecimento e poder computacional que nunca imaginei possível ter a preços tão acessíveis, consegui migrar 100% de meus recursos online pra a infra da Amazon.

Alguns dos serviços que tenho hoje:

  • Um servidor Glassfish com uma loja virtual inteira - inclui um servidor Apache HTTPD, MTA, redirecionamentos e afins;
  • Envio e recebo e-mails usando meu próprio servidor IMAP/SMTP - ao contrário dos servidores POP das hospedagens web;
  • Meus dados estão mais acessíveis (para mim), com várias camadas de segurança - inclusive um repositório Mercurial;
  • Recebo todo dia um e-mail com o log das principais informações de acesso. Isso me permite cerrar ainda mais a segurança ao ver as tentativas de acesso anômalo (ex: nada mais de porta 22 para o SSH, além de restrição por usuário/IP);
  • Se precisar, ainda posso contar com meu "Cloud Desktop", que, agora, por ter menos uso, posso me dar ao luxo de usar uma máquina mais poderosa na Amazon;
  • Toda e qualquer tecnologia que preciso testar antes de implantar (ex: meu novo Mantis para projetos pessoais), uso uma máquina específica e descartável;
  • DNS 100% configurável com o Route 53 - além de aprender muito mais sobre esse assunto, ainda tenho agora subdomínios, domínios estacionados, múltiplos domínios, sem limite teórico de quantidade;
  • Tudo isso com direito a backup com um único clique.

Agradeço aos envolvidos pelo pontapé inicial. Ainda tenho muito a evoluir (ex: usar o RDS, SNS, além do novo Beanstalk), mas o que tenho hoje vale muito para mim, principalmente em conhecimento.

Categorias: cloud 1 Comentário