知って欲しいpaasの話
TRANSCRIPT
知って欲しいPaaSの話PaaS勉強会 @jacopen
Kazuto Kusama @jacopen
明日は京都で人類の未来を決める戦い
共に戦いましょう！
普段はCloud Foundry関連の仕事もしています
今回
今回
APIの話はあんまりしません
今回
APIの話はあんまりしません
PaaSの話をします
PaaS勉強会
PaaSなら何でもあり
PaaSに関係しそうなものもあり
なぜ我々はPaaS勉強会をやるのか
PaaSってすごい
Buildpack あらゆる言語やフレームワークが 利用出来るようになる仕組み
Github sync Githubにpushするだけで
自動でHerokuアプリも更新される
PaaSってすごい
Azure App Service (Azure Websites) ものすごくカンタンにWebアプリを構築・運用できる
PaaSってすごい
IBM Bluemix
Pivotal Web Services
NTT Com Cloudn PaaS
Cloud Foundry プラットフォーム間の互換性あり。 どのサービスでも同じツール、 同じ操作で利用出来る
PaaSってすごい
OpenShift V3 Kubernetesを内包し、Dockerが
使えるPaaSに
PaaS、使っていますか？
(質問)
PaaSを触ったことある人
(質問)
PaaSをProduction環境で 使っている人
ない
ある
PaaSを触ったことがある※上のグラフは想像です
使っていない
使っている
PaaSをProductionで使っている※上のグラフは想像です
なぜPaaSを使わないか• ベンダーロックインされたくない
• 意外と手間がかかる
• 自由にやれない
• 漠然とした不安がある
ベンダーロックイン
ベンダーロックイン• ベンダーロックイン（英: vendor lock-in）とは、特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象のこと。
http://ja.wikipedia.org/wiki/ベンダーロックイン
独自技術？
• 一般的な言語やフレームワークを使えるPaaSが殆ど
• Gitのような一般的なツールや、特に支障にならないシンプルなツールを使う場合が殆ど
• これらについてロックインを恐れる必要は無い
コアの PaaS機能
LBaaSDBaaS
3rd Party DevOps
インフラ統合
こういうロックインはある
• 便利に使える機能を活用した結果、ロックインされるという事態は起こりうる
• こういう心地良いロックインまで回避するかどうかは、クリティカル度合いに応じて判断
• 少なくとも、ロックインと言うだけで判断してしまうのは勿体ない！
意外と手間がかかる
意外と手間がかかる• 特にトラブルのとき
• 手元では動くのに・・・
• ログを確認しよう→あれ、どこで見れば？
• PaaSで動かすための修正を入れよう
→ なんか本末転倒じゃね？
• 多くの場合、対処方法はある
• おそらくそれは、これまでのやり方とは違う
• 違うやり方を強いられる
→PaaSから離れてしまう
自由にやれない
自由にやりたいのに・・・• Apacheのチューニングがしたい
• Nginxのチューニングがしたい
• PHPのチューニングがry
• MySQLのチューニry
• LBのチry
• あry
• ある程度の設定ができるサービスもあるが、基本的にはお任せ
• 簡単に使えることと、詳細な設定ができることは、トレードオフの関係
PaaSに対する漠然とした不安
漠然とした不安• 軽く試した限りでは問題無い
• でも、本番に投入して良いものか、不安
• 具体的にどこが悪いっていうわけじゃないんだけど、なんか、こう、ね？
• IaaS･･･何でも自由に触れる
• SaaS･･･そもそも中身を知る必要が無い
• PaaS･･･これまで知っておく必要があった部分が、ブラックボックス化されていて見えない
PaaSのブラックボックス• 基盤の面倒をみなくて良い→サービス側で隠蔽して、面倒をみる
• 逆にこれが、ユーザーに漠然とした不安を抱かせる原因のひとつでもある
これまでのまとめ
PaaSはすごい
でも実際使うと、ちょっと大変
このミスマッチはどこからくるのか
PaaSは
ベストプラクティスを追求する
PaaSは
ベストプラクティスを追求する
そして、それを強制する
• ログの見方が今までと違う・・・⇒そもそもスケールアウトしたら、個別にログチェックは辛いでしょ。標準出力に出せばPaaS側でアグリゲートするよ
• トラブルシュートのやり方が今までとry⇒ん十台のインスタンスにSSHは厳しいでしょ
• 再起動したらローカルストレージが消える･･･ ⇒ローカルストレージ使う設計だとスケールしないでしょ
ベストプラクティスとは• 多くの人にとって、反復され、証明された最も効率の良い結果をもたらす慣行
• 多くの人であって、全ての人ではない
• なので、マッチしない人も確実に存在する⇒こういう人達にも、PaaSは仕組みを強制してしまう
使っていない
使っている
実際、使ってる人達からの評価はすごく高い 上手くマッチすれば幸せになれる
さらに• ベストプラクティスは、常に変わりゆく。
• かつてのベストプラクティスに沿って作られたアプリは、PaaSにフィットしないかもしれない
じゃあ、どうすればいいか
• 新しくアプリを作るときは、PaaSでやれないか試してみる
• よく言われるPaaSのメリット • 構築が楽になる • 運用が楽になる
• もう一つ意識して欲しいメリット • PaaSに載るように設計することで、自然とベストプラクティスに沿ったものになる
• 既存アプリの載せ替えは、試してみてダメならムリする必要はない
• 常に世の中のベストプラクティスを追っていれば、どこかのタイミングでPaaSを活用出来るチャンスがやってくる(はず)
PaaSは
ベストプラクティスを追求する
ベストプラクティスは、常に変わりゆく
• 10年後のPaaSは、今とは全く異なるものになっているはず
• きっとPaaSという言葉自体廃れていると思う
• でも、ベストプラクティスを追求するサービスは、絶対に無くならない。そしてそれは、PaaSから発展した何かだと思う
そのためにも
PaaS勉強会に参加しよう！
次回 PaaS勉強会 #26
4/27(月)
イベントページは近日公開!