Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2009-04-19

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

クラウドバズワード的で何がいいのか良くわからないという人も多いことでしょう。その感覚は正しい。クラウドという言葉だけだと、意味が広すぎて、焦点がぼける。

例えば、同じように思われているAmazonのEC2とGoogle App Engineは、まったく違うものです。


Amazonのほうは持続的イノベーションGoogleのほうは破壊イノベーション

EC2は、過去技術をそのまま使える(汎用的な仮想化サービス)ので、連続的な技術なのです。

それに対してGAE/Jは、できることをかなり制限して、しかもRDBMSをすててBigTableにのりかえるっていう非連続ぶり。

どっちがいいというものではありません。


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

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


大型コンピュータIBMは、ミニコンピュータのDECに倒され、

DECは、ワークステーションSunに倒され、

Sunは、Personal PCIBMに倒され(まだ倒れてないけど)、

IBMは、注文直販のDELLに倒され、

DELLもまた、Netbookという新たな挑戦者現在戦っています。


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


破壊イノベーションの特徴は、それが出てきたときには、機能的には既存のプロダクトに劣ることが多いということです。一部の機能が劣る代わりに、別のメリット(例えばコストが安いとか)を提供できる。

機能的には既存のプロダクトに劣っているので、マーケットリーダーである優良企業は、その技術を軽視する。でも、最初劣っていた技術も急速に改善されて、気付いたときには、その技術に負けてしまうのです。


破壊イノベーションは、出てきたときには、成功するかどうかは誰もわかりません。ただし、成功したときには、先に取り組んでいた企業先行者利益を上げられることが、わかっています。まぁ、一種のギャンブルです。

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


GAE/Jは、破壊イノベーションです。そして、成功するかどうかは誰もわからない。でも、不況の時にはチャレンジしてみていいと思う。

GAE/Jという破壊イノベーションが仮に成功したとすると、既存の成功している人たち(イノベーションのジレンマでいう優良企業)は、倒されることになる。


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


JBossも苦しい。看板プロダクトであるJBoss ASHibernateが使えなくなってしまうのだから。

Hibernateは、BigTable用のlow level APIJDBC 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からSpringHibernateを削って、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/PythonGAE/Javaバックエンド技術は同じでも、ビジネス的にはまったく違うものですよ。それは、PythonJavaのどちらが言語的に優れているというよりも、ビジネス的な規模がまったく違うということです。

後、EC2でオラクルVMを使えるようにするという話は出ていますが、GAE/Jでオラクルを使えるようにする話はまったくきいたことがないですよ。私の知ってる限りは。

そもそも、オラクルをのせるのなら、あそこまで制限を厳しくする必要もないし、EC2と何も変わらないから、単なる後発のサービスに過ぎなくなってしまうでしょう。

andalusiaandalusia 2009/04/20 04:24 > GAE/PythonとGAE/Javaもバックエンドの技術は同じでも、ビジネス的にはまったく違うものですよ。
>それは、PythonとJavaのどちらが言語的に優れているというよりも、ビジネス的な規模がまったく違うということです。

「Key/Value型DB」と「RDB」だって、ビジネス的規模が全く違うものですよね。
個人的には、Python が流行るという形の破壊的イノベーションが見たかったというだけです。

もちろん Slim3 も応援していますので、がんばってください。

hiuchidahiuchida 2009/04/20 09:21 EC2単体とGAE/Javaと比べたらその通りだと思いますが、既存のRDB+J2EEアプリを捨てて、Amazon SimpleDB+S3を使ったJ2EEアプリに書き換えてEC2で動かしたらGAEと似たようなもの(本来のクラウド)だと思ってます。ただ、Amazonの方はGAEと違い強制力はないので、既存のアプリをそのまま動かすというのが大部分かもしれませんが・・。

一方で、EC2で既存アプリを公開すればクラウドで、自前のサーバーで既存アプリを公開すれば従来のASP、のような感覚の人もいますね。アプリ分散は考えているけど、DB分散は考えていないみたいな。やれやれ。

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証