Por favor, não alimentem os trolls novamente nesse tópico!
[]s
É mais fácil o site da padaria do Tio Joào, que tem algumas centenas de clientes, cair, do que uma aplicação “corporativa” numa intranet sendo usada por 5 pessoas.
Enquanto isso como antecedia a imagem postada:
FIGHT !!! FIGHT !!! FIGHT !!! FIGHT !!! FIGHT !!! FIGHT !!!
Com certeza! Lendo a discussão de pessoas assim percebo quanto tenho ainda a aprender. Houve uma ótima discussão do Luca e do Kenobi no Tectura também.
Poderia ter mais discussões desse nível no GUJ a comunidade agradece.
Se vc lembrar de algum tempo atrás, vai ver que tinham muitas discussões de alto nível, mas com a proliferação dos trolls e de quem os alimenta, quem tem conteúdo interessante pra compartilhar acaba indo pra outros lugares.
[]s
saudades do guj…
Ruby foi bom por um tempo, agora pra manter o ritmo de crescimento os caras precisão de uma linguagem mais robusta onde Java se aplica perfeitamente, as complicações que envolvem um crescimento exponencial é inerente ao desenvolvimento de soluções escaláveis, Java está pronto a anos luz para isso! Eles deveriam ter escolhido Java desde o começo do projeto, se pensavam em um crescimento tão rápido.
Acho que nem o mais otimista dos investidores previa que o Twitter ia chegar onde já chegou, e pagando isso como raciocínio, eles estão fazendo a coisa certa mesmo.
Usaram uma tecnologia que lhes desse uma produtividade grande no início pra ter um “startup” rápido no mercado, e foram evoluindo sua arquitetura conforme a necessidade foi surgindo. Lembrando que a primeira troca que fizeram de Ruby por Scala, também teve falha técnica da equipe do Twitter que fez uma implementação de tosca de um componentes Ruby e acabou não lhes atendendo, possivelmente eles trocariam mais pra frente, mas essa falha antecipou uma escolha por trocar o componente.
Se hoje a necessidade que eles tem, vai ser suprida com o uso da JVM (e os componentes que rodam sobre ela, como o próprio Scala), então realmente fizeram a escolha correta e estão mais uma vez escalando sua arquitetura.
Independente do uso da tecnologia X ou Y, acho que hoje o Twitter é um case a ser estudado em termos de arquitetura e como gerir a escalabilidade da mesma, alguns podem chegar a conclusões ruim, outros a boas, mas de toda forma, merece ver mais de perto e absorver os pontos que podem ser usados em nossas decisões de arquitetura no dia-a-dia.
[]s
Esse era outro problema do Twitter, eles começaram como um Ruby Shop shiita como o pessoal que estava brigando aqui nessa thread era Java Shiita também e acharam que valia a pena inventar os seus próprios componentes em Ruby pra tudo, como o Starling/Workling pra filas de mensageria, que eram basicamente uma atrocidade. Pobres de código, instáveis e pouco testados, quando haviam diversas soluções em Java e em Erlang pra resolver esse problema.
Acho que hoje eles finalmente estão indo no caminho certo, indo onde a boa tecnologia está e não tendo mais “opiniões” sobre o que deve ser usado ou não. Agora se usa o que dá mais certo pro problema em questão.
Com certeza! Lendo a discussão de pessoas assim percebo quanto tenho ainda a aprender. Houve uma ótima discussão do Luca e do Kenobi no Tectura também.
Poderia ter mais discussões desse nível no GUJ a comunidade agradece.[/quote]
O Kenobi é um dos melhores arquitetos que frequentam o GUJ. Geralmente os posts dele são uma verdadeira aula. heheh
O nível do GUJ já foi bem mais alto mesmo, caiu bastante com a chegada de vários trolls, mas recentemente vem melhorando o nivel de novo.
:shock:
Twitter é um aplicação web, isso quer dizer:
-
pode mudar a linguagem quando quiser sem afetar seu funcionamento
-
twitter não deu certo porque “escalonava” e sim porque foi adotado pelos usuários, e pra isso a linguagem não teve a menor importância, e sim o produto. Se tivessem focado em “linguagem robusta” como vc sugeriu provavelmente teriam fracassado, e não teria os “problemas” que tem agora.
-
Twitter mudou para aumentar performance em milisegundos, não para aumentar escalabilidade. Até porque escalabilidade na web se da por meio do uso correto do HTTP, novamente a linguagem usada em cada servidor não influencia muito. Para sua informação, o sistema mais acessado do mundo é feito em PHP.
Se estiver falando do Facebook, a forma como eles trabalham com PHP não é a mais trivial, tanto que existe o projeto HipHop para converter o php em C++
http://developers.facebook.com/blog/post/358/
Agora, o facebook mesmo é um exemplo de aplicação que não é 100% HTTP pois no seu interior existem filas assincronas e mensageria que utiliza outras tecnologias como XMPP. O twitter mesmo utiliza mecanismos de detecção de spam assincronos, por exemplo. Não vamos simplificar os sistemas demais 
[quote=peczenyj]Se estiver falando do Facebook, a forma como eles trabalham com PHP não é a mais trivial, tanto que existe o projeto HipHop para converter o php em C++
http://developers.facebook.com/blog/post/358/
[/quote]
Acho que é trivial quando se tem ex-engenheiros do google. :twisted:
Acho que nem o mais otimista dos investidores previa que o Twitter ia chegar onde já chegou, e pagando isso como raciocínio, eles estão fazendo a coisa certa mesmo.
Usaram uma tecnologia que lhes desse uma produtividade grande no início pra ter um “startup” rápido no mercado, e foram evoluindo sua arquitetura conforme a necessidade foi surgindo. Lembrando que a primeira troca que fizeram de Ruby por Scala, também teve falha técnica da equipe do Twitter que fez uma implementação de tosca de um componentes Ruby e acabou não lhes atendendo, possivelmente eles trocariam mais pra frente, mas essa falha antecipou uma escolha por trocar o componente.
Se hoje a necessidade que eles tem, vai ser suprida com o uso da JVM (e os componentes que rodam sobre ela, como o próprio Scala), então realmente fizeram a escolha correta e estão mais uma vez escalando sua arquitetura.
Independente do uso da tecnologia X ou Y, acho que hoje o Twitter é um case a ser estudado em termos de arquitetura e como gerir a escalabilidade da mesma, alguns podem chegar a conclusões ruim, outros a boas, mas de toda forma, merece ver mais de perto e absorver os pontos que podem ser usados em nossas decisões de arquitetura no dia-a-dia.
[]s[/quote]
Desculpa corrigindo, onde lê-se linguagem refiro-me a plataforma, (falha tosca…). Sim concordo, Ruby garante sim uma alto produtividade, mas o que me referia é que se implemento um projeto de Micro-Blog, espero sim uma alta adesão , mesmo em sonho! Daí escolher desde o inicio a melhor plataforma para essa arquitetura é só previsão de mercado, exercício simplista de qualquer inicio de projeto. Não estou questionando que Ruby não dá conto do serviço, pelo visto, até agora ele se garantiu muito bem! Só que estou querendo puxar um brasa pra nossa sardinha… Java é a melhor plataforma escalável do mercado! E isso evita um bocado de reestruturação futura como neste caso.
Eu também acho que um dos motivos para eles escolherem utilizar java foi a maturidade do projeto netty. Trabalho em um projeto de integração entre sistemas que trocam informações em tempo real. A maioria dos sistemas é escrita em c ou c++ e qualquer latência que é colocada no percurso da informação (que vem de bolsas
de valores) é ruim para o negócio da empresa, já que um dos motivos dos produtos da empresa serem um sucesso é justamente o tempo de resposta. No início do projeto utilizamos webservices soap porém logo ficou claro que eles seriam uma barreira para a performance (como já esperávamos), então modificamos a implementação de referência para utilizar webservices rest utilizando o jax-rs, o que melhorou muito a performance da aplicação. Conseguimos também melhorar
o tempo de resposta utilizando um mecanismo de cache distribuído que implementamos utilizando um produto da oracle (Oracle Coherence), mas mesmo assim, em algumas situações, dependendo do número de acessos simultâneos, o tempo de resposta poderia comprometer o funcionamento das aplicações. Eu cheguei a implementar uma nova forma de acesso utilizando nio com io “não blocante”, o que obviamente melhorou a performance comparando com a implementação utilizando
o jax-rs, porém, para utilizar esta nova implementação, as outras aplicações teriam que ser todas alteradas para conectar-se diretamente via sockets ao invés de utilizar o protocolo http para as chamadas rest e, além disso, a manutenção da aplicação seria mais complicada, já que a maioria dos desenvolvedores não estava acostumada com o desenvolvimento utilizando sockets, nio, etc.
Foi aí que conheci a biblioteca netty e estudei o seu funcionamento. Desenvolvi os mesmos cenários anteriores utilizando esta biblioteca para processar as requisições rest que necessitavam de performance maior e realizando os testes de performance foi constatado que a performance era pior do que a implementação com sockets e nio (o que era esperado, já que mesmo utilizando a biblioteca netty as chamadas ainda eram feitas utilizando o protocolo http), porém a performance foi extremamente mais rápida se compararmos com as implementações do jax-rs (testei com o apache-cxf e jersey), mesmo eu tendo separado esta camada da aplicação e realizado o deploy no jetty e no tomcat em servidores diferentes dos que faziam parte do cluster do servidor de aplicações. A meu ver isto tem a ver com o fato de, com a biblioteca netty, podermos implementar um servidor http bem mais leve e dedicado ao trabalho que queremos fazer, ou seja, ao invés de termos um container web ou um servidor de aplicações “genérico” que, além de atender as requisições web, tem que “se preocupar” com vários outros processos da aplicação e dividir os recursos com todos estes processos, temos um pequeno servidor http extremamente leve, dedicado apenas a uma pequena parte da aplicação e com todos os recursos disponíveis utilizados para processar estas requisições. Desta forma nós distribuímos esta nova camada da aplicação desenvolvida com o netty por alguns outros servidores (os mesmos que antes rodavam o tomcat ou o jetty), que ficaram responsáveis apenas por atender estas requisições mais críticas e as outras requisições continuaram na implementação padrão que foi criada inicialmente, no cluster original do servidor de aplicações.
A implementação utilizando a biblioteca netty revelou-se extremamente mais performática em todos os cenários de teste que fizemos, e por fim conseguimos atingir o tempo de resposta especificado para a aplicação, e nenhuma aplicação “na ponta” que faz chamada aos webservices rest precisou ser alterada. Além disso, os desenvolvedores acharam muito mais fácil trabalhar com a biblioteca netty do que programar com sockets, nio, etc, o que vai facilitar a manutenção da aplicação. Eu recomendo muito o estudo e implementação utilizando esta biblioteca para casos onde o tempo de resposta é um requisito não funcional de extrema importância.
Primeiro, obrigado marcosalex. Estou muitíssimo lisonjeado com seu comentário e espero fazer jus.
Rogério, bacana seu depoimento e um case prático para podermos estudar.
Bom, acho que muitos possuem visão divergente. Enquanto acredito que não se tratava somente de performance, outros decordam e isso é normal, já que estamos apenas conjecturando com base no que lemos.
Mas precisamos separar 2 coisas: Linguagem e VM - Virtual Machine.
Java não é uma linguagem tão bem desenhada e está anos luz à frente como disseram, pelo contrário. Ela tem falhas graves de design e não precisa nem ir muito longe, falar dos generics types. Basta olhar a API de data.
A VM entretanto é avançadíssima realmente e como o Maurício disse, vai demorar muito até outras chegarem no nível. Contudo, a idéia da VM é se tornar cada vez mais plural e talvez no futuro tenhamos uma outra linguagem, melhor desenhada, fazendo uso dos seus recursos.
Scala é uma forte candidata, isso sem contar com coisas que estão vindo, como The Ceylon Project - http://blog.talawah.net/2011/04/gavin-king-unviels-red-hats-top-secret.html
Cheers,
Kenobi
Scala mal desenhada ? De onde você tirou isso ? Scala é uma linguagem muitíssima bem desenhada. Aqui vai só um exemplo de types do Rafael - http://blog.rafaelferreira.net/2008/07/type-safe-builder-pattern-in-scala.html.
Com Scala você consegue ter programação funcional, oop, metaprogramação, script direto do shell (http://www.scala-lang.org/node/166). Se você pensar então em aplicações distribuídas, tem Actors embutida (http://www.scala-lang.org/node/242), Collections Paralelas http://infoscience.epfl.ch/record/150220/files/pc.pdf . Vale à pena estudá-la à fundo, antes de dizer que o design dela é ruim. Analisar superficialmente por uma sintaxe que você não compreende, é um grave equívoco.
Quanto à “oficial” eu não gosto muito dessa idéia, espero que com a evolução da JVM ao longo do tempo, perca o sentido e a liberdade de escolha em detrenimento à necessidades.
1 - Olhar para os dois lados antes de atravessar a rua;
2 - Nunca, nunca, mas nunca mesmo, alimentar os trolls.
Kenobi por favor não resposta os posts do malconL, isso serve para os outros também.
Adicionei esse tópico ao favoritos pra voltar aqui quando eu for gente grande e conseguir entender a maior parte o.O
Me senti A caloura do ano.