More Related Content Similar to MicroServiceArchitecture
Similar to MicroServiceArchitecture (20) 27. 「早く失敗する」にはどうしたらいい？
「構築 – 計測 – 学習」のサイクルをできる限り早く回すことです
このあたりは、リーン開発とかが詳しいみたいです。
深追いはしませんよ。
ものすご～く大雑把にいうと
構築： システムの構築や改修
計測： 運用と、そこで得られる様々なデータ
学習： 計測で得られたデータから得た知見
28. 「早く失敗する」にはどうしたらいい？
「構築 – 計測 – 学習」のサイクルをできる限り早く回すことです
このあたりは、リーン開発とかが詳しいみたいです。
深追いはしませんよ。
ものすご～く大雑把にいうと
構築： システムの構築や改修
計測： 運用と、そこで得られる様々なデータ
学習： 計測で得られたデータから得た知見
⇒このサイクルをできるだけ早くしていきたい
31. 「構築 – 計測 – 学習」サイクルを早めるには
いままで（いまも？）こういった組織構成となることが多かったのでは？
構築：開発部門
計測：運用部門
学習：サービス事業部門
32. 「構築 – 計測 – 学習」サイクルを早めるには
いままで（いまも？）こういった組織構成となることが多かったのでは？
構築：開発部門
計測：運用部門
学習：サービス事業部門
これでは、サイクルを回すのにオーバヘッドがかかってしまいます
33. 「構築 – 計測 – 学習」サイクルを早めるには
いままで（いまも？）こういった組織構成となることが多かったのでは？
構築：開発部門
計測：運用部門
学習：サービス事業部門
これでは、サイクルを回すのにオーバヘッドがかかってしまいます
こういった組織の垣根を取り払ってチーム一丸となる必要があります
34. 「構築 – 計測 – 学習」サイクルを早めるには
いままで（いまも？）こういった組織構成となることが多かったのでは？
構築：開発部門
計測：運用部門
学習：サービス事業部門
これでは、サイクルを回すのにオーバヘッドがかかってしまいます
こういった組織の垣根を取り払ってチーム一丸となる必要があります
でもこれって、とても難しいことなんです。
たとえば
35. 「構築 – 計測 – 学習」サイクルを早めるには
いままで（いまも？）こういった組織構成となることが多かったのでは？
構築：開発部門
計測：運用部門
学習：サービス事業部門
これでは、サイクルを回すのにオーバヘッドがかかってしまいます
こういった組織の垣根を取り払ってチーム一丸となる必要があります
でもこれって、とても難しいことなんです。
たとえば
開発部門 vs サービス just like: “あなた作る人、わたし食べる人”
36. 「構築 – 計測 – 学習」サイクルを早めるには
いままで（いまも？）こういった組織構成となることが多かったのでは？
構築：開発部門
計測：運用部門
学習：サービス事業部門
これでは、サイクルを回すのにオーバヘッドがかかってしまいます
こういった組織の垣根を取り払ってチーム一丸となる必要があります
でもこれって、とても難しいことなんです。
たとえば
開発部門 vs サービス just like: “あなた作る人、わたし食べる人”
開発部門 vs 運用部門 just like: “変化”を好む vs “安定”を好む
38. 「構築 – 計測 – 学習」サイクルで
必要とされる「構築」とは？
「構築 - 計測 - 学習」サイクルを回していくためには
「構築」にかかる時間を短くする必要があります。
39. 「構築 – 計測 – 学習」サイクルで
必要とされる「構築」とは？
「構築 - 計測 - 学習」サイクルを回していくためには
「構築」にかかる時間を短くする必要があります。
日本では、ここで「アジャイル開発が必要！」となります。
40. 「構築 – 計測 – 学習」サイクルで
必要とされる「構築」とは？
「構築 - 計測 - 学習」サイクルを回していくためには
「構築」にかかる時間を短くする必要があります。
日本では、ここで「アジャイル開発が必要！」となります。
でも海外では、そうはなりません。なぜならアジャイルが普通だからです。
41. 「構築 – 計測 – 学習」サイクルで
必要とされる「構築」とは？
「構築 - 計測 - 学習」サイクルを回していくためには
「構築」にかかる時間を短くする必要があります。
日本では、ここで「アジャイル開発が必要！」となります。
でも海外では、そうはなりません。なぜならアジャイルが普通だからです。
「私は間違っていた。ごめん。ウォーターフォールは何のメリットもない」 in メソッド屋のブログ
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
42. 「構築 – 計測 – 学習」サイクルで
必要とされる「構築」とは？
「構築 - 計測 - 学習」サイクルを回していくためには
「構築」にかかる時間を短くする必要があります。
アジャイル開発では、 変化を受容する
43. 「構築 – 計測 – 学習」サイクルで
必要とされる「構築」とは？
「構築 - 計測 - 学習」サイクルを回していくためには
「構築」にかかる時間を短くする必要があります。
アジャイル開発では、 変化を受容する
そこには仮説に沿った「構築」を行う素地が既にある
45. 「構築 – 計測 – 学習」サイクルに
おける「学習」とは？
仮説を立てる
46. 「構築 – 計測 – 学習」サイクルに
おける「学習」とは？
仮説を立てる
仮説のもととなるデータは「計測」のなかで取得される
47. 「構築 – 計測 – 学習」サイクルに
おける「学習」とは？
仮説を立てる
仮説のもととなるデータは「計測」のなかで取得される
フィードバックから、仮説が正しかったのかを検証する
48. 「構築 – 計測 – 学習」サイクルに
おける「学習」とは？
仮説を立てる
仮説のもととなるデータは「計測」のなかで取得される
フィードバックから、仮説が正しかったのかを検証する
フィードバックは「計測」からもたらされる
49. 「構築 – 計測 – 学習」サイクルに
おける「学習」とは？
仮説を立てる
仮説のもととなるデータは「計測」のなかで取得される
フィードバックから、仮説が正しかったのかを検証する
フィードバックは「計測」からもたらされる
進む方向を決定する
52. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」のために
「構築 - 計測 - 学習」サイクルを回していくためには
「測定」をする環境の作成にかかる時間を、短くする必要があります。
※「測定」する対象も重要なのですが、ここでは割愛。
53. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」のために
「構築 - 計測 - 学習」サイクルを回していくためには
「測定」をする環境の作成にかかる時間を、短くする必要があります。
※「測定」する対象も重要なのですが、ここでは割愛。
環境の作成の高速化
54. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」のために
「構築 - 計測 - 学習」サイクルを回していくためには
「測定」をする環境の作成にかかる時間を、短くする必要があります。
※「測定」する対象も重要なのですが、ここでは割愛。
環境の作成を機械化
仮想化、コンテナ
55. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」のために
「構築 - 計測 - 学習」サイクルを回していくためには
「測定」をする環境の作成にかかる時間を、短くする必要があります。
※「測定」する対象も重要なのですが、ここでは割愛。
環境の作成の高速化
仮想化、コンテナ
Infrastructure As Code
56. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」のために
「構築 - 計測 - 学習」サイクルを回していくためには
「測定」をする環境の作成にかかる時間を、短くする必要があります。
※「測定」する対象も重要なのですが、ここでは割愛。
環境の作成の高速化
仮想化、コンテナ
Infrastructure As Code
Blue Green Deployment
57. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」のために
「構築 - 計測 - 学習」サイクルを回していくためには
「測定」をする環境の作成にかかる時間を、短くする必要があります。
※「測定」する対象も重要なのですが、ここでは割愛。
環境の作成の高速化
仮想化、コンテナ
直接、機械を触る必要がなくなる
Infrastructure As Code
Blue Green Deployment
58. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」のために
「構築 - 計測 - 学習」サイクルを回していくためには
「測定」をする環境の作成にかかる時間を、短くする必要があります。
※「測定」する対象も重要なのですが、ここでは割愛。
環境の作成の高速化
仮想化、コンテナ
直接、機械を触る必要がなくなる
Infrastructure As Code
人間が１台ずつ設定していく必要がなくなる
Blue Green Deployment
59. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」のために
「構築 - 計測 - 学習」サイクルを回していくためには
「測定」をする環境の作成にかかる時間を、短くする必要があります。
※「測定」する対象も重要なのですが、ここでは割愛。
環境の作成の高速化
仮想化、コンテナ
直接、機械を触る必要がなくなる
Infrastructure As Code
人間が１台ずつ設定していく必要がなくなる
Blue Green Deployment
設定は必要になったタイミングで都度、実施
いらなくなったら、全部リセット
61. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」とは？
仮説を構築するためのデータを提供する
62. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」とは？
仮説を構築するためのデータを提供する
仮説を検証するためのフィードバックを提供する
63. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」とは？
仮説を構築するためのデータを提供する
仮説を検証するためのフィードバックを提供する
「学習」のプロセスでは上記が視覚化されることが必要
64. 「構築 – 計測 – 学習」サイクルで
必要とされる「測定」とは？
仮説を構築するためのデータを提供する
仮説を検証するためのフィードバックを提供する
「学習」のプロセスでは上記が視覚化されることが必要
視覚化を「計測」「学習」のどちらでやるかは、考えなくてもよいと思う。
チーム一丸なので、どちらでも。
69. ひとつの巨大なシステムでは、
「構築 - 計測 - 学習」サイクルを早く回せない
リリースには時間がかかります
部署間の調整
システムの影響範囲の調査
スケールアウトではなく、スケールアップが選択肢となることが多い
70. ひとつの巨大なシステムでは、
「構築 - 計測 - 学習」サイクルを早く回せない
リリースには時間がかかります
部署間の調整
システムの影響範囲の調査
スケールアウトではなく、スケールアップが選択肢となることが多い
チームや組織、コンポーネントの関係が密になりすぎているわけです
71. ひとつの巨大なシステムでは、
「構築 - 計測 - 学習」サイクルを早く回せない
リリースには時間がかかります
部署間の調整
システムの影響範囲の調査
スケールアウトではなく、スケールアップが選択肢となることが多い
チームや組織、コンポーネントの関係が密になりすぎているわけです
この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず）
APIを通じて、お互いがコミュニケーションすればよい
72. ひとつの巨大なシステムでは、
「構築 - 計測 - 学習」サイクルを早く回せない
リリースには時間がかかります
部署間の調整
システムの影響範囲の調査
スケールアウトではなく、スケールアップが選択肢となることが多い
チームや組織、コンポーネントの関係が密になりすぎているわけです
この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず）
APIを通じて、お互いがコミュニケーションすればよい
スケールアップではなく、スケールアウトが選択肢となる
73. ひとつの巨大なシステムでは、
「構築 - 計測 - 学習」サイクルを早く回せない
リリースには時間がかかります
部署間の調整
システムの影響範囲の調査
スケールアウトではなく、スケールアップが選択肢となることが多い
チームや組織、コンポーネントの関係が密になりすぎているわけです
この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず）
APIを通じて、お互いがコミュニケーションすればよい
スケールアップではなく、スケールアウトが選択肢となる
⇒これが、「マイクロサービス・アーキテクチャ」の原型です
74. ひとつの巨大なシステムでは、
「構築 - 計測 - 学習」サイクルを早く回せない
リリースには時間がかかります
部署間の調整
システムの影響範囲の調査
スケールアップ
チームや組織、コンポーネントの関係が密になりすぎているわけです
この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず）
APIを通じて、お互いがコミュニケーションすればよい
スケールアップではなく、スケールアウトが選択肢となる
⇒これが、「マイクロサービス・アーキテクチャ」の原型です
「マイクロサービス・アーキテクチャ」は、
現実世界の課題を解決しようと
試行錯誤したうえで出てきたもの
Editor's Notes それぞれの組織が、自己の「責任」を果たそうとする
とても正しく、素晴らしいことで、それを否定するつもりはないのです
（誤解されそうなので、ここ強調！）
一丸となるには、結集軸が必要となります。
・自分の組織や仕事への影響は出るでしょうが、それを甘受できるようになるなにかが。 アジャイル開発が隆盛：２０００年前後。
２００１年、「アジャイルソフトウェア開発宣言」
一方、MapReduceのGoogleの論文は、2004年 アジャイル開発が隆盛したときには、まだこの、計測は難しかった。
２００１年、「アジャイルソフトウェア開発宣言」
一方、MapReduceのGoogleの論文は、2004年 アジャイル開発が隆盛したときには、まだこの、計測は難しかった。
２００１年、「アジャイルソフトウェア開発宣言」
一方、MapReduceのGoogleの論文は、2004年 アジャイル開発が隆盛したときには、まだこの、計測は難しかった。
２００１年、「アジャイルソフトウェア開発宣言」
一方、MapReduceのGoogleの論文は、2004年 「発見」っていうのは言い過ぎなので、訂正 http://readwrite.jp/startup/29950
に失敗を従容すること
そして有名な６原則が書かれている。
英語だと、こちら？
http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/
「Amazonは一つのことだけに携わる小さなチームの集まりで出来ており、そのために急速なイノベーションが可能になっている」とベゾス氏は述べている。
これらのチームは、以下にある「公開されたAPI」に（強制的に）沿って互いにコミュニケーションを取っている。
－全てのチームはサービスインターフェイスを通じてその機能やデータを公開しなければならない。
－チームのコミュニケーションはインターフェイスを通じて行われる。
－インターフェイスを通じたもの以外のあらゆるプロセス間通信は許可されない。 直接的にリンクすること、他のチームのデータを直接見ること、共有メモリモデルによる コミュニケーション、バックドアやその他の手段すべてに対してこれは適用される。 唯一許可されるコミュニケーションは、ネットワーク越しにインターフェイスを叩くことのみである。
－どのようなテクノロジーを使っていたとしてもこのルールは変わらない。
－どのようなサービスインターフェイスも例外なく公開されることを前提に、 根底からデザインされなければならない。つまり、チームはインターフェイスを 開発者に公開できるようにプラン設計を行わなければならない。例外は認められない。
そして、これらを選択肢の1つだと考えているAmazonの従業員たちに対し、ベゾス氏はこう締めくくっている。
「これを守れない社員はクビにする。では、今日もいい日を」
