Salve,
Nos dias 11 e 12 de Setembro de 2010 aconteceu a primeira QCon São Paulo, organizada pela Caelum, que é a mantenedora do InfoQ Brasil. O evento é a versão nacional, e oficial, do famoso QCon, que acontece todos os anos em San Francisco e em Londres, uma conferência de desenvolvimento e arquitetura de software, e contou com mais de 700 de participantes que assistiram 40 palestras divididas entre 6 tracks, ainda tivemos vários Lightining Talks e excelentes happy hours :) Recomendo que vocês leiam o resumo da QConSP no blog da Caelum.
Tivemos vários palestrantes vários internacionais, e tive a oportunidade de falar com dois deles após suas palestras. O primeiro foi Randy Shoup, Distinguished Architect do eBay (o que acredito ser algo como o engenheiro-chefe do lugar). Em sua palestra, “Best Practices for Large-Scale Web Sites – Lessons from eBay”, ele mostrou os números e os desafios absurdos dos sistemas do eBay (veja o segundo slide para ter uma noção da escala), e explicou as lições que aprenderam para lidar com esse monstro, uma boa apresentação muito instrutiva.
Porém, ao fim da apresentação, fiquei com algumas dúvidas e consegui conversar rapidamente com ele. Um dos itens que ele repetiu dezenas de vezes foi a importância de se desenvolver sistemas resistentes à falhas e com dezenas de alternativas para evitar problemas que, inevitavelmente irão acontecer. Muitas pessoas, leia-se, PHBs, acham que esse tipo de preocupação é um exagero, e classificam investimentos de tempo e dinheiro nisso como desperdício.
Mas no fim, é um problema estatístico: se você tem 10 mil aplication servers e mil instâncias de bancos de dados, mais cedo ou mais tarde você vai ter problemas. Minha primeira pergunta foi: na prática, esses problemas acontecem regularmente? Ele me disse que sim, é normal haver problemas, que vão desde falhas de infra e conexão, até erros em programas e falhas de deploy. Graças as medidas tomadas, a maior parte dos problemas são evitados. A resposta só seria melhor se ele tivesse números para termos uma noção melhor da escala dos problemas :)
Ok, essa resposta era esperada, dado o conteúdo da apresentação. Outra questão é que, segundo as informações da palestra, os sistemas que hoje estão em operação começaram a ser desenvolvidos em 2001 (minha memória é péssima), ou seja, são sistemas relativamente antigos. Naquela época testes automatizados e as preocupações incessantes com qualidade de código e boa arquitetura eram muito menos difundidas do que hoje, então perguntei a ele: dada a idade do sistema, como é a qualidade do código? Ele confirmou minhas suspeitas, disse que os sistemas mais antigos não tem os padrões de qualidade que sonhamos hoje em dia, mas que eles investem tempo para consertá-los e melhorá-los e também substituí-los.
O fato deles terem reescrito os sistemas é um atestado de que mesmo corporações de tecnologia do tamanho deles precisam em algum momento parar e reavaliar a necessidade de um big rewrite. Concordo que big rewrites não devem ser comuns, ou mesmo a primeira opção, mas classificar todos eles como preciosismo técnico ou desnecessários é burrice.
Ainda sobre a idade do sistema, perguntei sobre a grande quantidade de sistemas especiais, escritos para fazer coisas como uma real-time search engine e bancos de dados chave-valor. Hoje em dia temos dezenas de opções open ou closed source para essas necessidades, e apesar de que provavelmente nem todas elas serem boas o suficientes para a escala absurda deles, algumas deveriam diminuir a necessidade de reinventar a roda. Tendo isso mente perguntei: vocês usam soluções open source atuais como os bancos NoSQL (Redis, CouchDB, etc), linguagens além do Java (Ruby, Python, Erlang, etc) ou search engines como o Lucene ou coisas similares? A resposta foi: sim, eles utilizam algumas dessas ferramentas, na época em que desenvolvimento foi feito muitas dessas ferramentas não estavam disponíveis ou eram muito novas, e eles preferiram escrever muitos sistemas eles mesmos. Segundo Shoup, se o desenvolvimento fosse feito hoje, provavelmente utilizariam algumas delas, e estão fazendo testes e experimentos com várias delas apesar da maioria dos sistemas em produção não utilizá-las.
Foi uma conversa bastante instrutiva, ele foi bem legal. Ouvir histórias de sucesso sem analisá-las, questioná-las ou colocá-las em contexto fazem as transformam em passatempo, perguntar faz toda diferença, e nos mostra que nem nessas empresas monstro os sistemas são perfeitos.