O que 9 sites grandes estão usando

Assuntos Gerais
#41

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 :wink:

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.

[quote=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”…[/quote]

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:

#42

[quote=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.
[/quote]

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 ?

#43

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

[quote]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.[/quote]
Eu no caso, me referia realmente a qtd de acessos.Tenho um projetinho pessoal super simples(tá, tem uma parte de cálculo que não é dana simples, mas é “offescalabilidade”, interno ao sistema), mas é algo que ainda não existe, e o meu medo seria justamente: “E se o troço cresce, eu choro?” Por isso a pergunta com o Hiebrnate.

#44

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!

#45

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.

#46

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.

#47

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.

#48

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

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.

#49

Olá

[quote=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.[/quote]

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

#50

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 :slight_smile:

#51

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

#52

[quote=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…[/quote]
Poderia elaborar, fiquei curioso, você está se referindo a acesso a named pipes?

#53

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.

#54

[quote=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.[/quote]

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.

#55

[quote=fcmartins]
Poderia elaborar, fiquei curioso, você está se referindo a acesso a named pipes?[/quote]

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

#56

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

#57

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.

#58

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

#59

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.

#60