Google App Engineは敷居が高いのがメリット？セールスフォースは開発生産性が高いが制限にも苦しむ〜クラウドごった煮パネルディスカッション（PaaS編前編） − Publickey（情報元のブックマーク数）

Windows Azureユーザ会（JAZ）のメンバーが中心となったクラウドイベントのディスカッションメモが出ていますが、面白い。

国内にあるクラウドのユーザーコミュニティに集まってもらい、ディスカッションを行う日本で初めてのイベント「クラウドごった煮」が、昨年末12月11日に開催されました。Windows Azureのユーザー会（Japan Windows Azure User Group、JAZ）の人たちが中心になり、つてをたどってほかのクラウドのユーザー会などに呼びかけて実現したものです。
前回のIaaS編に続き、この記事ではPaaS（Platform as a Service）の機能を提供する3つのクラウド、Google App Engine（GAE）、Heroku、Salesforce.com（SFDC）のコミュニティ代表3人のパネルディスカッションの内容を記事にして紹介しましょう。
Google App Engineは敷居が高いのがメリット？セールスフォースは開発生産性が高いが制限にも苦しむ～クラウドごった煮パネルディスカッション（PaaS編前編）－ Publickey

敷居が高いから付加価値が上がって、企業としてやる意味が出る。

ひが（GAE）　Google App Engine（以下App Engine）のいいところは、素人お断りみたいな、そういうところがあるところが非常に気に入ってます。一般的には「とっつきやすいです」というのが売りになると思うのですが、App Engineは敷居が高いです。
ただし、これが重要なんですが、なぜ私がこれを「いいところ」にしたかというと、われわれがビジネスをやるうえにおいて大事なのは差別化なんです。ほかの人が「これはできない」ということをできる、その付加価値を提供できるときにお金がもらえる。
敷居が低いといろんな人が参入してきてマーケットが広がるという意味はありますが、差別化してお金を儲けるという意味では敷居が高いというのが大事だったりします。
Google App Engineは敷居が高いのがメリット？セールスフォースは開発生産性が高いが制限にも苦しむ～クラウドごった煮パネルディスカッション（PaaS編前編）－ Publickey

ソーシャルアプリでは、５秒が普通

いろいろこう、SQLが使えないとか、レスポンスは30秒以内とか、一般には不便に感じるところはあるのだけれど、ソーシャル系のアプリケーションなら5秒以内とかにリクエストを処理しなければいけないから30秒は楽勝だし、リレーショナルデータベースではユーザーが増えていくと更新系が重くなって、たくさんデータベースを並べて解決するといったことをがんばらなくてはいけないのですが、App Engineはそういうのを自動化してくれるので、ソーシャル系ではそんなに不満に思ってはいません。
Google App Engineは敷居が高いのがメリット？セールスフォースは開発生産性が高いが制限にも苦しむ～クラウドごった煮パネルディスカッション（PaaS編前編）－ Publickey

ここ、僕もクラウドを検討している人に言ってるけど、なかなか難しいですよね。

ただ先ほども言ったように、スケールアウトするアプリケーションをどう開発するか、ということを理解するには3カ月くらいかかるのではないですかね。
Google App Engineは敷居が高いのがメリット？セールスフォースは開発生産性が高いが制限にも苦しむ～クラウドごった煮パネルディスカッション（PaaS編前編）－ Publickey

PaaSはプラットフォームに合わせて開発が必要

新野　PaaSの場合は言語とデータベースが決まっていてほとんど選択の余地はありませんね。App Engineなら言語はJava/PythonでストレージはBigTableだったりと。それぞれのクラウドが採用している言語とストレージについて、いい点、悪い点を教えてください。
どのクラウドが受託に向いているか？ Javaに未来はない、インフラ担当にも未来はないのか～クラウドごった煮パネルディスカッション（PaaS編後編）－ Publickey

スケールアウトする技術は技術者が身につけておくべき技術か・・・

ひが　スケールアウトするキーバリュー型データストアの技術は、この5年くらいの期間で考えると技術者としては身につけておかなければならない技術の1つだと思っています。いまくらいのタイミングできっちりキーバリュー型データストアに取り組んで、自分なりに「こうすればできる、良さを活かせる」というところまでやっていかなければ、みんなと同じになって技術者としての差別化ができなくなってしまいます。
どのクラウドが受託に向いているか？ Javaに未来はない、インフラ担当にも未来はないのか～クラウドごった煮パネルディスカッション（PaaS編後編）－ Publickey

多分インフラ担当ではなく、システム管理担当って感じになるのかな、Quotaを超えていないか、不要・無駄な処理がないか、請求金額は正しいか、システムは正しく動いているか、そういうことを担当する人が必要だと思いますよ。

会場から　私はSIerでインフラ担当をやっているのですが、PaaSを使っていて、インフラ担当って必要ですか？
新野　これは面白い質問ですね。ちなみにいま質問された方、ちょっと教えていただきたいのですが、インフラ担当とは具体的にはどんな仕事をしていますか？
会場から　私はどちらかというとアプリケーションとインフラのあいだの、どちらにも属さないところを担当していて、トラブルシュートとかデータベースのチューンとか、そういうことをしています。
新野　なるほど。といったインフラ担当の人が、PaaSの中で必要とされるでしょうか？いかがですか？
ひが答えるまでもなく、いらないと思います（笑）
小倉　私もひがさんとまったく同じで、弊社でも私が一日一回管理画面をちょろっと見て、あとはデプロイのときにちょっとコマンド打つくらいです。
今岡　私も同じく、いらないと思います（笑）
新野　簡潔なお答えをみなさんありがとうございます。
僕は司会なのですが、ちょっと付け加えさせていただくと、パネリスト3人のお答えは、PaaSで完結している場合にはインフラ担当はまったくいらないというもので、私もそう思います。
どのクラウドが受託に向いているか？ Javaに未来はない、インフラ担当にも未来はないのか～クラウドごった煮パネルディスカッション（PaaS編後編）－ Publickey