JAWS Summit 2日目

JAWS Summit 2日目に行ってきました。（1日目は参加せず）


＜資料＞
サイト
まとめリンク
発表資料(slideshare)

・サイト
JAWS Summit 2012

・facebook
JAWS Summit 2012ファンページ
クラウドデザインパターン (cdp)

・slideshare
クラウドデザインパターン デザインパターン概要編
クラウドデザインパターン コンテンツ配信編(Movable Type on AWS)
クラウドデザインパターン Eコマース編(EC-CUBE on AWS)
クラウドデザインパターン キャンペーンサイト編(WordPress on AWS)

# ベストプラクティス Force.comとAWS連携は、3/4時点では公開されておらず

・Toggetter
2012/03/03 JAWS Summit 2012 PROGRAM Day2 クラウドデザインパターン


＜感想＞
それぞれのセッションの内容は、詳しく記載されているのでそちらを参照。（最近はホント、資料もアップされる勉強会が多くて親切ですね、感謝。）

注）以下でのクラウドは、基本的にPaaS、IaaSを想定しています。

AWSも認知度が上がってきてるかと思えば、まだまだそうではないみたい。
知ってる人は増えてきてるけど、使いこなしてる人はまだまだ少ない。

AWSクラウドをより伝わりやすくしたい。
ということで考え出されたのが、クラウドデザインパターン（CDP）。
クラウドをつかうときの典型的な問題の解決するパターンとのこと。

デブサミでもチラッと聞いたけど、物事を認知させるのには、名前が重要。
アジャイルのように名前と意味が別解釈されたり一人歩きする危険性はあるものの、名前がないと認知しようがない、確かにそうだ。

facebookのクラウドデザインパターンのファンページをいいねすれば、CDPのパターンを記載したwikiが見れる。
（が、一説によるとgoogle検索してもクロールされてるかも、facebookのアカウントを持ってない人はググればでてくるかも）

最近は、こういう勉強会などのfacebookのファンページも多くなってきてるのかな。

CDPは、3/3時点で45パターンあるらしくて、もうすこしで48とか。
ちらっと見てみると、図でイメージがちゃんと示されてるのが多くて、パターン適用時の注意点も書いたりしているものもあって、育っていくとすごく便利だと感じた。
（AWS忍者や、JAWSUGの方々が書いてると思うので、実体験によるものも多く載ってると思います。）


ただし、パターンだけあっても、じゃあそれを自分たちのシステムを作る際にどう適用さればいいの？ということになるが、それをシナリオとして一緒に伝えていくためのものが、今回のセッションの中心だった。
コンテンツ配信、Eコマース、キャンペーンサイトなど。
こういったシステムでどういうスモールスタートをして、どうスケールしていくかが順々に説明されてわかりやすい。


世界を見ると、世界ではクラウドを使いこなしている企業が多く成功している。
日本ではまだまだ弱いという印象（らしい）。
AWSとしてはクラウドを使いこなせるデベロッパーを増やしたい、とのこと。


デザインパターンのプレゼンを見ていて、やっぱりクローズドな環境と、パブリッククラウドはスケールのしやすさが桁違いだなぁと。
QAでもあったけど、スモールスタートから、順々に規模を大きくしていくこともできるし、逆に規模を縮小していくこともできる。
ホント、柔軟(elastic）だなぁと。

コストとしても、個人的にはどんどん（AWSだけでなく）パブリッククラウド自体が流行って、クローズドな環境とのコスト差をどんどん広げていってほしいと思う。

今でも相当あると思うけど、より差がついていくことによって、クローズドオンリーな環境でも検討の機会が出てくると思うので。

もちろん、セキュリティリスクや、既存運用の取り回しなどいろいろな乗り越えるべきハードルがあると思うけど、トップダウンで判断されやすいコストで大きく水を空けられると検討せざるを得なくなる。
（まぁ、世の中にはどうしても外に繋げないシステムもあると思うけど、それはそれで寡占ビジネスなんだろうなぁ）

官公庁や金融機関などの事例はまだ少ないという認識だけど、時間の問題で先に着手できたところがアドバンテージを得れるんじゃないかなと思う。
官公庁や金融機関を扱ってるSIerもアドバンテージを得るためにも提案してほしいなぁ。（SIerとしての旨みは少ないのかもしれないが）

たぶん、いずれはクラウドが来るな、しなきゃなと思っているところはいかに早く手を出していけるかが大事。
クラウドの流れはもう規定路線になってる。
AWSでないにしろ、検討をしてノウハウを溜めていかないとどんどんコスト差がついていく。

後はベンダー（クラウド）ロックインを避けるためにももう少し、クラウドポータビリティが充実してくるといいなぁ。
SQLみたいな共通言語としてAPIが共通化されればいいのに。
（SpringSourceがクラウドポータビリティを目指していたと思うけど、どうなったんでしょう。。）
仮想サーバなどのインフラはある程度共通化できたとしても、運用ノウハウはクラウド固有だから難しいかな。

個人ユースでは去年はEC2、RDS、S3などを利用していたけど、APIももう少し深堀して行きたい。
全部のサービスを使うには手広くなりすぎてると思うので、自分に必要なサービスから入っていて、必要になったら徐々に見ていく感じがいいと思う。