Salesforce, Google App Engineとユーザコードのホスティング
こういう方が書いてくれると、僕も書き易い。今までは論じるにはあまりにマイナーすぎた。
salesforceのTour de Force Tokyo(-ツール・ド・フォース-)に行ってきました。
IBMには悪いですが、Notesの正統な後継者の一番手はsalesforceかもしれない、という思い — ありえるえりあ
* http://www.salesforce.com/jp/events/crm-events/2008-07-03.jsp
まず、最初におことわりしておくと、僕は去年までsalesforce.com Japanに在籍していました。で、今の仕事も多少関わってたりします。その上で以下お読みください。
「ページ」相当の機能は、facebookも同様の仕組みを提供しています(FBML)。これはこれで両者とも凄いのですが、salesforceが行っちゃったなと思うのがApexコードです。これは、サーバで動作するビジネスロジック層(上に書いたように、salesforceは「コントローラ」と呼んでいました)をユーザに自由に書かせる機能です(正確に用語を使うとApexはそのための言語)。これも、仕組みだけなら誰でも作れます。ブラウザから perlのコードをポストさせて、CGIとして実行させる仕組みと言えば、実現の簡単さがイメージできるはずです。しかし、普通はできません。現実の様々な障害(セキュリティやパフォーマンス)が多すぎるからです。しかし、salesforceはやってしまいました(Google App Engineよりずっと先に実現)。
IBMには悪いですが、Notesの正統な後継者の一番手はsalesforceかもしれない、という思い — ありえるえりあ
SalesforceのApexについて。これは確かに頑張った。その凄さに気づいている人が増えてきたことは、もっとsalesforceのプラットフォーム上での開発者を増やしたいと考えている彼らにとってはなかなか喜ばしいことではないだろうか。
でも、GAEと比較しては、多少持ち上げ過ぎかも。ApexコードはVM on VMだ。つまりJava VMレベルでユーザのコード動作の制限（Governor Limitという。Google App Engine流に言えばQuota）を実装した形になる。一方、Google App Engineでは（一部ライブラリの制限はあれ）pythonがそのまま動く。何かのVMで動いてるという話は聞いていないので、CPUなどのQuotaの実現はOSのスケジューラレベルでやっているのに違いないとおもう。こういった実装は、それが可能だとしてもなかなかサービスまで踏み切れるものではない。Googleの土壌のみがそれを可能にしたのだろうかなと感じる。
Googleに１年以上も先んじてアプリケーションサーバ・サービスを一般に開放したのは、評価すべきだと思うが、惜しむらくは、それを実現するために言語的にも全く独自の言語*1を持ち出してしまったことだ。これで随分の開発者が二の足を踏んだに違いない。個人的には、同じJVM上の実行系でもRhinoでサーバサイドJavaScriptが動いてくれることを期待したものだったけれども、いろいろな事情からそうはならなかったようだ。ただこれからは、「Governor Limitを実現するために独自言語（ある意味フレームワーク）が必要」といういままで通じていた言い訳は、GAEの存在によってあまり使えなくなるだろう。
ただ、別に独自言語で十分じゃない？、という見方もできる。いままでどれだけ企業向けプラットフォームで独自言語が生き延びてきたかをみればよい。ABAPしかりPL/SQLしかり。ロジックカスタマイズに関する需要があり、その習得に投資する層がいる限り致命的にならないだろう。ただ単に、Googleではない一企業が（技術の優劣という意味でなく）いろいろな指標を鑑みて一番彼らにとってやりやすい道を選んだだけだ。まあだからこそ、成功する／しないの話ではなく、惜しかったな、と、今でも思うのだけれども。
Apexを出すときに一番彼らが気にしていたことは、ユーザコードの負荷のために収入源であるCRMサービスの方が止まってしまっては元も子もない、ということだし、それを徹底的に避けた上でしか、革新を打ち出すということはあり得なかった。そこは今からのプラットフォームであるGAEと単純に比較したらかわいそうではある。
ちなみにいまsalesforce USのDevに入ってきている人は、いままでJEEをやっていた連中が多くなっている（とくにBEA出身とか）。なので必然的に、プラットフォーム自体それを意識したアーキテクチャになっている。ApexがJVM上に実装されたのも、Visualforceのページをつくるときに使うタグがほとんどJSF（というかそもそもプラットフォームの内部実装がJSF）だったりするのも、それ故だと思う。
あ、でもningってユーザコードホスティングという意味では両者よりも実はもっと先じゃないかしら？彼らはスケーラビリティをちゃんとクリアしていたのだろうか。その上でビジネス的に割にあわないからSNSサービスに主軸を置いたのか、それとも全然スケールしなくてサーバ投資がかさんで細々とPHPホスティングを終息させていったのか、どっちなのか、それが知りたい。
