O que 9 sites grandes estão usando

Muita gente fala mal mas pra mim Perl kick ass!

//Daniel

é… LAMP tá dominando… será o custo ? ou puro improviso ?

ps: improviso que digo é como “VAMOS FAZER ALGO RAPIDINHO E BARATO” ae dá certo… e continuao mantendo ?

é…

ja assisti uma palestra onde o cara falou que o conjunto LAMP seria dominador :shock: agora… com essa exposição desse quadrinho… fiquei abismado!
retomarei meus estudos com o PHP!

não dificil perceber que ha grande maioria de sites é :

linux + apache + php + mysql

une baixo custo + rapidez + qualidade.

agora vamos ver ruby on rails, que promete ser ainda melhor.

Qualidade ? 70% dos sites que eu vi escritos em PHP beiram ao total desespero… um xunxo pior q o outro… nao sei estes grandes… mas afirmar que php é sinonimo de qualidade… eh foda…

Mas aí a culpa não é da ferramenta em si…

É verdade, conheço aplicações muito boas feitas em php mas que são programadas por pessoas capacitadas.

Cara, eu já programeimuito em PHP é uma solução facil e rápida para sites
Sim existem muitas porcarias por ai feitas em PHP, mas não excluisivamente por culpa da linguagem e sim pelos desenvolvedores.
E como é popular fica mais evidente as “besteiras”

Sempre imaginei que por trás de grandes estruturas de sites como estes tivessem plataformas mais robustas, como o Java. Se nem esses justificam o uso de nossa plataforma fico pensando onde o peso de um Application Server seria realmente útil.

Isso me fez lembrar de um vídeo: http://www.youtube.com/watch?v=PQbuyKUaKFo :lol:

Faltou orkut nesse quadrinho.

Eu tenho uma teoria: o que “grande” nesse caso realmente significa? Parece que é o número de acessos e não complexidade de aplicação.

Imagine, o digg tem apenas três funcionalidades: cadastro de usuários, exibir as notícias e votar nas notícias. Não é algo tão grande e complexo quanto um netbanking. A complexidade está em servir milhões de acessos simultâneos, não na aplicação em si.

E talvez por isso que quase nenhum dos sites usam Java, tem que fazer algo simples e que responda ao serviço rapidamente, e não ficar fazendo ligações com sistemas legados, se preocupar com segurança (pelo menos não muito) e administrar muitas funcionalidades.

Leonardo, mas fazer um site escalar para os volumes de acesso que o MySpaces suporta não é um trabalho simples de engenharia. Veja o LiveJournal, eles tiveram que construir um cache particionado distribuído (memcached) um file system distribuído (MogileFS), um proxy reverso que faz load-balancing (perlbal), um servidor de presença e IM com protocolo Jabber (DJabberd) e também um framework para execução distribuída de tarefas e RPC (Gearman).

Ferramentas essas que são ordens de magnitude mais complexas que escrever um sitezinho que te permite tirar extratos e pagar suas contas. Quantos code monkeys que desenvolvem os sites de internet banking dos bancos nacionais seriam capazes de entender o que são essas ferramentas? Java é usado pois facilita produção de software faceis com zilhões de features, que você consegue fazer com 10 caminhões de macacos.

python tb é uma linguagem super produtiva para aplicativos web é de fácil apredizagem
totalmente hibrida pode se programar tanto orientado a objeto quanto de forma procedural
já fiz algumas coisas em python vale a pena conhecer…!

é complicada essa questão…

mais tipo ja vi sites em jsps(“java”) muito piores que sites em php.

o acaba pesando mais é qualidade do programador

é curioso q perl é popular no estados unidos… já no brasil nunca vi

Leonardo3001:

Eu tenho uma teoria: o que “grande” nesse caso realmente significa? Parece que é o número de acessos e não complexidade de aplicação.

Imagine, o digg tem apenas três funcionalidades: cadastro de usuários, exibir as notícias e votar nas notícias. Não é algo tão grande e complexo quanto um netbanking. A complexidade está em servir milhões de acessos simultâneos, não na aplicação em si.

E talvez por isso que quase nenhum dos sites usam Java, tem que fazer algo simples e que responda ao serviço rapidamente, e não ficar fazendo ligações com sistemas legados, se preocupar com segurança (pelo menos não muito) e administrar muitas funcionalidades.

concordo com vc tb… as tres funcionalidades apresentadas a respeito do digg… qualquer linguaguem faz, php, asp… porem quando envolve complexibilidade e segurança será que elas oferecem? Por que algumas aplicacoes no Banco do Brasil funciona em Java?.. assim quando eu vejo… empresas grandes… como o google eu sempre me pergunto… pq eles usam essa linguaguem… e nao outra… para determinada aplicacao… eu fico bastante em curioso em saber + do pq… boa pesquisa… porem tem que ver é que nivel de aplicacao foi as linguagens foi usada… e de q forma…

flw!!

Sempre tive a impressão,e inclusive escrevi isso aqui, que java é imbatível para ser usado por macacos. (Mas, é claro, existe gente boa em tudo quanto é buraco)

python tb é popular no eua, só aqui no brasil que poucas empresas usam.

Depois falam q mysql nao aguenta banco grande :roll:

Perl e bastante popular no meio academico no Brasil, trabalhei muitos anos com bioinformatica e posso te dizer que o laboratorio que eu trabalhei e os outros da usp, unicamp, usam perl pra desenvolver seus aplicativos.
Ele eh otimo quando vc tem manipular arquivos texto.

Daniel

acompanhando o raciocínio do Luca, achei um artigo muito legal:

Why most large-scale Web sites are not written in Java
http://www.theserverside.com/news/thread.tss?thread_id=47135

Olá,

Pensei a mesma coisa! Mas acho que deve ter alguma engenharia a mais para suportar o número de acesso!

Abraços

Leonardo3001:

Eu tenho uma teoria: o que “grande” nesse caso realmente significa? Parece que é o número de acessos e não complexidade de aplicação.

…

E talvez por isso que quase nenhum dos sites usam Java, tem que fazer algo simples e que responda ao serviço rapidamente, e não ficar fazendo ligações com sistemas legados, se preocupar com segurança (pelo menos não muito) e administrar muitas funcionalidades.

Concordo parcialmente.

Discordo radicalmente. Java não é fácil. Inclusive tem complexidades idiotas como um objeto Date ridículo. Java é multi-plataforma e pode ser compilado (e descompilado também, mas não vem ao caso) e para mim essa é a força da linguagem. Ter uma série de ótimas aplicações open-source também ajuda muito.

Não é isso. O custo de criar uma conexão é muito mais baixo que o resto e a clusterização é muito simples. Além disso, é ideal para realizar consultas rapidamente.

Dizer que o digg não tem muitas funcionalidades pelo número de coisas expostas ao usuário não pode ser levado em consideração. Se for assim é só dizer que o YouTube é simples, quem toca o vídeo é o flash player, upload de vídeo é boçal de fazer. Que tal adminsitração, relatórios, controle de usuários, lidar com bases de dados gigantestas, repliacadas manualmente, caches distribuídos, filesystems com milhões de entradas distribuídas em centenas de nós…

Entre em um projetinho de portal web “de verdade” que você vai ver que desempenho em runtime de uma paltaforma é geralmente o menor dos problemas.

Como disse na minha palestra ontem no JustJava: escalabilidade através de cluster é um mito. Quando você precisa de desempenho de verdade vai ficar perdido quando as 300 máquinas começarem a replicar estado entre si.

As melhores arquiteturas para escalabilidade web são baseadas em share-nothing, oposto dos clusters.

http://www.niallkennedy.com/blog/uploads/flickr_php.pdf

Otávio,

Eu acho java ideal para fábricas. Java mantém o programador na linha dura, sem flexibilidade, isso é legal se a média não saca muito ou tende a fazer merda

Se fizer a mesma tabelinha com sites de Bancos, o panorama muda.

Não é bem assim… eu estava conversando com a Danese Cooper* ontem (ela está no Brasil) e ela estava contando que muitas vezes o povo lá até queria usar Python, mas acabam usando Java por ter mais profissionais e tal.

• Danese Cooper para quem não conhece está na diretoria da OSI e foi responsável por grande parte das questões de “open source” da Sun

pcalcado:

Dizer que o digg não tem muitas funcionalidades pelo número de coisas expostas ao usuário não pode ser levado em consideração. Se for assim é só dizer que o YouTube é simples, quem toca o vídeo é o flash player, upload de vídeo é boçal de fazer. Que tal adminsitração, relatórios, controle de usuários, lidar com bases de dados gigantestas, repliacadas manualmente, caches distribuídos, filesystems com milhões de entradas distribuídas em centenas de nós…

Entre em um projetinho de portal web “de verdade” que você vai ver que desempenho em runtime de uma paltaforma é geralmente o menor dos problemas.

Calçado, eu sei que normalmente você é mais inteligente que 99% dos programadores (não é ironia não! Eu acredito mesmo no que eu acabei de dizer! Acho impressionante a burrice que assola a área de TI), mas, apesar de não trabalhar em projeto de portal, trabalho em projetos de bancos e telecom, onde tem também seus projetos web. Por isso posso dizer o seguinte:

1. Banco e telecom tem administração, tem relatórios, tem controle de usuários, tem blá blá blá blá blá blá tanto quanto o projeto de portal que você falou, mas com adicionais! Tem que haver controle transacional, tem que haver prevenção e controle de fraudes, tem que lidar com legados de 20, 30 anos. Posso estar enganado, mas não consigo imaginar esses sistemas menores que um portal.

2. A história da Globo (é nesse lugar que você trabalha, né?) na internet não é nada parecido aos 9 grandes. Enquanto que a Globo só entrou em mercados já estabelecido por concorrentes e atirando pra tudo quanto é lado, as 9 grandes nasceram criando seu próprio nicho e raramente ampliaram para mercados distintos (porque esperam ou esperaram serem adquiridos pelas gigantes Google, Yahoo! ou Microsoft). Para um portal, o desempenho pode até ser “o menor dos problemas”, mas imagine uma empresa ponto-com que quer entrar em um mercado novo e incerto e que precisa de aumentos de público instantâneos. O menor pode se tornar crítico se uma espera no carregamento da página fizer com que o usuário mude para um site que está logo abaixo na lista de resultados do Google.

3. Eu disse que os 9 sites citados são simples porque não há controle transacional, não há segurança complicada (já viu token ou biometria em algum desses sites?), não há uma enorme quantidade de tabelas relacionais (pelo menos não como em banco e telecom), a quantidade de usuários que fazem acesso “read-only” é muito maior do que aqueles que fazem “read-write” (ao contrário de sites de banco) e por aí vai. Mas é claro que o fato de prover acessos a milhões de pessoas simultaneamente tira o adjetivo “simples” a esses sites; se dei a entender isso, foi mal.

4. Digamos que digg possua zilhões de funcionalidades por trás, não os considerei por dois motivos: a) não faz a diferença entre competidores, e b) não é crítico ao negócio.

Essa é a base da minha crença do por que os 9 sites grandes usam majoritariamente LAMP, eles precisam simplesmente fazer seus serviços rapidamente e em grande quantidade, não precisam dos muitos serviços que um servidor de aplicações oferece. Eles estão sacrificando a segurança, a manutenibilidade e a facilidade de desenvolvimento para prover acesso em larga escala (o que não é demérito). Ao contrário, os bancos e telecom, que não podem jogar fora aquilo que os nove grandes jogaram, estão usando bastante J2EE.

Leonardo3001:

…
Essa é a base da minha crença do por que os 9 sites grandes usam majoritariamente LAMP, eles precisam simplesmente fazer seus serviços rapidamente e em grande quantidade, não precisam dos muitos serviços que um servidor de aplicações oferece. Eles estão sacrificando a segurança, a manutenibilidade e a facilidade de desenvolvimento para prover acesso em larga escala (o que não é demérito). Ao contrário, os bancos e telecom, que não podem jogar fora aquilo que os nove grandes jogaram, estão usando bastante J2EE.

Não entendi essa parte, eles estão sacrificando a segurança usando Linux e Apache?

Bom,a tualm ente eu trabalho num grande portal mas passei os últimos sete anos exatamente nestes segmentos: logística, billing GSM, análise de risco e aplicações financeiras.

Eu não comparei os dois segmentos, comparei o desenvolvimento de sites de grande volume e de baixo volume. De qualquer forma, a grande maioria dos sistemas que rodam em, digamos, telefonia, são feitos em C/C++ e se itnegram por coisas como Tuxedo. Logística então é lar de softwares especializados e barramentos que existiam antes que a sigla ESB fosse criada.

Você não trabalha em um portal

Como falei são segmentos muito diferentes mas você está fazendo uma comparação injusta. Imagine o trabalho que dá mantêr privilégios para assinantes, não assinantes, assinatnes com pacotes especiais, proibir acesso internacional á alguns conteúdos, liberar para outros, fazer sistemas que possam ser distribuídos em CDN, criar mecanismos de cache, sincronizar aplicação e streamming, controlar fraudes e tentativas de ‘roubo de sinal’, gerenciar acervos, integrar com outros sites, etc etc etc

Eu estou an Globo.com há exatamente um ano e infelizmente não posso comentar a fundo este assunto (contrato) mas sua observação não condiz com a realidade. O que você chama de Portal não existe, dá uma olhada aqui: http://www.globo.com/Globo.com/sites/0,,5623,00.html a maioria é conteúdo mas veja quantos aplicativos rodam. mesmo para o conteúdo. Eu não tinha idéia de quantos sistemas e integrações são necessários para fazer um mero ‘portal’ até ir trabalhar com isso.

Desculpe mas você não pode afirmar isso a menos que tenha trabalhado lá. Aliás, quando eu trabalhava com billing real time para redes GSM em uma operadora multinacional as tabelas eram muito simples e todas em memória, exatamente porque o sistema tinha que ser simples e eficiente. Este sistema roda em boa parte das operadoras GSM do mundo e foi o primeiro sistema de billing pré-pago existente.

Leonardo3001:

4) Digamos que digg possua zilhões de funcionalidades por trás, não os considerei por dois motivos: a) não faz a diferença entre competidores, e b) não é crítico ao negócio.

Essa é a base da minha crença do por que os 9 sites grandes usam majoritariamente LAMP, eles precisam simplesmente fazer seus serviços rapidamente e em grande quantidade, não precisam dos muitos serviços que um servidor de aplicações oferece. Eles estão sacrificando a segurança, a manutenibilidade e a facilidade de desenvolvimento para prover acesso em larga escala (o que não é demérito). Ao contrário, os bancos e telecom, que não podem jogar fora aquilo que os nove grandes jogaram, estão usando bastante J2EE.

Sumarizando: Já trabalhei nos dois lados e te digo que são equivalentes em complexidade. Os requisitos não funcionais de um portal deixam o desenvolvedor comum de cabelos em pé porque eles não estão acostumados sequer à medir peso de páginas. Dificilemnte um programador Java se preocupa com performance da aplicação desde que ela seja razoável. Na web não existe performance razoável, é correr contra gargalos o tempo todo porque se você for um sucesso sua vida vai ser um inferno otimizando tudo o tempo todo, da marca de palcas de rede utilizada até tornar seus programas assíncronos e paralelos manualmente.

Eu não te critico por pensar assim de grandes sites porque eu, sinceramente, também pensava. Afinal, já trabalhei em projetos de gerência de informação que foram simplesmente comprar um CMS e consertar sus bugs (nenhum CMS presta), um portal é apenas um bando de páginas estáticas, certo? Pode ter sido um dia mas não é não. Soluções de CMS não funcionam para portais de verdade. Eu conversava exatamente com o Kumpera dia desses sobre nossas experiências com portais e como isso mudou nosso modo de enxergar sistemas escaláveis. Imagina o que é sair de um sistema de análise de risco de commodity que trabalha como application service provider, define seu próprio escalonador de jobs assíncronos, tem uma versão de JBoss hackeada. Eu realmente achei que entrar para o mundinho dos portais ia ser fácil, tão fácil que ia ser tedioso. Ledo engano. No meu projeto atual tivemos que fazer um baita hack no Rhino, por exemplo, além de criar frameworks para coisas para as quais nãoe xistem bibliotecas no sourceforge: ninguém quer liberar seus fontes sobre assuntos delicados.

Vou te dar alguns exemplos de tecnologias de ponta: Memcached, MogileFS, GoogleFS, BigTable. Estas tecnologias surgiram para mantêr portais funcionando.

Excelente post Philip!
Shoes, uma pergunta(Tá, na verdade são três!):
Se vc tivesse que projetar uma aplicação para 10 milhões de usuários,baixo numero de tabelas(umas 6, tipo um Orkut de pobre) altíssimo numero de consultas, média-alta de escrita, o que vc usaria como tecnologia para implementá-lo?(OBS.:Considere que temos a parte de Hardware ideal, ou seja, o quanto precisarmos, teríamos o suficiente de máquinas e cabeamento/banda).Teria coragem de usar Java?Qual a maior app usando Hibernate que vc já fez/ou viu?

Olá

Adoro quando eu consigo lançar um tema e depois a galera se mata discutindo. Fico só lendo e me divertindo.

Só preciso fazer 2 observações:

1. Estes 9 sites não são “os 9 grandes” e sim “9 dentre os grandes”. Há milhares de outros sites enormes, simples ou complexos

2. Não é a simplicidade ou complexidade do que executa que torna um site grande. Querem exemplo mais simples do que o Google?

Não consigo comparar sites com objetivos de negócio muito diferentes porque é muito difícil para quem está fora tentar advinhar o que tem por trás. Há bancos enormes com sites bem simplizinhos e com poucas facilidades. Geralmente os sites ligados a empresas do ramo de midia fornecem muito mais facilidades. Talvez para fazer o chat o UOL precise de uma infra estrutura mais parruda do que Internet Banking do Bradesco. Como posso saber disto sem informações lá de dentro?

[]s
Luca

Acredito que eu esteja puxando a sardinha pro meu lado e dizendo que só aquilo que eu vi é que é difícil, os outros é que são fáceis. Se o Calçado diz que portal também é difícil, não vou duvidar disso.

Mas ainda ficou a dúvida: o que fizeram esses 9 sites a adotarem LAMP ao invés de Java? Não sei se seria a facilidade de desenvolvimento o motivo principal, porque se fosse assim, haveria aqueles que adotariam Ruby on Rails ou Django.

Uma outra teoria minha foi que suas necessidades não eram supridas por frameworks livres ou comerciais, tendo que criar suas próprias soluções. LAMP, cujas siglas são livres “por tradição” possui uma comunidade de desenvolvedores espalhada pelo mundo com know-how sobre suas implementações. Ao contrário de Java, cuja chancela free foi cunhada à pouco tempo, e cujo conhecimento de sua implementação ainda se prende dentro das paredes da Sun, da IBM ou da Red Hat.

Nesse caso, seria melhor criar um framework sobre LAMP, pois a quantidade e a qualidade de profissionais que pudessem mexer em detalhes internos da estrutura da plataforma era mais disponível para a plataforma LAMP do que para a plataforma Java.

E aí? Faz sentido ou tô viajando?

ASOBrasil:

Leonardo3001:

…
Essa é a base da minha crença do por que os 9 sites grandes usam majoritariamente LAMP, eles precisam simplesmente fazer seus serviços rapidamente e em grande quantidade, não precisam dos muitos serviços que um servidor de aplicações oferece. Eles estão sacrificando a segurança, a manutenibilidade e a facilidade de desenvolvimento para prover acesso em larga escala (o que não é demérito). Ao contrário, os bancos e telecom, que não podem jogar fora aquilo que os nove grandes jogaram, estão usando bastante J2EE.

Não entendi essa parte, eles estão sacrificando a segurança usando Linux e Apache?

Ele quiz dizer seguranca na aplicacao, nao estava se referinco ao Linux ou ao Apache serem “inseguros”.

pcalcado:

Completando o que o Shoes falou, eu nunca trabalhei em um sistema de portal, mas estive quase. Fiz uma entrevista la na globo com o Shoes e mais duas pessoas estes tempos atras e realmente pelas perguntas que me fizeram deu pra ver que a coisa não era pequena. Parecia interessante pra quem buscava desafio.

]['s

Acho que o principal benefício de LAMP é a abertura que a plataforma possui. Java é um jogo de caixas-pretas, você tem um servidor de aplicações com tudo dentro dele, a única opção real para IPC é sockets. LAMP segue a excelente filosofia UNIX de pequenos pedaços que se unem para compor um sistema.

Talvez a questão seja mais simples…

O Java "hoje" endereça todos os pontos fracos mencionados, a questão é, alguém usa o "Java de hoje"?

Bancos foram mencionados... a grande maioria deles presos em versões arcaicas (como o Java 1.3 na grande maioria), com sérios erros de modelagem, nenhuma utilização de replicação de sessão nos seus clusters, controle manual de sessão, integração com sistemas legados à nível de aplicação e pior, atrelados a uma arquitetura "pré-java" que algumas vezes contém até ASP.

- Das pessoas que dizem que Java não é produtivo, quantas usam JEE 5?
- Daquelas que reclamam da flexibilidade quantas usam Generics?
- Daquelas que reclamam de qualidade, quantas usam Javadoc corretamente e os excelentes frameworks de testes unitários?
- Das que reclamam de integração, quantas usam JMS, WebServices, JBI, JNA, JCA e outros?
- Das que reclamam de performance quantas usam uma versão recente da máquina virtual, com incrementos de performance a cada versão?
- Dos que falam em segurança, que tal JAAS?
- Dos que reclamam de escalabilidade, quantos criam sistemas orientados à mensagens e filas de requisições?

Poderíamos continuar a lista acima, de forma a fazer com que as pessoas não quisessem mais ler este post :-)

O grande "problema" que vejo no Java é a questão do "começar grande", não se pode escrever uma aplicação Java (principalmente para web) sem ter certos cuidados e precauções (que não precisamos em certas linguagens como PHP), por ser completamente orientado à objeto, o Java nos força a definir nossa estratégia e arquitetura em tempo de modelagem... Sistemas que não foram feitos pra escalar simplesmente não escalam...

Filosofia... Pessoas que estão acostumadas a trabalhar com o estilo M$ ou aficcionados em unix não perdem um update ou nova versão... já aplicações em Java tem que continuar no "ambiente" delas, sem alteração.

O tópico gera muita discussão pois estamos comparando coisas que não são equivalentes... Coloque dois desenvolvedores, um JavaEE e outro PHP, quem leva menos tempo para colocar uma mensagem numa fila MQ por exemplo?

Java não foi desenvolvido para produzir sites, é uma linguagem "globalizada" endereçando a integração em ambientes complexos, que vão desde Celulares em frente de caixa até o controle assíncrono e distribuído de transações em larga escala.

Na área de exemplos, que tal o eBay? é complexo, distribuído, "grande"... Majoritariamente em Java e suporta um grande número de acessos simultâneos...

Só não acho justo "culpar" o Java por "defeitos" que foram corrigidos à bastante tempo. Se vamos levantar estas questões, que seja com informações atualizadas e não com citações do tipo [i]"Teria coragem de usar Java?Qual a maior app usando Hibernate que vc já fez/ou viu?"[/i] e [i]"a única opção real para IPC é sockets"[/i]...

Acho que é tudo o que gostaria de acrescentar, peço desculpas caso alguém se sinta ofendido pelo que acabou de ler, mas é apenas uma dose da amarga "verdade"...

PHP é bom, oq vai dizer se é bom o site ou ruim é o desenvolvedor nao a linguagem como um carinha lá em cima flw

Geralmente nao foram eles que escolheram se prender a estas tecnologias, foram os fornecedores de tecnologia.

Existem comparações de tecnologias ditas ‘mais produtivas’ com Java EE 5, basta procurar.

Ahm?! O que generics têm a ver com flexibilidade?!?

Estes frameworks e ferramentas existem para qualquer plataforma hoje em dia. na verdade se você olhar coisas como RSpec e comparar com os equivalentes em Java vai ver que há um bom tempo a plataforma não é mais o supra-sumo de ferramentas e paradigmas novos.

Que eu conheço, todos. E aí está boa parte do problema: soluções incrivelmente complexas de conectores e barramentos que são vendidos como A solução definitiva. Um ponto interessante é que soluções simples e eficientes são completamente viáveis em java (ou qualquer plataforma) mas não é isso que é vendido por aí, seja por fornecedores ou por centros de treinamento.

Acho que é exatamente o oposto: performance hoje é uma das grandes vantagens de Java. Versões recentes?! Desde a JVM 1.4 que não faz sentido questionar a performance de Java. Hoje o movimento é exatamente produzir uma VM para linguagens como Ruby e/ou utilizar outras linguagens na CLR e JVM.

Solução complexa com uma especificação cheia de buracos. Acegi é uma boa alternativa mas dificilmente se precisa de tantos recursos, uma ACL geralmente é mais que suficiente e isso dá para implementar na mão em pouco tempo.

E por que isso seria um ponto a favor de Java se qualquer engine de fila oferece suporte à dezenas de plataformas?

Qual a diferença? Existem conectores MQ para quase todas as plataformas de desenvolvimento.

E esse é sue maior problema: nãoe xiste linguagem ou paltaforma que seja a melhor opção para qualquer cenário.

E quem disse que java não suporta este tipo de coisa? Se você ler o tópico vai perceber que a pergunta é por que os 9 sites citados não usam Java. Você está mais preocupado emd efender sua tecnologia favorita que em participar do tópico

Ah, então Java tem opção apra fazer IPC? Se importa de me dizer qual? Sabe como é, nestes 7 anos eu venho procurando uma opção viável que não inclua JNI nem filas em disco, seria fantástico saber este seu segredo.

A pergunta Hibernate do Ironlynx não foi uma crítica à Java, foi uma pergunta sobre escolha tecnológica. Alto acesso, uso Hibernate ou não? É bom entender um texto antes de comentá-lo, cuidado com o protecionismo.

zardi:

Acho que é tudo o que gostaria de acrescentar, peço desculpas caso alguém se sinta ofendido pelo que acabou de ler, mas é apenas uma dose da amarga “verdade”…

Uma bela dose de pretensão, isso sim. As pessoas que estão discutindo neste tópico no mínimo são desenvolvedores experientes e sua ‘listinha’ não trouxe nada de novo aqui. Ninguém quer comparar Java com a linguagem X porque faz uma década que discutimos isso e não faz sentido. Este não é o ponto da discussão.

Se você não consegue aceitar o fato que java não é indicada para qualquer cenário eu sinto muito. Mais uma vez vou citar Robert C. Martin:

Leonardo3001:

Eu tenho uma teoria: o que “grande” nesse caso realmente significa? Parece que é o número de acessos e não complexidade de aplicação.

Imagine, o digg tem apenas três funcionalidades: cadastro de usuários, exibir as notícias e votar nas notícias. Não é algo tão grande e complexo quanto um netbanking. A complexidade está em servir milhões de acessos simultâneos, não na aplicação em si.

Eu concordo contigo. “grande” é sinônimo de “muitos acessos” e não de “complexidade de regra de negocio”
Em tese java é melhor para resolver regras complexas e muitos acessos é uma questão de arquitetura e não de linguagem. Ou seja, esses “grandes” são até bem pequenos e a tecnologia que os suporta poderia ser qq, desde que permita uma taxa elevada de consultas simultâneas.

Seria interessante encontrar aplicações complexas ( não necessáriamente “grandes”) para ver se o java tem afinal alguma vantagem… se não tiver, porque usar java afinal ?

Ufa, ainda bem que pelo menos vc entendeu o que eu escrevi! :lol:

Eu concordo contigo. “grande” é sinônimo de “muitos acessos” e não de “complexidade de regra de negocio”
Em tese java é melhor para resolver regras complexas e muitos acessos é uma questão de arquitetura e não de linguagem.

Eu tenho a mesma duvida com o hibernate.

Quanto a java e esses sites, eu nunca trabalhei com php, ruby, perl etc, soh java, naum tenho muita experiencia e tal, e os sistemas que desenvolvo geralmente saum sistemas com um monte de formulario, telas de grid, algo bem crud mesmo, gosto de usar jsf, acho super produtivo, entao quando vejo essas discussoes fico curioso, penso pow a que ponto esta o desenvolvimento, aquelas arquiteturas JEE com aqueles patterns todos, que muitos ainda preciso estudar melhor, ainda valem?! por um lado eu vejo uma arquitetura como a JEE avancando de tal forma que parece ser o futuro, e por outro uma pesquisa dessas mostrando que muitas empresas naum usam nada disso.

Entao minha pergunta, todos esses sites poderiam ser desenvolvidos usando java certo?! essas empresas naum saum “pobres” a ponto de naum conseguir bancar um servidor de aplicacoes JEE, com java eh possivel vc criar algo que abstraia muita coisa e acabe tornando o desenvolvimento rapido, vi aqui que muita da discucao eh em torno da quantidade de acessos.
Seila, na opiniao de vcs, porque eles optaram por usar essas tecnologias?! desenvolvimento rapido?! arquitetura simples?! custo de manter um servidor baixo?! melhor performasse?! ou elas suportam uma quantidade de acessos maior?! o pcalcado falou “java não é indicada para qualquer cenário”, com certeza, mas como naum conheco muito, se possivel gostaria que comentasse esses cenarios, ateh para podermos aprender e entender essas decisoes, lendo essas coisas eu fico muito na duvida se estou usando as coisas certas nos meus projetos.

Valeu!

luBS, empresas como Flickr e YouTube eram paupérrimas no começo, mal tinham grana pros servidores - logo tinham que usar a tecnologia mais produtiva na época. Seus sites não são hoje me Java pois é idiotisse jogar dinheiro fora re-escrevendo e a dificuldade em escalar esse tipo de site está mais relacionada a infra que ao tier de view.

Esses sites usam sistemas com muito mais tiers que o habitual para J2EE. Desde proxy reversos, caches distribuídos, a banco de dados com sharding. Coisas que nenhum deploy “enterprise” J2EE jamais usaria.

O crescimento de tecnologias open source é um fato no atual cenário. Isto se deve em função de vários fatores, como por exemplo:
Custo, Infra-estrutura utilizada, segurança, desempenho, confiabilidade da plataforma, entre outros.
O sistema operacional Linux tem alavancado o desenvolvimento web em PHP integrando com bancos de dados MySQL ou PostgreSQL.

Nas minhas experiências em tentar escalar aplicações já existentes, seja em Java ou em outras plataformas, posso dizer que tive mais dificuldade quando a aplicação era em Java.

Acredito que isso seja mais culpa dos arquitetos e seus purismos do que propriamente da plataforma Java.
Outro dia estava trabalhando num proxy reverso para uma aplicativo ASP que tem mais de 10 anos. Foi muito mais fácil que todas as experiências que tive com Java. O detalhe e que este aplicativo foi construído no codifica-e-remenda. Não existiam arquitetos naquela época.

Estou totalmente de acordo que não existe uma tecnologia que resolve bem todos os problemas e que temos que combinar o que cada uma oferece de melhor.

Tenho pra mim que saber combinar essa salada será o que diferenciará os bons dos normais no futuro.

Adorei a discussão, alto nível, parabéns à todos

Meu ponto de vista sobre java no que tange missão crítica é que muitos arquitetos de soluções não olham para o mercado e enxergam produtos que podem agregar na construção da sua infra-estrutura.

Um exemplo claro são produtos similares ao memcached como Gigaspace que endereça uma série de problemas como topologias de cluster, escabilidade linear, failover, memória compartilhada para latência mínima entre outros.

Conhecer com um pouco mais de profundidade alguns produtos que estão no mercado, ApplicationServers mesmo, que muitos nem tunning fazem … por exemplo Sun que traz consigo um produto comprado da clustra ( empresa que fazia cluster para o setor de telecom) o HADB. (replicação em memória através de clusters); é fundamental para o desenho de soluções de missão crítica.

IM da solução poderia utilizar algo bacana que é o projeto JXTA e por aí vai, que poderia até escrever um tratamento de GRID em cima do mesmo.

Finalizando meu ponto de vista, acho que o problema não está na plataforma Java ou especificação e sim achar que ela irá contemplatar todos os cenários e não abrir o seu leque de possibilidades dentro da mesma.

Quando o pessoal começar a olhar para estratégias como http://www.eecs.harvard.edu/~mdw/proj/java-nbio/ e não achar que simplesmente o TomCat - escolha seu favorito, spring e tre le lé , vai resolver todos os seus problemas.

Pattern MapReduce http://209.85.163.132/papers/mapreduce-osdi04.pdf by google e implementação lab - https://map-reduce-example.dev.java.net e por aí vai …

O mundo java é muito mais amplo do que se imagina e na minha ótica a maior parte dos sites escolhe estratégia Lamp por custos inerentes e baixo conhecimento de alternativas como essas citadas.

Olá

RodrigoSol:

Estou totalmente de acordo que não existe uma tecnologia que resolve bem todos os problemas e que temos que combinar o que cada uma oferece de melhor.

Tenho pra mim que saber combinar essa salada será o que diferenciará os bons dos normais no futuro.

Um exemplo disso aí:

http://www.leahculver.com/2007/10/08/pownce-lessons-learned-fowa-2007/

Pownce: Social messaging application Developed in 4 months
Django (Python web framework), S3 (Amazon?s Simple Storage Service), AIR (Adobe Integrated Runtime), MySQL, memcached, version control, backup, etc.
Lessons learned: Think about technology choices, Do a lot with a little, Be kind to your database & Expect anything

Detalhe: Leah Culver é desenvolvedora Java mas escolheu Python para este projeto.

http://s3.amazonaws.com/ppt-download/pownce-lessons-learned4283.pdf

[]s
Luca

Só uma curiosidade, com o Gigaspaces, você pode usufruir dos serviços do S3 - http://developer.amazonwebservices.com/connect/entry.jspa?externalID=916, assim como o Django o permite.

Aliás, excelente review sobre a nova versão do produto - http://www.infoq.com/news/2007/09/gigaspaces

Isso é quase um SEDA luca ? heeh

AH! quanto ao pownce, eu tenho mais 5 invites aqui , quem quiser testar o trem, manda uma mp …

pcalcado:

… a única opção real para IPC é sockets. LAMP segue a excelente filosofia UNIX de pequenos pedaços que se unem para compor um sistema…

… Ah, então Java tem opção apra fazer IPC? Se importa de me dizer qual? Sabe como é, nestes 7 anos eu venho procurando uma opção viável que não inclua JNI nem filas em disco, seria fantástico saber este seu segredo…

O que mais me assustou nessa pesquisa foi realmente o fato de somente um dos 9 sites citados utilizar Java.
Nem imaginava que Perl estava bem assim.
Aqui na facul teve um evento em que tinha um laboratorio de Perl para web, foi o laboratorio de menor numero de participantes. Mas depois dessa noticia, próximo eu to colado.

francislon:

O que mais me assustou nessa pesquisa foi realmente o fato de somente um dos 9 sites citados utilizar Java.
Nem imaginava que Perl estava bem assim.
Aqui na facul teve um evento em que tinha um laboratorio de Perl para web, foi o laboratorio de menor numero de participantes. Mas depois dessa noticia, próximo eu to colado.

Essa pesquisa pra mim me pareceu bem tendenciosa.

Alguem poderia muito bem tbm pegar 9 sites grandes feitos em Java e falar que Java domina amplamente o mercado. O mesmo com .NET e por aí vai…

Existem muuuuitos sites grandes por aí…ateh maiores que esses que foram citados na pesquisa.

Então não se assuste…pra mim essa pesquisa só serviu pra mostrar uma coisa…muita gente acredita que só existe Java e .NET no mundo, e q só essas tecnologias que servem pra fazer grandes sistemas, e isso não é verdade.

fcmartins:

Poderia elaborar, fiquei curioso, você está se referindo a acesso a named pipes?

Sinais, pipes, shared memory… qualquer coisa que se usa há décadas.

Eu nunca tentei usar mas… e a classe sun.misc.Signal ?

Não é Java. Classes dos pacotes proprietarios da Sun não são Java, ela mesmo afirma isso. Não é portavel e tão pouco esperto* abusar de detalhes da implementação.

*Digo esperto para me abster de ser grosseiro. Projetos como o XStream usam o sun.misc.Unsafe, que é uma enorme burrada, já que seu código passa a não funcionar mais em um sandbox.

Bom, então a saida seria alterar a JVM ?

Não, já é possivel usar shm com Java, a interoperabilidade com aplicações nativas não é a melhor coisa do mundo mas funciona. Named/Unix Pipes basta implementá-los com JNI. Quanto a signal io, não sei se vale a pena investir nisso.