The Macro of Microservices #jsug_sis

jsug_sis 勉強会 技術

はじめに

  • 話を聞きながら書いたので、全然章立て出来ていません

セッション開始前に

  • ブラジル→フランクフルト経由→日本（当日午前7時着）

セッション

  • マイクロサービスの概要を説明するセッション
  • マイクロサービスのマクロつまり大きな全体像

  • ピボタルがなぜ存在するのか

  • 私達は開発とプロダクションの溝を埋めたい

  • 皆さんに「オープンソース」と叫んで欲しい

  • 5冊の本を執筆している

  • Twitterでフォローしてね(@starbuxman)

  • Javaチャンピオンでもある

  • 2時間前についたばかり。38時間かかった

  • 2日前のブラジルの写真。違うシャツですよ

  • アプリケーションは本番環境に出すこと。全体像が重要

  • マイクロサービスの話になると、大きな全体像の小さい部分
  • プロダクションは私達の夢

  • 安全に早くプロダクションに行くことがマイクロサービス

  • 最近、ウォーターフォールが良いと感じている

  • アジャイルの3つの原則
  • 一番優先されるのはお客様の満足。つまりデリバリが大事
  • 速い

  • 頻繁に

  • ピボタルには良いソリューションがある

  • できるだけ早くリリースする

  • そのために小さく書くんだ
  • 昔はQAチームがテストする
  • DBの管理者にパスする
  • 最終的にリリースする→ここで問題が発生することもある

  • 各段階で待ち行列が発生している

  • ToyotaはLean開発を行っている

  • ソフトウェアでも使わない手はない
  • ウォータースクラムフォールになってしまう
  • 大きなアイディアを理解して欲しい
  • DevOpsで一つのチームにしよう
  • これは待ち行列を無くす仕組み
  • 業務部門からとにかくフューチャーを出せと言われていた

  • 両方が最終的には短時間でだしつづけなければいけなかった

  • まずは全体を知る。共有の見解を得ることが大事

  • 進化しつつあるものをどう管理するのか

  • 自動化することが大事

  • お客様が基盤を作りたい→本当にそれでいいの？

  • アイディアの新しさとビジネスの価値でグラフを書いた

  • 誰も電気を発明しないですよね？もう既にコモディティ化しているので

  • 本当の強みに時間をかけるべき。

  • アイディアが新しくない、ビジネスの価値が低いのは時間をかけるべきではない。
  • Amazonは既に理解していた
  • Amazonのエンジニアがとても時間を費やしてお互いの話の共有をしていた
  • 同期にもコストがかかってしまう→AWSを作った→共通のリソースを提供できるようにした
  • サーバーの運用に時間を費やすのは無駄

  • 皆さんはサーバーの管理者ではない。そこに価値を出すことはできない

  • コードを預かればその下の部分は他に任せる

  • クラウドファンドリーはクラウドのLinuxのようなもの

  • コードをより短時間でデプロイする仕組みがある

  • 皆さんの笑顔を見るのが私は嬉しい

  • できるだけ多くのものをPlatformに任せたい

  • ビルを建てる建築家が建てたビルの清掃までしなければならないとしたら？

  • クラウドは本当に良い。ただ、どうやってソフトウェアをかけば良い？

  • 続きのプレゼンテーションを是非聞いてください。

  • 2000年のアプリケーションから比べてずいぶん変わってきた

  • かつては巨大な岩だった。これで十分だった。そしていっぺんにデプロイする

  • DCの保守コストなどを考えると、これでは良くならなくなった
  • ドメインを明らかにし、機能を明らかにする
  • これを速くすることで見出すことができる
  • しかしすぐに問題が発生する

  • 共通の一つの応えがマイクロサービス

  • マイクロサービスを使うともっと色々できる

  • そんなことがどうでもいい
  • モノシックなアプリケーションで十分かもしれない

  • しかしスケーラビリティのことを考えるとそれでうまく行かなくなる

  • 立方体の図

    • ロードバランス
    • データ
    • 機能を分解する

  • データの部分が一番分かりやすい

  • インターネット上で最もよく寝られているのはポルノ→Netflix→Youtube

  • Netflixはインターネットの80％がNetflixの視聴である（アメリカよる）
  • Netflixはその時点での最高のものを提供した

  • それを提供するとスケーラビリティが必要になった

  • CEOは考えたモノシックなアプリケーションは無駄な時間が存在する。多分やを通貫するチームを作ろう

  • ビジネスリーダーが特定の部分を管理するようにする
  • 縦方向をできるだけ排除する
  • コードは小さいコードベースになる
  • コミットに対していちいち話し合う必要がない状態に
  • 変更もすぐできる

  • チーム間で安定させる必要がない

  • どれぐらいの粒度が最適なのか

  • チーム状態が大切。コードではない
  • チームはソフトウェアを写す鏡
  • OSSとプロペアのコードと比べ、様々なところから参加している。同じ業務時間で動かすことがない
  • OSSはコンポーネント間の境界をはっきりさせなければならない
  • べウンだリーは強化されなければならない
  • お互いにコミュニケーションを取れていないと、ソース間のコミュニケーションも取れないことになる
  • モジュール間の境界線が弱いんです
  • ビジネス機構に注力する一つのアイディアになる
  • マイクロサービスを行うとドメインが重要になる
  • ドメインがあれば、各会社の部門がドメインを考えると定義が違うかもしれない
  • 例えばカスタマーの定義。営業にとってのカスタマーはお金を支払っていない
  • マイクロサービスは小さな境界になる
  • マイクロサービスは沢山のメリットを提供する
  • 一番のメリットは反復できることである
  • 常に数をこなすこと、スピードを挙げることがクォリティより大切なんです
  • 1ヶ月かけて素晴らしいものを作るよりも何度も何度もできるだけ早く頻繁にリリースするほうが良い
  • 2年間とかかけていれば市場は変わっていくんです
  • フィードバックを得るんです
  • 全てのデータを集めて決定をすると
  • コンピュータサイエンスは短時間にデータを得ること
  • 非常に効率が良くないことよりもリリースを素早く出す頃が重要
  • ビジネスはリリースして価値を出せれば良い

  • レスポンスタイムが遅くても良い

  • おルプをとおっている

  • Netflixはビデオストリーミングの会社だと思っていない
  • むしろ分析の企業だと思っている
  • 例えば、TVのチャンネルがあるとする
  • 終わる10分前に死んじゃった
  • このへんで殺せばもっと見てもらえる
  • データによってどうすればよいのか分かるようになる
  • データがどのようなスクリプトにすれば良いのか教えてくれる
  • ユーザーにソフトウェアに提供するまでは
  • GreenBuild
  • 10％のオーディエンスだけにまず提供してみる
  • それで受けが良ければ残り90％に提供する
  • データを得ることで次のディシジョンが決められる
  • 自分達の分析に役立つ
  • うまく行かなければ変更する
  • ODALOOPによって継続的デリバリができる
  • ソフトウェアの自動化をする
  • できるだけ自動化する
  • プロダクションであっまりやらないと怖くなるけど、ひたすらリリースすることで
  • Flicerが1æ—¥20回デプロイするという話をした
  • LapTopを与えられ、初日にリリースする
  • オペレーションチームは常に安定を求める
  • それを支えるのが自動化
  • マイクロサービスはAPIに尽きる
  • フレームワークを入れることでAPIを作るようにする
  • 細かいサービスを創ることで痛みが発生する
  • しかしこの痛みは予測できる
  • 何かが起こった場合はどうすれば良いのか
  • こういった痛みを経験して解決してきた人がいる
  • そのオープンソースを使えば良いのです
  • クラウドによってより効率的にできるようになった
  • 生産性を上げていくには継続的デリバリにしていくことが大事