Ruby、JavaScript、Clojureに続いて4番目の言語対応

HerokuがJava対応、過去の煩雑さとの決別うたう

2011/08/26

　Ruby向けPaaSとして成長してきたセールスフォース傘下のクラウドベンダ、Herokuは2011年8月26日、Java言語のパブリック・ベータサービス開始を発表した。7月にはNode.js（JavaScript）とClojure（JVM上のLisp方言）のサポートも開始しているため、Java言語は4番目の対応となる。

　Java対応は、これまで同様に「Cedar」（英語でヒマラヤ杉）と同社が呼ぶバージョンのソフトウェアスタックを用いる。現在のCedarのスペックは、

Ubuntu Server 10.04 (Lucid Lynx)
Ruby: MRI 1.9.2
Bundler: 1.1pre5
Node.js: 0.4.7
NPM: 1.0.6
JVM: OpenJDK 6

となっている。ほかのHeroku対応言語と同様に、分散バージョン管理システムのGitを使ったデプロイが可能。ロギングやスケーリングについても、ほかの言語と同様の手法が使えるという。依存関係は、デプロイ時にHeroku側でMavenを使って自動解決される。アプリケーションサーバには、Google App Engineでも使われているオープンソースのJettyを使っているという。

　個別サーバの管理が不要で、アプリケーションを直接デプロイできるPaaSの分野では、Herokuに限らず複数言語対応がトレンドとなっている。Herokuでは、ClojureやJavaのサポートで明らかなように、すでに、JRubyやScalaといったほかのJVM言語をデプロイすることも可能だ。JRubyやScala対応への利用者からの要望は大きく、今回のアナウンスブログの中でHerokuは、こうしたJVM言語の公式サポートの可能性を示唆している。

　Java採用の理由としてHerokuでは、高速でメモリリークなどの少ないJVMの信頼性、600万人とも言われる開発者層の厚み、ほとんど完璧に近くなったプラットフォーム間の互換性の3点を挙げている。

なぜJ2EEがJava開発を脱線させたのか

　こうした強みがある一方、ブログの中でHerokuはJ2EEが開発のプロセスを複雑なものとしたことで、Javaを脱線させた（derailed）と指摘している。J2EEはエンタープライズ市場でのJavaのプレゼンスを圧倒的なものとした一方で、デプロイなどの面で複雑さが増したという。

　J2EEによる開発では、8つの役割のチームもしくは開発メンバーが規定されているなど、工場の組み立てラインのようにコードを流れ作業で構築していくモデルが示さているという。

　ところが、現代的なアプリケーション開発では、すでに「開発→パッケージング→配布→インストール→デプロイ」という従来の開発モデルに合わなくなってイピーダンスミスマッチが存在しているという。SaaSでは、比較的少人数の開発チームが直接デプロイし、プロダクション環境からのフィードバックをダイレクトに受ける開発モデルを採用することが多いからだ。

　J2EEも、ブランディングを変えたり、分散アプリケーションなど重厚なモデルが不要なケースで軽量な開発が行えるよう変化してきているが、Herokuは「それはすでに手遅れで、変化も微々たるもの。Javaを取り巻く環境は、いまやクラウドアプリケーションプラットフォームによる破壊的イノベーションの機が熟した」としている。

　多言語対応を進めるに当たってHerokuは、各言語コミュニティが互いに学べることが多いだろうと指摘している。例えば、RubyのGemやBundler、PythonのPipなどはJavaコミュニティが蓄積した経験やツールに負うところが大きいという。逆に、すでにJavaコミュニティは、Play!やGrailsといったモダンなWebアプリケーション開発フレームワークの登場という形で、RubyやPythonといった軽量言語コミュニティからアイデアを取り入れている。今後、Herokuのようなプラットフォームで多言語環境ができることによってJava開発者らは、Webフレームワークばかりでなく、デプロイやスケーリングについてのベスト・プラクティスについても学ぶ機会が得られることになろだろうとしている。