API Meetup Tokyo #7 で発表した資料です

1. 知って欲しいPaaSの話
PaaS勉強会 @jacopen

2. Kazuto Kusama
@jacopen

4. 明日は京都で人類の未来を決める戦い

5. 共に戦いましょう！

6. 普段はCloud Foundry関連の仕事もしています

7. 今回

8. 今回
APIの話はあんまりしません

9. 今回
APIの話はあんまりしません
PaaSの話をします

10. PaaS勉強会

11. PaaSなら何でもあり

12. PaaSに関係しそうな
ものもあり

13. なぜ我々はPaaS勉強会を
やるのか

14. PaaSってすごい
Buildpack
あらゆる言語やフレームワークが
利用出来るようになる仕組み
Github sync
Githubにpushするだけで
自動でHerokuアプリも更新される

15. PaaSってすごい
Azure App Service (Azure Websites)
ものすごくカンタンにWebアプリを
構築・運用できる

16. PaaSってすごい
IBM Bluemix
Pivotal Web
Services
NTT Com
Cloudn
PaaS
Cloud Foundry
プラットフォーム間の互換性あり。
どのサービスでも同じツール、
同じ操作で利用出来る

17. PaaSってすごい
OpenShift V3
Kubernetesを内包し、Dockerが
使えるPaaSに

18. PaaS、使っていますか？

19. (質問)
PaaSを触ったことある人

20. (質問)
PaaSをProduction環境で
使っている人

21. ない
ある
PaaSを触ったことがある
※上のグラフは想像です

22. 使っていない
使っている
PaaSをProductionで使っている
※上のグラフは想像です

23. なぜPaaSを使わないか
• ベンダーロックインされたくない
• 意外と手間がかかる
• 自由にやれない
• 漠然とした不安がある

24. ベンダーロックイン

25. ベンダーロックイン
• ベンダーロックイン（英: vendor lock-in）と
は、特定ベンダー（メーカー）の独自技術に
大きく依存した製品、サービス、システム等
を採用した際に、他ベンダーの提供する同種
の製品、サービス、システム等への乗り換え
が困難になる現象のこと。
http://ja.wikipedia.org/wiki/ベンダーロックイン

26. 独自技術？

27. • 一般的な言語やフレームワークを使えるPaaS
が殆ど
• Gitのような一般的なツールや、特に支障にな
らないシンプルなツールを使う場合が殆ど
• これらについてロックインを恐れる必要は無
い

28. コアの
PaaS機能
LBaaS
DBaaS
3rd Party DevOps
インフラ統合
こういうロックインはある

29. • 便利に使える機能を活用した結果、
ロックインされるという事態は起こりうる
• こういう心地良いロックインまで回避するか
どうかは、クリティカル度合いに応じて判断
• 少なくとも、ロックインと言うだけで判断し
てしまうのは勿体ない！

30. 意外と手間がかかる

31. 意外と手間がかかる
• 特にトラブルのとき
• 手元では動くのに・・・
• ログを確認しよう→あれ、どこで見れば？
• PaaSで動かすための修正を入れよう
→ なんか本末転倒じゃね？

32. • 多くの場合、対処方法はある
• おそらくそれは、これまでのやり方とは違う
• 違うやり方を強いられる
→PaaSから離れてしまう

33. 自由にやれない

34. 自由にやりたいのに・・・
• Apacheのチューニングがしたい
• Nginxのチューニングがしたい
• PHPのチューニングがry
• MySQLのチューニry
• LBのチry
• あry

35. • ある程度の設定ができるサービスもあるが、
基本的にはお任せ
• 簡単に使えることと、詳細な設定ができるこ
とは、トレードオフの関係

36. PaaSに対する漠然とした不安

37. 漠然とした不安
• 軽く試した限りでは問題無い
• でも、本番に投入して良いものか、不安
• 具体的にどこが悪いっていうわけじゃないん
だけど、なんか、こう、ね？

38. • IaaS･･･何でも自由に触れる
• SaaS･･･そもそも中身を知る必要が無い
• PaaS･･･これまで知っておく必要があった部分
が、ブラックボックス化されていて見えない

39. PaaSのブラックボックス
• 基盤の面倒をみなくて良い
→サービス側で隠 して、面倒をみる
• 逆にこれが、ユーザーに漠然とした不安を抱
かせる原因のひとつでもある

40. これまでのまとめ

41. PaaSはすごい
でも実際使うと、ちょっと大変

42. このミスマッチはどこからくるのか

43. PaaSは
ベストプラクティスを追求する

44. PaaSは
ベストプラクティスを追求する
そして、それを強制する

45. • ログの見方が今までと違う・・・
そもそもスケールアウトしたら、個別にロ
グチェックは辛いでしょ。標準出力に出せば
PaaS側でアグリゲートするよ
• トラブルシュートのやり方が今までとry
ん十台のインスタンスにSSHは厳しいでしょ
• 再起動したらローカルストレージが消える･･･
ローカルストレージ使う設計だとスケールし
ないでしょ

46. モダンでスケーラブルなWebアプリを作るための方法論
http://12factor.net/ja/
12 Factor App

47. ベストプラクティスとは
• 多くの人にとって、反復され、証明された
最も効率の良い結果をもたらす慣行
• 多くの人であって、全ての人ではない
• なので、マッチしない人も確実に存在する
こういう人達にも、PaaSは仕組みを強制し
てしまう

48. 使っていない
使っている
実際、使ってる人達からの評価はすごく高い
上手くマッチすれば幸せになれる

49. さらに
• ベストプラクティスは、常に変わりゆく。
• かつてのベストプラクティスに沿って作られた
アプリは、PaaSにフィットしないかもしれない

50. じゃあ、どうすればいいか

51. • 新しくアプリを作るときは、PaaSでやれない
か試してみる
• よく言われるPaaSのメリット
• 構築が楽になる
• 運用が楽になる
• もう一つ意識して欲しいメリット
• PaaSに載るように設計することで、
自然とベストプラクティスに沿ったものに
なる

52. • 既存アプリの載せ替えは、
試してみてダメならムリする必要はない
• 常に世の中のベストプラクティスを追ってい
れば、どこかのタイミングでPaaSを活用出来
るチャンスがやってくる(はず)

53. PaaSは
ベストプラクティスを追求する

54. ベストプラクティスは、常に変わりゆく

55. • 10年後のPaaSは、今とは全く異なるものになっているはず
• きっとPaaSという言葉自体廃れていると思う

56. • でも、ベストプラクティスを追求する
サービスは、絶対に無くならない。
そしてそれは、PaaSから発展した何かだと思う

57. そのためにも

58. PaaS勉強会に参加しよう！

59. 次回
PaaS勉強会 #26
4/27(月)
イベントページは近日公開!