Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ひしめき合う Open PaaSを徹底解剖! PaaSの今と未来
Kazuto Kusama @jacopen
Cloud Foundryベースの PaaS開発・運用 しごと
世界を緑色にする仕事 しごと
世界を緑色にする仕事 しごと
個人活動 • PaaS勉強会主宰 • 日本Cloud Foundryグループ
 理事
今日の話
Open PaaS
プロプライエタリPaaS
Open PaaS
Open PaaS
今回伝えたいこと • 是非、Open PaaSに興味をもって欲しい • 今あるOpen PaaSの紹介 • どうOpen PaaSと付き合っていくべきか • Open PaaSの未来はどうなるか
Open PaaSを触ってみよう
Cloud Foundry Cloud Foundry Foundationが開発
 (Pivotal, IBM, HP, Intel, NTTなどが参加) 2011年にVMwareがOSSとして公開。その後 Pivotal Software ...
Cloud Foundryを採用したサービス Public PaaS Private PaaS Pivotal (Pivotal Web Services) IBM (Bluemix) NTT Communications (Cloudn Pa...
DEMO
$  ls   index.php  info.php   $cf  push  jft-­‐php   Creating  app  jft-­‐php  in  org  cln1000212...
$  ls   index.php  info.php   $cf  push  jft-­‐php   Creating  app  jft-­‐php  in  org  cln1000212...
$  cf  api  https://api.ng.bluemix.net   Setting  api  endpoint  to  https://api.ng.bluemix.net...   OK ...
$  cf  api  https://api.ng.bluemix.net   Setting  api  endpoint  to  https://api.ng.bluemix.net...   OK ...
$  cf  scale  jtf-­‐php  -­‐i  3   Scaling  app  jtf-­‐php  in  org  erm  /  space  production...
Cloud Foundryのメリット • たくさんのベンダーがCFを採用 • Open PaaSの理想「アンチベンダーロックイ ン」が実現されつつある • Open PaaSでは古参なので、比較的情報が多い • Eclipse, Intelli...
Cloud Foundryのデメリット • デプロイが死ぬほど大変 • 互換性維持のために、合理的とは言い難いソフ トウェアスタックになりつつある • NIH症候群の気が・・・
Cloud Foundryのデメリット • デプロイが死ぬほど大変 • 互換性維持のために、合理的とは言い難いソフ トウェアスタックになりつつある • NIH症候群の気が・・・ • デプロイが死ぬほど大変
Cloud Foundryのデメリット • デプロイが死ぬほど大変 • 互換性維持のために、合理的とは言い難いソフ トウェアスタックになりつつある • NIH症候群の気が・・・ • デプロイが死ぬほど大変 • デプロイが死ぬほど大変
は？ は使えないの？
次期バージョン”Diego”で
 Docker imageサポート
Docker image互換じゃなくて Dockerが使えるPaaSが欲しい？
OpenShift Red Hatが開発 2011年に発表、2012年にOSSとして公開。 2015年、それまでの仕組み(OpenShift v2)を捨て 去り、Docker PaaSとして生まれ変わった OpenShift v3を公開。
KubernetesをPaaSに OpenShift v3のコアはKubernetes Kubernetesの開発にはRed Hatが深く関わってい る Kubernetesの概念(Service, Pod, Replication Contr...
OpenShiftの展開
DEMO
DEMOしようと思ったけど
 失敗(◔⊖◔)
http://www.slideshare.net/jacopen/openshift-3dockerpaas あたりを参考に・・・
OpenShiftのメリット • コアにKubernetesを据えることで、進化が著 しい • Githubとの連携やwebhookなど、便利な機能 が最初から っている • Red Hat + Google + その他沢山のベンダーや 開発者...
OpenShiftのデメリット • Kubernetesの概念が色濃く残っており、PaaS として使い勝手がいいかどうかは・・・？ • Cloud Foundryほどエコシステムが広がって いない • アーキテクチャのリセットはこれで最後・・・...
Kubernetesは分かりづらい！ もっとシンプルなDocker PaaSは無いの？
Deis • Docker + CoreOSをベースとしたPaaS • 2013年公開。OpDemandが開発。 • 2015年、PaaSベンダーのEngine Yardが OpDemandを買収
DEMO
$  deis  create   Creating  application...  done,  created  sanest-­‐odometer   Git  remote  deis  a...
$  deis  create   Creating  application...  done,  created  sanest-­‐odometer   Git  remote  deis  a...
$  deis  scale  web=5   Scaling  processes...  but  first,  coffee!   done  in  12s   ===  unise...
Deisのメリット • Herokuライクな使い勝手 • Buildpack, Docker image, Dockerfileなど様々 な仕組みが利用出来る
Deisデメリット • スケジューリングが遅い • Productionに投入するにはもう少し・・・
Flynn
Flynn • Docker PaaS • 2013年、クラウドファウンディングのスタイ ルでスタート。現在はPrime Directiveが開発 を主導 • シンプルなHerokuクローン Dokkuの作者が開 発に関与している
DEMO
$  flynn  create   Created  coyotes-­‐rebuff-­‐richards   $  git  remote  show   deis   flynn   orig...
$  flynn  create   Created  coyotes-­‐rebuff-­‐richards   $  git  remote  show   deis   flynn   orig...
$  flynn  scale  web=5   scaling  web:  3=>5   14:32:04.554  ==>  web  flynn-­‐6e60228c3fa54933acc3040...
Flynnのメリット • シンプル、かつモジュラーでカスタマイズし やすいアーキテクチャ • PaaSに必要な要素がFlynn内でほぼ完結して いる
Flynnのデメリット • CF, OpenShift, Deisに比べると開発の継続力 に一抹の不安 • モジュラーなアーキテクチャは良し、しかし どこまでメンテナンスし続けられるか
アプリのデプロイ方法 cfコマンド git gitocコマンド webhook
アプリのデプロイ方法 buildpack (docker image) buildpack docker image buildpack docker image dockerfile STI docker image
前提OS Ubuntu Ubuntu CoreOS RHEL CentOS
コンテナ Warden Docker DockerDocker
By gopher-vector https://github.com/golang-samples/gopher-vector Ruby + Golang Golang Python + Golang Golang 開発言語
4つのOpen PaaSを比較してみましたが
どれもあまり変わらなくね？
✓ gitやCLIツールからデプロイができて ✓ DockerfileやBuildpackのような複数言語を扱う仕組 みが使えて ✓ コマンド一発で起動・停止・スケールアウトが出来て ✓ リクエストルータもあってマルチホストに展開ができ る
何故どれも似た感じになるのか
スケールするWebアプリケーションの ベストプラクティスがある
• 12 Factor appの考え方は極めてシンプルで優れている • どのPaaSも、12 Factor appを前提に作り込んでいく • 結果として、どれも使い勝手としては
 似たようなものとなる
大規模にスケールする プラットフォームの作り方も、 だいたい確立している
node node node アプリが動く 複数のノード
node node node Controller Scheduler ノードにアプリを配置する コントローラ スケジューラ
node node node Controller Scheduler Helth Monitoring ヘルスチェックの 仕組み
node node node Controller Scheduler Request
 Router Helth Monitoring アプリへのアクセス をルーティングする リクエストルータ
node node node Controller Scheduler Request
 Router MQ or KVS Helth Monitoring 各コンポーネントを 疎結合に保つための メッセージキュー
 キーバリューストア
node node node Controller Scheduler Request
 Router MQ or KVS Log Collector Metrics Collector Helth Monitoring ログ・メトリクスの ア...
+
結果として似たような感じに
Open PaaSとの付き合い方
Public PaaSの選択肢として
自社サービスの基盤として Private PaaS構築
自社サービスの基盤として Private PaaS構築 • えー、大変じゃない？
自社サービスの基盤として Private PaaS構築 • えー、大変じゃない？  はい、死ぬほど大変です。
自社サービスの基盤として Private PaaS構築 • えー、大変じゃない？  はい、死ぬほど大変です。 • あんまり自由が利かないんじゃない？
自社サービスの基盤として Private PaaS構築 • えー、大変じゃない？  はい、死ぬほど大変です。 • あんまり自由が利かないんじゃない？  はい、あんまり利きません
でもちょっと待って
皆さん Dockerは使っていますか？
構成管理ツールは？ Fluentdも使ってますね？
優れた仕組みを積極的に
 取り入れていくのは大切
でも、だんだんと継ぎ接ぎになりませんか？
1. サービスを開発する 2. 様々な場所に新しい仕組みを取り入れ、効率化を図っていく 3. だんだん規模が大きくなってくる 4. 間に挟まる仕組みも大規模に、複雑になってくる 5. それぞれのアップデートにかかるコストや、引き継ぎにかか るコ...
『全部入り』のOpen PaaSを選択肢に
• どうやってスケールアウトしよう・・・ • どうやってログ収集しよう・・・ • どうやってリソース監視しよう・・・ • どうやって無停止でアップデートしよう・・・ みんな課題は似たようなもの
node node node Controller Scheduler Request
 Router MQ or KVS Log Collector Metrics Collector Helth Monitoring きっと自前で作っても似...
ダクトテープを投げ捨てよう
仮にOpen PaaSを採用しなかったと しても、アーキテクチャの参考に
デカイ 複雑 コアはk8s CoreOSの機能 活用しまくり これ1つで完結
Open PaaSの未来
や ぁ
進化し続けるコンテナへの対応
進化し続けるコンテナへの対応
Webアプリケーション以外のサポート • コンテナで動けば、アプリケーション自体は動く • HTTP/HTTPS以外でどうアクセスできるようにするか
TCP Routing openshift-sdn Networking v2
あらゆるサービスの「ハブ」に PaaS IoT mBaaS DBaaS Bigdata
進化の著しい世界
楽しい!!✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌
PaaS勉強会
第27回 7/29
PaaS x IoT Node-RED 勉強会 8/26
Questions?
ひしめき合うOpen PaaSを徹底解剖！ PaaSの今と未来
ひしめき合うOpen PaaSを徹底解剖！ PaaSの今と未来
ひしめき合うOpen PaaSを徹底解剖！ PaaSの今と未来
ひしめき合うOpen PaaSを徹底解剖！ PaaSの今と未来
ひしめき合うOpen PaaSを徹底解剖！ PaaSの今と未来
ひしめき合うOpen PaaSを徹底解剖！ PaaSの今と未来
Upcoming SlideShare
Loading in …5
×

ひしめき合うOpen PaaSを徹底解剖！ PaaSの今と未来

17,116 views

Published on

July Tech Festaで発表した資料です。 Cloud Foundry、OpenShift v3、Deis、Flynnを取り上げて、Open PaaSの今と未来について解説しました。

Published in: Technology
no profile picture user

  • Be the first to comment

Show More

ひしめき合うOpen PaaSを徹底解剖！ PaaSの今と未来

  1. 1. ひしめき合う Open PaaSを徹底解剖! PaaSの今と未来
  2. 2. Kazuto Kusama @jacopen
  3. 3. Cloud Foundryベースの PaaS開発・運用 しごと
  4. 4. 世界を緑色にする仕事 しごと
  5. 5. 世界を緑色にする仕事 しごと
  6. 6. 個人活動 • PaaS勉強会主宰 • 日本Cloud Foundryグループ
 理事
  7. 7. 今日の話
  8. 8. Open PaaS
  9. 9. プロプライエタリPaaS
  10. 10. Open PaaS
  11. 11. Open PaaS
  12. 12. 今回伝えたいこと • 是非、Open PaaSに興味をもって欲しい • 今あるOpen PaaSの紹介 • どうOpen PaaSと付き合っていくべきか • Open PaaSの未来はどうなるか
  13. 13. Open PaaSを触ってみよう
  14. 14. Cloud Foundry Cloud Foundry Foundationが開発
 (Pivotal, IBM, HP, Intel, NTTなどが参加) 2011年にVMwareがOSSとして公開。その後 Pivotal Software Cloud Foundry Foundationに 移管。
  15. 15. Cloud Foundryを採用したサービス Public PaaS Private PaaS Pivotal (Pivotal Web Services) IBM (Bluemix) NTT Communications (Cloudn PaaS) Fujitsu (K5) Pivotal (Pivotal CF) HP (Helion Development Platform) Active State (Stackato)
  16. 16. DEMO
  17. 17. $  ls   index.php  info.php   $cf  push  jft-­‐php   Creating  app  jft-­‐php  in  org  cln100021251  /  space  production  as  xxxxx...   OK   Creating  route  jft-­‐php.paas.jp-­‐e1.cloudn-­‐service.com...   OK   Binding  jft-­‐php.paas.jp-­‐e1.cloudn-­‐service.com  to  jft-­‐php...   OK   Uploading  jft-­‐php...   Uploading  app  files  from:  /Users/jacopen/Project/jacopen/jtf/php   Uploading  1.7K,  2  files   Done  uploading   OK   (中略)            state          since                                        cpu        memory                    disk                    details   #0      running      2015-­‐07-­‐26  02:07:26  PM      0.0%      14.5M  of  256M      34.1M  of  2G   ※デモで話した内容 シンプルなPHPアプリをCloudn PaaSにデプロイ
  18. 18. $  ls   index.php  info.php   $cf  push  jft-­‐php   Creating  app  jft-­‐php  in  org  cln100021251  /  space  production  as  xxxxx...   OK   Creating  route  jft-­‐php.paas.jp-­‐e1.cloudn-­‐service.com...   OK   Binding  jft-­‐php.paas.jp-­‐e1.cloudn-­‐service.com  to  jft-­‐php...   OK   Uploading  jft-­‐php...   Uploading  app  files  from:  /Users/jacopen/Project/jacopen/jtf/php   Uploading  1.7K,  2  files   Done  uploading   OK   (中略)            state          since                                        cpu        memory                    disk                    details   #0      running      2015-­‐07-­‐26  02:07:26  PM      0.0%      14.5M  of  256M      34.1M  of  2G   ※デモで話した内容 動きました。かんたん。
  19. 19. $  cf  api  https://api.ng.bluemix.net   Setting  api  endpoint  to  https://api.ng.bluemix.net...   OK   API  endpoint:      https://api.ng.bluemix.net  (API  version:  2.27.0)   Not  logged  in.  Use  'cf  login'  to  log  in.   $  cf  login   API  endpoint:  https://api.ng.bluemix.net   (中略)   $  cf  push  jtf-­‐php   Creating  app  jtf-­‐php  in  org  erm  /  space  production  as  xxxxx...   OK   ※デモで話した内容 全く同じコマンドで、向き先をBluemixに切り替えてデプロイ
  20. 20. $  cf  api  https://api.ng.bluemix.net   Setting  api  endpoint  to  https://api.ng.bluemix.net...   OK   API  endpoint:      https://api.ng.bluemix.net  (API  version:  2.27.0)   Not  logged  in.  Use  'cf  login'  to  log  in.   $  cf  login   API  endpoint:  https://api.ng.bluemix.net   (中略)   $  cf  push  jtf-­‐php   Creating  app  jtf-­‐php  in  org  erm  /  space  production  as  xxxxx...   OK   ※デモで話した内容 全く同じようにうごきました
  21. 21. $  cf  scale  jtf-­‐php  -­‐i  3   Scaling  app  jtf-­‐php  in  org  erm  /  space  production  as  xxxxx...   OK   ※デモで話した内容 スケールアウトも簡単にできます
  22. 22. Cloud Foundryのメリット • たくさんのベンダーがCFを採用 • Open PaaSの理想「アンチベンダーロックイ ン」が実現されつつある • Open PaaSでは古参なので、比較的情報が多い • Eclipse, IntelliJ, Visual StudioなどのIDEサポー トがある。ツールも豊富
  23. 23. Cloud Foundryのデメリット • デプロイが死ぬほど大変 • 互換性維持のために、合理的とは言い難いソフ トウェアスタックになりつつある • NIH症候群の気が・・・
  24. 24. Cloud Foundryのデメリット • デプロイが死ぬほど大変 • 互換性維持のために、合理的とは言い難いソフ トウェアスタックになりつつある • NIH症候群の気が・・・ • デプロイが死ぬほど大変
  25. 25. Cloud Foundryのデメリット • デプロイが死ぬほど大変 • 互換性維持のために、合理的とは言い難いソフ トウェアスタックになりつつある • NIH症候群の気が・・・ • デプロイが死ぬほど大変 • デプロイが死ぬほど大変
  26. 26. は？ は使えないの？
  27. 27. 次期バージョン”Diego”で
 Docker imageサポート
  28. 28. Docker image互換じゃなくて Dockerが使えるPaaSが欲しい？
  29. 29. OpenShift Red Hatが開発 2011年に発表、2012年にOSSとして公開。 2015年、それまでの仕組み(OpenShift v2)を捨て 去り、Docker PaaSとして生まれ変わった OpenShift v3を公開。
  30. 30. KubernetesをPaaSに OpenShift v3のコアはKubernetes Kubernetesの開発にはRed Hatが深く関わってい る Kubernetesの概念(Service, Pod, Replication Controller)をそのまま取り入れている
  31. 31. OpenShiftの展開
  32. 32. DEMO
  33. 33. DEMOしようと思ったけど
 失敗(◔⊖◔)
  34. 34. http://www.slideshare.net/jacopen/openshift-3dockerpaas あたりを参考に・・・
  35. 35. OpenShiftのメリット • コアにKubernetesを据えることで、進化が著 しい • Githubとの連携やwebhookなど、便利な機能 が最初から っている • Red Hat + Google + その他沢山のベンダーや 開発者によって開発される安心感
  36. 36. OpenShiftのデメリット • Kubernetesの概念が色濃く残っており、PaaS として使い勝手がいいかどうかは・・・？ • Cloud Foundryほどエコシステムが広がって いない • アーキテクチャのリセットはこれで最後・・・ だよね？
  37. 37. Kubernetesは分かりづらい！ もっとシンプルなDocker PaaSは無いの？
  38. 38. Deis • Docker + CoreOSをベースとしたPaaS • 2013年公開。OpDemandが開発。 • 2015年、PaaSベンダーのEngine Yardが OpDemandを買収
  39. 39. DEMO
  40. 40. $  deis  create   Creating  application...  done,  created  sanest-­‐odometer   Git  remote  deis  added   $  git  remote  show   deis   origin   $  git  push  deis  master   Counting  objects:  9,  done.   Delta  compression  using  up  to  4  threads.   Compressing  objects:  100%  (5/5),  done.   Writing  objects:  100%  (9/9),  1.04  KiB  |  0  bytes/s,  done.   Total  9  (delta  1),  reused  0  (delta  0)   (後略) ※デモで話した内容 deis createすると、deisにアプリが作られると同時に gitにremoteリポジトリが追加される あとは git push deis masterすればデプロイされる、 Herokuライクな使い勝手。
  41. 41. $  deis  create   Creating  application...  done,  created  sanest-­‐odometer   Git  remote  deis  added   $  git  remote  show   deis   origin   $  git  push  deis  master   Counting  objects:  9,  done.   Delta  compression  using  up  to  4  threads.   Compressing  objects:  100%  (5/5),  done.   Writing  objects:  100%  (9/9),  1.04  KiB  |  0  bytes/s,  done.   Total  9  (delta  1),  reused  0  (delta  0)   (後略) ※デモで話した内容 簡単
  42. 42. $  deis  scale  web=5   Scaling  processes...  but  first,  coffee!   done  in  12s   ===  unisex-­‐newsreel  Processes   -­‐-­‐-­‐  web:   web.1  up  (v2)   web.2  up  (v2)   web.3  up  (v2)   web.4  up  (v2)   web.5  up  (v2)   ※デモで話した内容 deis scaleでスケールアウト可能。 ただ、ちょっと遅い
  43. 43. Deisのメリット • Herokuライクな使い勝手 • Buildpack, Docker image, Dockerfileなど様々 な仕組みが利用出来る
  44. 44. Deisデメリット • スケジューリングが遅い • Productionに投入するにはもう少し・・・
  45. 45. Flynn
  46. 46. Flynn • Docker PaaS • 2013年、クラウドファウンディングのスタイ ルでスタート。現在はPrime Directiveが開発 を主導 • シンプルなHerokuクローン Dokkuの作者が開 発に関与している
  47. 47. DEMO
  48. 48. $  flynn  create   Created  coyotes-­‐rebuff-­‐richards   $  git  remote  show   deis   flynn   origin   $  git  push  flynn  master   Counting  objects:  9,  done.   Delta  compression  using  up  to  4  threads.   Compressing  objects:  100%  (5/5),  done.   Writing  objects:  100%  (9/9),  1.04  KiB  |  0  bytes/s,  done.   Total  9  (delta  1),  reused  0  (delta  0)   -­‐-­‐-­‐-­‐-­‐>  Building  coyotes-­‐rebuff-­‐richards...   -­‐-­‐-­‐-­‐-­‐>  PHP  app  detected   (後略)   ※デモで話した内容 flynn createでアプリ作成とリモートリポジトリ追加 git push flynn masterでデプロイ。 deisと驚くほど一緒 (まあ、Herokuのインスパイア)
  49. 49. $  flynn  create   Created  coyotes-­‐rebuff-­‐richards   $  git  remote  show   deis   flynn   origin   $  git  push  flynn  master   Counting  objects:  9,  done.   Delta  compression  using  up  to  4  threads.   Compressing  objects:  100%  (5/5),  done.   Writing  objects:  100%  (9/9),  1.04  KiB  |  0  bytes/s,  done.   Total  9  (delta  1),  reused  0  (delta  0)   -­‐-­‐-­‐-­‐-­‐>  Building  coyotes-­‐rebuff-­‐richards...   -­‐-­‐-­‐-­‐-­‐>  PHP  app  detected   (後略)   ※デモで話した内容 (n‘∀‘)η
  50. 50. $  flynn  scale  web=5   scaling  web:  3=>5   14:32:04.554  ==>  web  flynn-­‐6e60228c3fa54933acc30401b9a30a4d  starting   14:32:04.747  ==>  web  flynn-­‐397fba6e68cf4206bb8c28328a843427  starting   14:32:05.215  ==>  web  flynn-­‐397fba6e68cf4206bb8c28328a843427  up   14:32:06.344  ==>  web  flynn-­‐6e60228c3fa54933acc30401b9a30a4d  up   scale  completed  in  2.252653272s   ※デモで話した内容 flynn scaleでスケールアウト可能。 こちらはかなり速い
  51. 51. Flynnのメリット • シンプル、かつモジュラーでカスタマイズし やすいアーキテクチャ • PaaSに必要な要素がFlynn内でほぼ完結して いる
  52. 52. Flynnのデメリット • CF, OpenShift, Deisに比べると開発の継続力 に一抹の不安 • モジュラーなアーキテクチャは良し、しかし どこまでメンテナンスし続けられるか
  53. 53. アプリのデプロイ方法 cfコマンド git gitocコマンド webhook
  54. 54. アプリのデプロイ方法 buildpack (docker image) buildpack docker image buildpack docker image dockerfile STI docker image
  55. 55. 前提OS Ubuntu Ubuntu CoreOS RHEL CentOS
  56. 56. コンテナ Warden Docker DockerDocker
  57. 57. By gopher-vector https://github.com/golang-samples/gopher-vector Ruby + Golang Golang Python + Golang Golang 開発言語
  58. 58. 4つのOpen PaaSを比較してみましたが
  59. 59. どれもあまり変わらなくね？
  60. 60. ✓ gitやCLIツールからデプロイができて ✓ DockerfileやBuildpackのような複数言語を扱う仕組 みが使えて ✓ コマンド一発で起動・停止・スケールアウトが出来て ✓ リクエストルータもあってマルチホストに展開ができ る
  61. 61. 何故どれも似た感じになるのか
  62. 62. スケールするWebアプリケーションの ベストプラクティスがある
  63. 63. • 12 Factor appの考え方は極めてシンプルで優れている • どのPaaSも、12 Factor appを前提に作り込んでいく • 結果として、どれも使い勝手としては
 似たようなものとなる
  64. 64. 大規模にスケールする プラットフォームの作り方も、 だいたい確立している
  65. 65. node node node アプリが動く 複数のノード
  66. 66. node node node Controller Scheduler ノードにアプリを配置する コントローラ スケジューラ
  67. 67. node node node Controller Scheduler Helth Monitoring ヘルスチェックの 仕組み
  68. 68. node node node Controller Scheduler Request
 Router Helth Monitoring アプリへのアクセス をルーティングする リクエストルータ
  69. 69. node node node Controller Scheduler Request
 Router MQ or KVS Helth Monitoring 各コンポーネントを 疎結合に保つための メッセージキュー
 キーバリューストア
  70. 70. node node node Controller Scheduler Request
 Router MQ or KVS Log Collector Metrics Collector Helth Monitoring ログ・メトリクスの アグリゲーション
  71. 71. +
  72. 72. 結果として似たような感じに
  73. 73. Open PaaSとの付き合い方
  74. 74. Public PaaSの選択肢として
  75. 75. 自社サービスの基盤として Private PaaS構築
  76. 76. 自社サービスの基盤として Private PaaS構築 • えー、大変じゃない？
  77. 77. 自社サービスの基盤として Private PaaS構築 • えー、大変じゃない？  はい、死ぬほど大変です。
  78. 78. 自社サービスの基盤として Private PaaS構築 • えー、大変じゃない？  はい、死ぬほど大変です。 • あんまり自由が利かないんじゃない？
  79. 79. 自社サービスの基盤として Private PaaS構築 • えー、大変じゃない？  はい、死ぬほど大変です。 • あんまり自由が利かないんじゃない？  はい、あんまり利きません
  80. 80. でもちょっと待って
  81. 81. 皆さん Dockerは使っていますか？
  82. 82. 構成管理ツールは？ Fluentdも使ってますね？
  83. 83. 優れた仕組みを積極的に
 取り入れていくのは大切
  84. 84. でも、だんだんと継ぎ接ぎになりませんか？
  85. 85. 1. サービスを開発する 2. 様々な場所に新しい仕組みを取り入れ、効率化を図っていく 3. だんだん規模が大きくなってくる 4. 間に挟まる仕組みも大規模に、複雑になってくる 5. それぞれのアップデートにかかるコストや、引き継ぎにかか るコストが無視出来なくなってくる ある種のリスクを抱えている状態
  86. 86. 『全部入り』のOpen PaaSを選択肢に
  87. 87. • どうやってスケールアウトしよう・・・ • どうやってログ収集しよう・・・ • どうやってリソース監視しよう・・・ • どうやって無停止でアップデートしよう・・・ みんな課題は似たようなもの
  88. 88. node node node Controller Scheduler Request
 Router MQ or KVS Log Collector Metrics Collector Helth Monitoring きっと自前で作っても似たような仕組みに
  89. 89. ダクトテープを投げ捨てよう
  90. 90. 仮にOpen PaaSを採用しなかったと しても、アーキテクチャの参考に
  91. 91. デカイ 複雑 コアはk8s CoreOSの機能 活用しまくり これ1つで完結
  92. 92. Open PaaSの未来
  93. 93. や ぁ
  94. 94. 進化し続けるコンテナへの対応
  95. 95. 進化し続けるコンテナへの対応
  96. 96. Webアプリケーション以外のサポート • コンテナで動けば、アプリケーション自体は動く • HTTP/HTTPS以外でどうアクセスできるようにするか
  97. 97. TCP Routing openshift-sdn Networking v2
  98. 98. あらゆるサービスの「ハブ」に PaaS IoT mBaaS DBaaS Bigdata
  99. 99. 進化の著しい世界
  100. 100. 楽しい!!✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌
  101. 101. PaaS勉強会
  102. 102. 第27回 7/29
  103. 103. PaaS x IoT Node-RED 勉強会 8/26
  104. 104. Questions?

×