O que 9 sites grandes estão usando

Leonardo3001 wrote:
...
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?

This message was edited 1 time. Last update was at 06/10/2007 00:14:58

Leonardo3001 wrote:
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:

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.

Leonardo3001 wrote:
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.

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

Leonardo3001 wrote:
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.

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.

Leonardo3001 wrote:
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.

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

Virtual Machine Man Membro desde: 04/07/2007 18:28:58 Mensagens: 824 Offline

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

Leonardo3001 wrote:
...
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 wrote:

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.

HelloWorld Membro desde: 20/07/2006 11:28:10 Mensagens: 15 Offline

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 "Teria coragem de usar Java?Qual a maior app usando Hibernate que vc já fez/ou viu?" e "a única opção real para IPC é sockets"...

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

zardi wrote:
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.

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

zardi wrote:
- Das pessoas que dizem que Java não é produtivo, quantas usam JEE 5?

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

zardi wrote:
- Daquelas que reclamam da flexibilidade quantas usam Generics?

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

zardi wrote:
- Daquelas que reclamam de qualidade, quantas usam Javadoc corretamente e os excelentes frameworks de testes unitários?

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.

zardi wrote:
- Das que reclamam de integração, quantas usam JMS, WebServices, JBI, JNA, JCA e outros?

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.

zardi wrote:
- Das que reclamam de performance quantas usam uma versão recente da máquina virtual, com incrementos de performance a cada versão?

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.

zardi wrote:
- Dos que falam em segurança, que tal JAAS?

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.

zardi wrote:
- Dos que reclamam de escalabilidade, quantos criam sistemas orientados à mensagens e filas de requisições?

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

zardi wrote:
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?

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

zardi wrote:
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.

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

zardi wrote:
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...

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

zardi wrote:
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 "Teria coragem de usar Java?Qual a maior app usando Hibernate que vc já fez/ou viu?" e "a única opção real para IPC é sockets"...

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

Eu já me preocupei com isso. Sabe o que aprendi? Faça o seu trabalho, as pessoas vão perguntar o que diabos você está fazendo. Se forem minimamente inteligentes vão ao menos se interessar, se não deixa pra lá. Eles serão extintos.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3201 Offline

Leonardo3001 wrote: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 ?

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.

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

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 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.

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.

Notícias, artigos e o maior fórum brasileiro sobre Java