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
[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.
…
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.[/quote]
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
[quote=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.[/quote]
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:
-
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.
-
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 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.
-
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.
[quote=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.[/quote]
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.
[quote=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.[/quote]
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:
-
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
-
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?
[quote=ASOBrasil][quote=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.[/quote]
Não entendi essa parte, eles estão sacrificando a segurança usando Linux e Apache? [/quote]
Ele quiz dizer seguranca na aplicacao, nao estava se referinco ao Linux ou ao Apache serem “inseguros”.
[quote=pcalcado][/quote]
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