Heroku estreiou a versão comercial de sua solução de hosting de Rails na última semana, depois de uma etapa gratuita que durou por um ano. Eles descrevem seu serviço como um "provisionless deployment" porque opera e escala automaticamente, sem nenhuma administração do sistema. Enquanto ele é mais caro que suas alternativas e (por enquanto) é baseado na cloud da Amazom EC2 com as limitações de SLA que o acompanham, nós pensamos que eles tem uma sólida oferta que compensa uma análise mais detalhada.
Na última semana alguns de meus engenheiros e eu falamos com James Lindebaum, co-fundador do Heroku, para captar suas idéias sobre o serviço. Ele jovialmente chama sua companhia de um grupo de "Ruby guys". Um pouco mais de um ano e meio atrás, com suporte do YCombinator, James e seus dois sócios, Adam Wiggins e Orion Henry começaram a trabalhar em um serviço para permitir deployments extremamente simples de aplicações Rails. Nós pensamos que o que eles alcançaram não é revolucionário.
Usando Heroku, o deployment de uma nova aplicação web desde o início é alcançado com pouco mais de um punhado de comandos de seu terminal. Sem emails, telefonemas ou tickets de suporte necessários. Nós usamos o serviço deles na Hashrocket para hospedar nossos ambientes internos e eu posso testemunhar que, não é como outras experiências de deployment que você já teve. A instalação e o deployment com Capistrano é coisa do passado com Heroku. Depois de registrar o serviço e criar uma nova instância de aplicação na cloud do Heroku via sua ferramenta de linha de comando, o deployment é fácil como digitar "git push heroku master".
O push dispara um hook ("gancho") de processamento que compila a sua aplicação em um instância somente leitura que o Heroku chama de "Slug". É automaticamente testada para garantir que possa realmente iniciar. As dependências do Gem são automaticamente instaladas e mantidas por um arquivo de manifesto .gem no diretório raiz da aplicação, uma das únicas diferenças de uma simples aplicação Rails. Vale a pena mencionar que aplicações Merb e Sinatra (na verdade, qualquer Rack) são suportadas também.
Uma vez que o push ocorre, o slug é instanciado em um ou mais slots em um ambiente de grid computing especialmente projetado, onde é dado acesso para suas informações de banco de dados e cache, e trazido a vida. O único banco de dados suportado é Postgres. De acordo com James, Heroku não suporta atualmente MySQL porque ele não tem execução de DDL transacional.
Uma vez que um slug é ativado, ele se torna uma aplicação web totalmente funcional chamada "dyno". Cada dyno é um processo rodando em um servidor no grid e contém uma única cópia do código da aplicação, framework, middleware, Rack, servidor de aplicação, máquina virtual Ruby e ambiente POSIX. O servidor de aplicação utilizado é uma versão deles levemente modificada do Thin, com uma alocação de memória de 250 MB.
Em resposta a demandas de mudança, a infra-estrutura inteligente do Her0oku pode executar dynos adicionais, totalmente independentes em novas localidades do grid, ou desativar os nós que estão ociosos. O tempo de inicialização de um novo dyno é menor que 2 segundos, um fato que dá a plataforma Heroku, um nível sem precedentes de dinamismo. O sistema padrão de roteamento pode realmente colocar uma requisição "em espera" enquanto incializa uma nova instância de dyno para atender a alta demanda. Quatro dynos dão performance computacional equivalente a uma instância de servidores em ambientes convencionais.
O grido do Heroku é construido em uma robusta infra-estrutura de cloud computing que permite expandir e contratar como for necessário para acomodar quantos dynos e quantas aplicações forem necessárias. Acima do grid está uma sofisticada e altamente concorrente rede de roteamento que aloca requisições entre os dynos. Elementos adicionais, como cache HTTP e cache de memória, reduzem as requisições para os dynos e banco de dados, respectivamente.
De acordo com James, a rede de roteamento é proprietária e uma parte importante da inovação do Heroku. A versão inicial do sistema foi implementada como módulos C do Nginx e funcionaram até eles alcançarem 10000 aplicações e a perfomance começou a sofrer. A segunda versão do sistema de roteamento é escrita em Erlang e está funcionando muito bem.
O próprio Heroku é hospedado em um pool de instâncias muito grandes do EC2. Eu perguntei para James o quanto ele cobra sobre o uso direto do EC2, uma pergunta que ele achou difícil de responder. Já que Heroku inclui uma arquitetura de sistema completa que iria precisar de 6 ou 7 instâncias do EC2 para replicar para uma simples aplicação, é difícil de esboçar uma comparação de preço válida entre os dois serviços. Por outro lado, a facilidade com que novos dynos podem ser ativados e desativados representam redução de custos já que um gerenciamento de consumo cuidadoso é mais fácil de alcançar que com deployments normais do EC2.
O modelo de preço do Heroku é projetado para cobrar os usuários somente pelos recursos que eles consomem, e para atender as necessidades de usuários de todos os níveis. Há uma variedade de camadas para acomodar a todos, de empresas com enorme aplicações e milhões de hits únicos por mês, até o usuários que estejam no nível de entrada. Preço varia de milhares de dólares por mês até menos que 100 e a plataforma inclui uma oferta grátis para testar o serviço e rápida prototipação. Como mencionado antes, nós usamos a oferta gratuita para etapas de deployment internos e funciona muito bem.
O serviço da Heroku tem sido fortemente testado durante um período beta extendido, no qual foi feito o deploy de 25 000 aplicações Ruby para a plataforma por mais de 23 000 desenvolvedores diferentes. Em estimativas conservadoras, isto faz a plataforma Heroku 10 vezes maior que o outro fornecedor de deployment Ruby mais popular. Mesmo considerando que a oferta comercial é nova, James nos disse que ele tem tido clientes pagos desde o início e que com o suporte dos investidores deles, eles estão prontos para oferecer um compromisso sério e duradouro para seus novos clientes. (Heroku levantou $3MM da Redpoint Ventures em Maio de 2008.)