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

おもしろい考察。
GAE/Jは破壊的イノベーション - ひがやすを blog

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に対応させるというのは、やってもいいと思う。