クラウドという言葉を特に良く聞くようになってきた今日この頃です。ユニマガも特集してましたね。Google Apps Engineも晴れて待望のJava対応になりました。ちょっとまとめますと：
- ビューはJSPを使うらしい
- servletも使える。基本的にJava eeのWAR部分。ただしwarをそのままデプロイできるわけではない（フォルダ構成は似ている）。
- データベース周りは、JPA/JDOなどを利用。DataNucleus Access Platformという、とあるJPAエンジン（ORマッピングフレームワーク）を使うのですが、この人は「BigTable用プラグイン」として下位層をGoogleのBigTableを使える。つまりJPQLをつかうんですかね。
- トランザクション周りは謎。
- 分散ハッシュとしてMemcacheServiceというのがある。memcachedプロトコルとの関係は不明。
興味があるのが、従来のエンタープライズシステム開発がこういうクラウド環境上に移行できるのかどうか。例えば、金融処理とか受発注処理とかが。いや、いままでもクラウド環境はあったのですが、単に仮想環境だったりして、イメージがわかなかった。GoogleのはこれはJavaベースで（JRuby とかも動くらしい）あり、がぜん現実味が増してくるってものじゃないですか。
もし、従来悩ませてきた性能問題を、マシンパワー任せ（金任せ）でスケーラブルに回避しきれるなら、インハウスでDBMSを持つ必然性が減っていく（セキュリティや情報を外に出すことの問題はあるにせよ）ので、それと比較すべきコストの問題（というよりトータル所有コストの問題）が我々の開発をクラウドに乗せていく必然性と可能性を徐々に高めていくでしょう。
その可能性に関してポイントとなるのが、クラウドのブームの中で広まっているBASE(basically available, soft state, eventually consistent)という考えかた。従来のACIDにおけるトランザクションという単位で宇宙の状態を確定させたい・させよう、という便宜上の考えに対して生まれてきた、異なる考え方です。
「トランザクションが終わっていれば状態は確定する」というのは開発者にとっては理解しやすいのですが、性能がスケールしない、マシン数の増大によってスケールさせられないという脱却不能な問題があります。
これに対して、BASEは、トランザクションというでかい祖粒度の（利便性の高いわかりやすい）単位ではなく、多数の条件の複合体として、状態の確定条件を単純には決めない。最終的には確定しないわけには行かないんだけど、それを可能な限り（便宜上必要なだけ）遅らせるようなものかと理解しています。トランザクションの様に、一歩一歩確定させながら進めるということをあきらめるのです。
変に例えると、ACIDが古典物理学的であるとするなら、BASEは量子論的である気がする。
将来のエンタープライズクラウド上で整合性保証のために用いられるプログラミング技術は、ACID より遥かに理解しにくい、複雑なものになるでしょう。いままでトランザクションモニタという黒子がやってきた処理のパンドラの箱が開いて、平均的なプログラマがそれをやらなければならないようになるのは悪夢です。ある種のパラダイムシフトが必要なんじゃあないでしょうか。
ただ、そもそも「エンタープライズシステムをクラウド環境にのっけるの？」という話はあるでしょう。それに対抗できる言説はただ金つまりコストの問題をもとにしたものでしょう。今後未来永劫、毎年毎年マシンの維持管理及びリプレース費チューニング費に何千万何億やっぱり払うのかどうかです。それはたぶん、許されない。（現状では単独の経済性の問題として必ずしもクラウド環境の方が安いとも言えないみたいですけど）。
あと、スケーラビリティの問題、つまりユーザ数が数百倍になったりデータ数が数百倍になったときに、それを突破的に解決できる望みは、今のところクラウドさんちのところにしかないのです。インターネットサービスほどでは無いにせよ、僕らがイントラシステムなどを開発するときに直面する技術的（かつ致命的な）問題の大きな割合を性能問題が占めることを考えると、その可能性を無碍に切り捨てるというわけにはいかないし、あと最低１０年はこの業界にいるつもりがあるエンジニアとしては見ておかないわけにはいかない。
参考リンク。
