GigaSpaces(サイト・英語)のNati Shalom氏(ブログ・英語)は、最近何故ほとんどの大規模なwebサイトがJavaで構築されていないのかという疑問を投げかけている(source)。この疑問はJava Communityで大変大きな議論を引き起こし、InfoQはそれに関する見解を探るための機会を設けた。
彼の掲載記事の中で、Shalom氏はたくさんのサイトがLAMP(Linux, Apache, MySQL, PHP/Perl)を使用しており、そしてその中のいくつかのものはGoogleのGFSか、もしくはメモリキャッシュ等のキャッシュのようなカスタムファイルシステムを開発している。Shalomは大規模なwebアプリケーションと大規模な金融機関向けアプリケーションの両方のために開発されたスケーラビリティソリューションの類似点を述べている。
下記はData層で見られるものである。
- メモリソースの有効性を活用するためにキャッシングレイヤーを追加しインターオペラビリティオーバーヘッドを減少させる。
- データベース中心のアプローチからパーティショニング（別名shards)への移行。
ビジネスロジック層上では、
- アプリケーション層に平行化セマンティックを追加（例：MapReduce)
- リニアスケーラビリティを実行するためのスケールアウトアプリケーションへの移行
- 従来の2段階コミットと処理プロセス用のXAからの撤退（Lessons from Pat Helland: Life Beyond Distributed Transactions参照(source))
Shalom氏はこれらの類似したソリューションが異なるアプリケーションをどのようにして所有することができるのか説明した。Todd Hoff氏はShalom氏が述べた、可能性のある理由の一つを提示した(source)。"LAMPスタックは協力で自由自在であり、一方Javaは中核というよりもむしろ補足的なコンポーネントとして使われるのです。"
他には下記のような見解があった。
- Justin Sher氏(ブログ・英語)はeBay、GMail、Amazon、hi5.comとGoogle AdWordsがJava上で構築されていることをすばやく指摘した(source)。
- Shance Isbell氏(ブログ・英語)は典型的なwebデベロッパは典型的なJavaデベロッパよりもソーシャルネットワーキングサイトと目を楽しませるものに興味を持っているのではないかという、文化的な違い(source)を指摘した。また金融機関はweb会社がソフトウェアで大規模化するのに対して、より大きな予算があるのでハードウェアで大規模化する傾向があるとコメントした(source)。
- もう一人は金融機関向けアプリケーション内でのJavaソリューションの普及は、大規模なJava EEベンダーと金融機関のパートナーシップ(source)に関係していることを提示した。
- 数年に渡る金融機関との経験を持ったAngelo Andreetto氏(サイト・英語)は、可能性のあるリスクへの保守的なアプローチは不均一のソフトウェア上のJavaベースのソリューションのセレクションに繋がると考えている(source)。
- 他の人は金融機関のダウンタイムの影響は一般的にweb会社のためのものより大きいとコメントした(source)。
- George Coller氏はその疑問は間違って提示されており、それはなぜJava EEがもっと使われていないのかという疑問であるべきだ(source)と述べている。
GigaSpacesのMickey Ohayon氏はもっと詳細な返答をしている。
技術的な観点において、
経済的な観点において、
- JEEがより複雑な一方PHP/Perlにおける開発はとても早くシンプルである。
- 歴史的に考えて、ホスティングサービスとデベロッパたちがより入手可能となっている。
- JEEをインフラと考えると、LAMPはより安定したインフラであり一般的である。
- JEEは時々webシステムにとってはやりすぎなアプリケーションサーバを必要とする。
- 軽量なweb言語(PHP/Perl)は短期開発での変更に対してより柔軟である（Non-MVCを基盤とした貧相なアーキテクチャの一部として。もちろん長い目でみると変更のコストは激的に高いが）。
- Javaアプリケーションのデプロイメントとテストは遥かに遅く比較的強固なマシーンを必要とする。
- JEEデベロッパはPHP/Perlよりもはるかに高額である。
- ラーニングカーブとマーケットする時間は既に有効ではない。
- JEEアプリケーションサーバのホスティングはより高額である。
NokiaのJilles Van Gurp氏(サイト・英語)は、Java EEはエンタープライズドメインのために最適化されていて、またそれは大規模な消費者向けのwebサイトとは異なるニーズを備えていると述べた。
これらのwebサイトは比較的シンプルなデータストラクチャである。処理や持続レイヤーのようなものである（mySQL+非処理&ACIDバックエンドはほとんどの場合において十分適している。）。大変強固なwebサービス用の実質的な条件はないのである。基本的にJ2EEが大変適しているものである消費者向けのwebサイトの実装は、大体がやり過ぎなのである。手の込んだIDEは必要ないのである。それは超フレキシブルなメッセージバスや、非常に複雑な処理論理等である。
代わりに焦点は極端なスケーラビリティ当てられている。メモリ使用・CPU利用・キャッシング等である。これらはSquid、Apache、分配 Linuxファイルシステムのようなよくあるコンポーネントを伴って表現される。また、それらはJavaコンポーネントで表現することも可能だが、それらを統 合するのにはJ2EEの利用が条件となるのである。これらは求人市場において人材が欠落しているためと、このような人々が最終的にエンタープライズ系の仕事で非常に高い給料を得るため、採用するのは簡単ではないのである。
Van Gurp氏は、またJavaは将来的な見込みが明るいと信じている。
最後に、私は全てが変化していると思うのです。RubyかもしくはPHPのJava実装は、PHPかRailsアプリケーションに良質なセキュリティ、パフォーマンス、スケーラビリティと管理性の増加をもたらすのです。もしあなたがこれらのシステムの大規模なデプロイメントを行っているならば、これを試さないのは損なのです。これはまだPHPとRubyデベロッパの間であまり知られておらず、またたくさんの人がハードウェアに投資するのを好んでいるがパフォーマンスには気をかけていないのと同じです。しかしながら一回Javaア プリケーション上においてPHPかもしくはRuby上でのデプロイに移行してしまうと、彼らのアプリケーションを更に強化する付加的なコンポーネントの世界があることを発見するのです。ほぼ間違いなくGoogleのweb開発ツールチェーン（部分的にオープンソース）は極端なラージスケールと迅速なプロトタイピングのweb開発において、まさに最先端を担っているのです。そしてwebデベロッパの視点からアプリケーションロジックの記述は100%Java内で行われるのです。私の知っている限りでは、Googleはweb UIレイヤーの中にPHPの大規模なデプロイメントか、もしくは似たようなアーキテクチャを所有していません（もしこれが本当でないなら証明して見せて欲しいです）。
このディベートが拡大するのを見て、Shalom氏はMichael O'Keef'氏の意見(source)に対する同意に関して説明(source)した。また、それは上記の見解にまつわるものである。Shalom氏はまた市場においてRails上の SpringやCauchoのJavaベースのPHP実装のようなツールを伴う移行トレンドがあり、またスケーラブルなサイトの開発という挑戦はLAMPとJavaを将来的に近づけるということを言及している。
あなたはどう思いますか？