Robsonfranca.eti.br

O @vedovelli, no Twitter, me pediu para esclarecer o seguinte micro-post:

@vedovelli Isso pq. eles falavam q a culpa era do #rubyonrails, que não escalava. Mudaram p/ #scala e parece q está pior #FAIL

Bom, aqui vai uma explicação rápida: o Twitter começou pequeno e modesto, usando Ruby para quase tudo (interface, gerenciamento de mensagens) e MySQL como base de dados. Acontece que a implementação deles de gerenciador de mensagens, feita em Ruby, não era assim uma maravilha. O site ficou caindo mais do que o "Bad Server, No Donut for You" do Orkut.

Primeiro eles culparam o MySQL. Migraram para outro banco (Oracle?). Os problemas persistiram. Em vez de analisar a carga no servidor e ampliar o parque (talvez com alguma parceira forte), resolveram que seria melhor botar a culpa no Ruby, mais exatamente no gerenciamento de mensagens meia-boca que eles fizeram, quando havia alternativas melhores.

Mudaram o culpado e a solução da vez foi implementar um gerenciador de mensagens em Scala, a queridinha dos desenvolvedores atualmente. Scala é uma linguagem orientada a objetos e funcional que roda na máquina virtual do Java. Ou seja, teoricamente o código ficaria escalável simplesmente porque a máquina virtual do Java é escalável.

Adoro quando a realidade mostra o contrário. Por mais que algumas plataformas sejam mais escaláveis, o que faz um código ser escalável é, antes de mais nada, a sua qualidade. Código (ou melhor ainda, algoritmo) meia-boca não-escalável em Ruby continua sendo não-escalável em Scala, Java, Python, PERL, Groovy, Erlang, COBOL, etc.

Mudanças de estrutura e refactoring são atitudes louváveis. Mas entender realmente qual o problema do Twitter é mais louvável ainda. Enquanto o crescimento (de usuários e mensagens) do Twitter for exponencial, uma mera mudança nas tecnologias não resolve os problemas decorrentes desse crescimento.