Um desabafo de Zed Shaw, o homem que escreveu a versão original do servidor de aplicação Ruby Mongrel, me fez pensar sobre as experiências que a DreamHost teve hospedando sites movidos a Ruby on Rails nos últimos anos. O próprio desabafo foi um tanto longo, mas uma leitura interessante (embora autoindulgente) se você for um desenvolvedor de Ruby on Rails, um nerd que gosta dessas coisas, ou interessado nos bastidores de um projeto open-source altamente público.
Não tenho nada a acrescentar aos comentários de Zed Shaw sobre como a equipe de desenvolvimento do Rails opera, pois não tenho conhecimento pessoal disso. O que eu tenho conhecimento pessoal é de como pode ser difícil colocar uma aplicação Rails em funcionamento e mantê-la funcionando. A DreamHost tem mais de 10 anos de experiência em executar aplicações na maioria dos frameworks de programação web mais populares e Rails tem sido e continua a ser um dos mais frustrantes.
Alguma História
Quando começamos a implementar nosso suporte para Ruby on Rails, queríamos fazer tudo o que pudéssemos para apoiá-lo. Era uma nova e empolgante estrutura web que estava revitalizando o desenvolvimento de aplicações web. Ruby on Rails parecia realmente se encaixar na filosofia da nossa empresa e pensávamos que nossa base de clientes existente iria adorá-lo. Acabamos implementando muitas novas funcionalidades apenas para apoiar Ruby on Rails, incluindo o suporte a FastCGI. Rails em si acabou sendo muito lento para ser usado sem algum tipo de aceleração (ao contrário de qualquer outro ambiente de programação web que apoiamos), e FastCGI é de longe o mais adequado para um ambiente de hospedagem web compartilhada. Infelizmente, Rails e FastCGI simplesmente não se dão bem! Não importa o que fizéssemos, os usuários do Ruby on Rails continuavam vendo erros internos regulares do servidor. O melhor palpite que tenho é que o gerenciador de processos dinâmicos FastCGI estava educadamente pedindo para o processo Rails morrer e, em vez disso, eles apenas saíam e deixavam a aplicação na mão. Isso é em termos leigos, claro!
Esses problemas foram posteriormente em grande parte mitigados por um único usuário de Ruby on Rails que queria que funcionasse melhor em nossos servidores, mas a solução da própria comunidade Rails foi, francamente, estúpida. Eles disseram para parar de usar Apache e FastCGI (uma combinação que alimenta com sucesso bazilhões de sites, apenas não os de Ruby on Rails) e, em vez disso, reequipar completamente nossos servidores com Lighttpd e SCGI (um protocolo semelhante ao FastCGI que pode ser tecnicamente superior, mas quase ninguém usa). Essa sugestão mostra ou uma completa falta de entendimento de como funciona a hospedagem de sites ou um total desrespeito pelo mundo real. É tudo bem e bom recomendar que os usuários usem hospedagem de servidores dedicados de alta qualidade para suas aplicações comerciais, mas simplesmente não se pode ignorar o fato de que quase todos vão querer usar hospedagem compartilhada de baixo custo para começar. É apenas uma questão de economia simples. Além disso, pessoas que usam sistemas como Ruby on Rails querem passar tempo programando e não tempo configurando servidores. Recomendar tecnologias que não são amplamente usadas ou suportadas por nenhuma grande empresa de hospedagem de sites está colocando um fardo muito grande em seus usuários, as pessoas que você quer manter felizes! Ainda bem que nunca tentamos mudar nosso sistema para suportar Lighttpd e SCGI, também, porque 6 meses depois, a ‘coisa do momento’ na comunidade Rails mudou para Mongrel, em vez disso. Decidam-se de uma vez por todas!
Como Poderia Ser Melhor
Zed Shaw menciona em seu desabafo que até a aplicação Ruby on Rails gerenciada por DHH (o cara que escreveu Rails!) tem problemas regulares e precisa ser reiniciada várias vezes ao dia. A comunidade Rails é composta por programadores muito inteligentes e eles implementaram um ótimo sistema que funciona maravilhosamente quando não precisa de manutenção. É um dos sistemas de aplicação web mais instáveis que já tive experiência, e isso vem de alguém que já passou pelo servidor web Netscape que fracassou, bem como por muitas iterações do PHP (PHP tem muitos problemas próprios, então não fique muito convencido, pessoal do PHP).
Ruby on Rails possui um potencial incrível, mas aqui estão algumas coisas que simplesmente precisam ser corrigidas antes que ele possa ser tão amplamente utilizado quanto ambientes de aplicação web menos comentados como PHP…
- Ruby on Rails precisa ser muito mais rápido. Com um acelerador adequado, é bastante utilizável, mas sem ele é doloroso. O próprio Ruby é uma grande parte do problema, então isso pode acabar sendo apenas simplificar o gerenciamento das tecnologias de aceleração, infelizmente. Mongrel parece ser um grande passo na direção certa, mesmo que não seja específico do Rails. Espero que os desenvolvedores principais do Rails cooperem muito mais de perto com os desenvolvedores do Mongrel no futuro.
- Ruby on Rails precisa funcionar mais ou menos em QUALQUER ambiente. Você não pode esperar que seus usuários configurem seus servidores de qualquer maneira. Há milhões de sistemas estabelecidos que simplesmente não podem integrar qualquer tecnologia de ponta que você ache melhor esta semana. Se você continuar com essa atitude, certamente estará atirando nos próprios pés.
- Você precisa manter uma melhor compatibilidade com versões anteriores. É verdade que esta é uma área onde o PHP historicamente se saiu muito mal, mas isso não é motivo para não superá-los. Além disso, Rails é admitidamente muito jovem como plataforma de desenvolvimento e vocês ganharam MUITA atenção muito cedo. Ainda assim, com grande hype vem grande responsabilidade. Você precisa manter o momento agora.
- Oficialmente suportar ambientes de hospedagem compartilhada. A sensação que tenho da comunidade Rails é que Rails está sendo empurrado como um tipo de sistema de aplicação de alta qualidade e isso faz com que seja aceitável ignorar a vastíssima maioria dos ambientes web dos usuários. Você simplesmente não pode ignorar os usuários de hospedagem compartilhada. Na minha opinião, uma coisa que o pessoal do PHP fez que os levou onde estão hoje foi abraçar a hospedagem compartilhada e trabalhar duro para fazer seu software funcionar bem dentro dela. Isso significa que tem que ser muito leve (pode ser tarde demais para isso no Rails já!), e tem que se “encaixar” em uma grande variedade de ambientes operacionais com o mínimo de problemas e complicações. Trabalhos de compatibilidade como esse não são glamorosos, emocionantes ou divertidos, mas precisam ser feitos.
E Agora?
A DreamHost tem toda a intenção de continuar a dar total suporte ao Ruby on Rails. O Ruby on Rails tem um grande potencial, e acredito que com o tempo possa atender à expectativa que criou ao seu redor. Só espero que a comunidade não fique muito arrogante antes disso acontecer!
As opiniões apresentadas aqui são inteiramente do ponto de vista de um externo com alguma experiência na web. Eu sei que Ruby on Rails é usado em alguns sites de alto tráfego e é certamente possível fazê-lo funcionar bem. O que estou dizendo é que realmente precisa ser muito mais fácil. Você tem que ter cuidado para não confundir entusiasmo do usuário com fácil de usar. Usuários entusiasmados preencherão muitas lacunas na usabilidade (DreamHost prospera com esse fato!), mas você não pode contar com isso a longo prazo.
