GAE/Jは破壊的イノベーション

クラウドはバズワード的で何がいいのか良くわからないという人も多いことでしょう。その感覚は正しい。クラウドという言葉だけだと、意味が広すぎて、焦点がぼける。
例えば、同じように思われているAmazonのEC2とGoogle App Engineは、まったく違うものです。

Amazonのほうは持続的イノベーション、Googleのほうは破壊的イノベーション。
EC2は、過去の技術をそのまま使える(汎用的な仮想化サービス)ので、連続的な技術なのです。
それに対してGAE/Jは、できることをかなり制限して、しかもRDBMSをすててBigTableにのりかえるっていう非連続ぶり。
どっちがいいというものではありません。

クリステンセンのイノベーションのジレンマ-技術革新が巨大企業を滅ぼすときを読むと、マーケットリーダーである優良企業が、なぜ、ずっと成長を続けることができずに、破壊的イノベーションに滅ぼされてしまうのかが説明されています。

イノベーションのジレンマ 増補改訂版 (Harvard Business School Press)

IT業界にいる人ならぜひ読んで欲しいと思う本です。

大型コンピュータのIBMは、ミニコンピュータのDECに倒され、
DECは、ワークステーションのSunに倒され、
Sunは、Personal PCのIBMに倒され(まだ倒れてないけど)、
IBMは、注文直販のDELLに倒され、
DELLもまた、Netbookという新たな挑戦者と現在戦っています。

マーケットリーダであり、顧客のニーズにこたえ、ニーズにあったプロダクトを作るために投資をする。どこから見ても、王道を歩んでいる優良企業が、破壊的イノベーションによって、滅ぼされるのがイノベーションのジレンマなのです。

破壊的イノベーションの特徴は、それが出てきたときには、機能的には既存のプロダクトに劣ることが多いということです。一部の機能が劣る代わりに、別のメリット(例えばコストが安いとか)を提供できる。
機能的には既存のプロダクトに劣っているので、マーケットリーダーである優良企業は、その技術を軽視する。でも、最初劣っていた技術も急速に改善されて、気付いたときには、その技術に負けてしまうのです。

破壊的イノベーションは、出てきたときには、成功するかどうかは誰もわかりません。ただし、成功したときには、先に取り組んでいた企業が先行者利益を上げられることが、わかっています。まぁ、一種のギャンブルです。
私はギャンブルは好きではありませんが、不況のときにはありだと思う。普通にやっていれば、失敗する可能性が高いわけだから、どうせなら破壊的イノベーションというギャンブルに挑戦し、失敗したらまぁしょうがない(普通にやっていても失敗する可能性が高いのだから)、成功すれば、不況を乗り越えていける。

GAE/Jは、破壊的イノベーションです。そして、成功するかどうかは誰もわからない。でも、不況の時にはチャレンジしてみていいと思う。
GAE/Jという破壊的イノベーションが仮に成功したとすると、既存の成功している人たち(イノベーションのジレンマでいう優良企業)は、倒されることになる。

BigTableが成功すると、一番打撃を受けるのは、オラクルでしょう。ミッションクリティカルでハイエンドな案件以外はなくなる可能性がある。

JBossも苦しい。看板プロダクトであるJBoss ASとHibernateが使えなくなってしまうのだから。
Hibernateは、BigTable用のlow level APIをJDBC Driverでラップし、BigTable用のdialectを作って、かつ、GAEの制限を回避するようにコードを書き直せば、何とか動くと思うけど、BigTableは、機能が低いので、Hibernateのもつ高機能な部分をほとんどいかすことができない。そうすると機能は低いけど複雑だということになり余り意味がない。

SpringSourceは、既存のSpring portfolio(Containerを中心にしたプロダクト群)は、無理にGAE/Jに対応させる必要はなく、既存の顧客に提供し続けるのがいいと思う。GAE/J上では、Annotation drivenなcomponent scanが使えないので、昔のようにいちいち設定ファイルを書く必要がある。これはちょっとめんどくさい。
前にも書いたけど、GAE/Jはいろいろ制限があるので、高度な機能(DIとかAOP)は、使い方が制限され、動かない部分が出てくる。前はできたけど、今はできないというのは嵌りやすいポイントだから、できる限り避けたほうがいい。
そういう理由があって、既存のSpringのプロダクトをGAE/J上で使うのは余りお勧めできない。実際、GAE/JのMLを見てると嵌っている人が大勢いる。
GrailsからSpringとHibernateを削って、GAE/Jに最適化したフレームワークにするというのは、いい考えだと思う。
SpringSourceからみると、GAE/Jは、失敗したほうが多分いいはず。これまでのプロダクト郡をそのままいかせるからね。ただ、せっかく、Groovy(Grails)を持っているわけだから、GAE/Jが成功したときの保険のために、Groovyの部分を限定的にGAE/Jに対応させるというのは、やってもいいと思う。

JJUGのイベントでは、このようなビジネス的な話ももう少し詳しく話したいと思います。もちろん、テクニカルな話もね。Slim3のデモもやるよ。タイプセーフな流れるようなインターフェースでBigTableにアクセスするデモももちろんやるよ。もうほとんどできているので。
aptを使って、Javaのソースコードをセーブ(コンパイル)した瞬間に、メタデータ用のクラスが自動生成される様子は、一番の見所。今後のフレームワークでは、aptの利用がはやるはず。
http://www.java-users.jp/contents/events/ccc2009spring/index.html

JJUGのイベントのタイムテーブルを改めて見直すと、クラウドのセッション多すぎ。
http://www.java-users.jp/contents/events/ccc2009spring/timetable.html

BOFを除くと、14セッション中のうち8セッションがクラウドがらみって。。。
名前をクラウドカンファレンスに変えるべきだよね。

追記:GAE/PythonとGAE/Javaもバックエンドの技術は同じでも、ビジネス的にはまったく違うものですよ。それは、PythonとJavaのどちらが言語的に優れているというよりも、ビジネス的な規模がまったく違うということです。
後、EC2でオラクルのVMを使えるようにするという話は出ていますが、GAE/Jでオラクルを使えるようにする話はまったくきいたことがないですよ。私の知ってる限りは。
そもそも、オラクルをのせるのなら、あそこまで制限を厳しくする必要もないし、EC2と何も変わらないから、単なる後発のサービスに過ぎなくなってしまうでしょう。