SlideShare a Scribd company logo

MicroServiceArchitecture

Download as PPTX, PDF
K
Kaseya Hiroshi

社内勉強会で利用した資料です。

Engineering
1 of 82
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
マイクロサービス アーキテクチャ概説
本日のゴール  「マイクロサービス」へと至る、昨今の開発トレンドを理解する  今後開催される、深堀りした勉強会の前提となる知識を身に着ける
 テーマが広すぎた・・・。  どうしよう・・・。
MicroServiceArchitecture
 ソフトな感じで、DevOpsから始めてみます。
突然ですが、DevOpsって知っていますか？
突然ですが、DevOpsって知っていますか？  そうです。DevとOpsが組み合わさったものです。
突然ですが、DevOpsって知っていますか？  そうです。DevとOpsが組み合わさったものです。  バズってます
突然ですが、DevOpsって知っていますか？  そうです。DevとOpsが組み合わさったものです。  バズってます  これの実現を目標にする上司がいたら、黄色信号。  理由は、のちほど
DevOpsって、なぜ生まれたのでしょう？
DevOpsって、なぜ生まれたのでしょう？  「必要だったから」
DevOpsって、なぜ生まれたのでしょう？  「必要だったから」  まあ、そうなんですが、身も蓋もないので、解説します
DevOpsって、なぜ生まれたのでしょう？  どの企業も、レッドオーシャンでビジネスなんかしたくないんです
DevOpsって、なぜ生まれたのでしょう？  どの企業も、レッドオーシャンでビジネスなんかしたくないんです  だから、  新しい分野への進出していく
DevOpsって、なぜ生まれたのでしょう？  どの企業も、レッドオーシャンでビジネスなんかしたくないんです  だから、  新しい分野への進出していく  何らかの付加価値をつけていく
DevOpsって、なぜ生まれたのでしょう？  どの企業も、レッドオーシャンでビジネスなんかしたくないんです  だから、  新しい分野への進出していく  何らかの付加価値をつけていく  そこは、トライ＆エラーの世界
DevOpsって、なぜ生まれたのでしょう？  どの企業も、レッドオーシャンでビジネスなんかしたくないんです  だから、  新しい分野への進出していく  何らかの付加価値をつけていく  そこは、トライ＆エラーの世界  何が成功するのか、答えは誰も知らない世界です
DevOpsって、なぜ生まれたのでしょう？  どの企業も、レッドオーシャンでビジネスなんかしたくないんです  だから、  新しい分野への進出していく  何らかの付加価値をつけていく  そこは、トライ＆エラーの世界  何が成功するのか、答えは誰も知らない世界です  だから仮説をつくり、それを世の中に出して結果を検証していく
DevOpsって、なぜ生まれたのでしょう？  どの企業も、レッドオーシャンでビジネスなんかしたくないんです  だから、  新しい分野への進出していく  何らかの付加価値をつけていく  そこは、トライ＆エラーの世界  何が成功するのか、答えは誰も知らない世界です  だから仮説をつくり、それを世の中に出して結果を検証していく  そのとき、「早く失敗する」（検証した結果を知る）というのが必要なんです
DevOpsって、なぜ生まれたのでしょう？  どの企業も、レッドオーシャンでビジネスなんかしたくないんです  だから、  新しい分野への進出していく  何らかの付加価値をつけていく  そこは、トライ＆エラーの世界  何が成功するのか、答えは誰も知らない世界です  だから仮説をつくり、それを世の中に出して結果を検証していく  そのとき、「早く失敗する」（検証した結果を知る）というのが必要なんです  「早く失敗する」ことで、  早くビジネスの方向を変えたりすることができる
DevOpsって、なぜ生まれたのでしょう？  どの企業も、レッドオーシャンでビジネスなんかしたくないんです  だから、  新しい分野への進出していく  何らかの付加価値をつけていく  そこは、トライ＆エラーの世界  何が成功するのか、答えは誰も知らない世界です  だから仮説をつくり、それを世の中に出して結果を検証していく  そのとき、「早く失敗する」（検証した結果を知る）というのが必要なんです  「早く失敗する」ことで、  早くビジネスの方向を変えたりすることができる  致命傷になる前にやめられる
MicroServiceArchitecture
 大丈夫です。ひどいニオイかもしれないけど、  鍋は無事です（外から見る限り）  火事になっていないですよ。
「早く失敗する」にはどうしたらいい？
「早く失敗する」にはどうしたらいい？  「構築 – 計測 – 学習」のサイクルをできる限り早く回すことです  このあたりは、リーン開発とかが詳しいみたいです。  深追いはしませんよ。
「早く失敗する」にはどうしたらいい？  「構築 – 計測 – 学習」のサイクルをできる限り早く回すことです  このあたりは、リーン開発とかが詳しいみたいです。  深追いはしませんよ。  ものすご～く大雑把にいうと
「早く失敗する」にはどうしたらいい？  「構築 – 計測 – 学習」のサイクルをできる限り早く回すことです  このあたりは、リーン開発とかが詳しいみたいです。  深追いはしませんよ。  ものすご～く大雑把にいうと  構築： システムの構築や改修  計測： 運用と、そこで得られる様々なデータ  学習： 計測で得られたデータから得た知見
「早く失敗する」にはどうしたらいい？  「構築 – 計測 – 学習」のサイクルをできる限り早く回すことです  このあたりは、リーン開発とかが詳しいみたいです。  深追いはしませんよ。  ものすご～く大雑把にいうと  構築： システムの構築や改修  計測： 運用と、そこで得られる様々なデータ  学習： 計測で得られたデータから得た知見 ⇒このサイクルをできるだけ早くしていきたい
MicroServiceArchitecture
「構築 – 計測 – 学習」サイクルを早めるには
「構築 – 計測 – 学習」サイクルを早めるには  いままで（いまも？）こういった組織構成となることが多かったのでは？  構築：開発部門  計測：運用部門  学習：サービス事業部門
「構築 – 計測 – 学習」サイクルを早めるには  いままで（いまも？）こういった組織構成となることが多かったのでは？  構築：開発部門  計測：運用部門  学習：サービス事業部門  これでは、サイクルを回すのにオーバヘッドがかかってしまいます
「構築 – 計測 – 学習」サイクルを早めるには  いままで（いまも？）こういった組織構成となることが多かったのでは？  構築：開発部門  計測：運用部門  学習：サービス事業部門  これでは、サイクルを回すのにオーバヘッドがかかってしまいます  こういった組織の垣根を取り払ってチーム一丸となる必要があります
「構築 – 計測 – 学習」サイクルを早めるには  いままで（いまも？）こういった組織構成となることが多かったのでは？  構築：開発部門  計測：運用部門  学習：サービス事業部門  これでは、サイクルを回すのにオーバヘッドがかかってしまいます  こういった組織の垣根を取り払ってチーム一丸となる必要があります  でもこれって、とても難しいことなんです。  たとえば
「構築 – 計測 – 学習」サイクルを早めるには  いままで（いまも？）こういった組織構成となることが多かったのでは？  構築：開発部門  計測：運用部門  学習：サービス事業部門  これでは、サイクルを回すのにオーバヘッドがかかってしまいます  こういった組織の垣根を取り払ってチーム一丸となる必要があります  でもこれって、とても難しいことなんです。  たとえば  開発部門 vs サービス just like: “あなた作る人、わたし食べる人”
「構築 – 計測 – 学習」サイクルを早めるには  いままで（いまも？）こういった組織構成となることが多かったのでは？  構築：開発部門  計測：運用部門  学習：サービス事業部門  これでは、サイクルを回すのにオーバヘッドがかかってしまいます  こういった組織の垣根を取り払ってチーム一丸となる必要があります  でもこれって、とても難しいことなんです。  たとえば  開発部門 vs サービス just like: “あなた作る人、わたし食べる人”  開発部門 vs 運用部門 just like: “変化”を好む vs “安定”を好む
 それぞれを、もう少し細かくみていきます
「構築 – 計測 – 学習」サイクルで 必要とされる「構築」とは？  「構築 - 計測 - 学習」サイクルを回していくためには  「構築」にかかる時間を短くする必要があります。
「構築 – 計測 – 学習」サイクルで 必要とされる「構築」とは？  「構築 - 計測 - 学習」サイクルを回していくためには  「構築」にかかる時間を短くする必要があります。  日本では、ここで「アジャイル開発が必要！」となります。
「構築 – 計測 – 学習」サイクルで 必要とされる「構築」とは？  「構築 - 計測 - 学習」サイクルを回していくためには  「構築」にかかる時間を短くする必要があります。  日本では、ここで「アジャイル開発が必要！」となります。  でも海外では、そうはなりません。なぜならアジャイルが普通だからです。
「構築 – 計測 – 学習」サイクルで 必要とされる「構築」とは？  「構築 - 計測 - 学習」サイクルを回していくためには  「構築」にかかる時間を短くする必要があります。  日本では、ここで「アジャイル開発が必要！」となります。  でも海外では、そうはなりません。なぜならアジャイルが普通だからです。  「私は間違っていた。ごめん。ウォーターフォールは何のメリットもない」 in メソッド屋のブログ  http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
「構築 – 計測 – 学習」サイクルで 必要とされる「構築」とは？  「構築 - 計測 - 学習」サイクルを回していくためには  「構築」にかかる時間を短くする必要があります。  アジャイル開発では、 変化を受容する
「構築 – 計測 – 学習」サイクルで 必要とされる「構築」とは？  「構築 - 計測 - 学習」サイクルを回していくためには  「構築」にかかる時間を短くする必要があります。  アジャイル開発では、 変化を受容する  そこには仮説に沿った「構築」を行う素地が既にある
MicroServiceArchitecture
「構築 – 計測 – 学習」サイクルに おける「学習」とは？  仮説を立てる
「構築 – 計測 – 学習」サイクルに おける「学習」とは？  仮説を立てる  仮説のもととなるデータは「計測」のなかで取得される
「構築 – 計測 – 学習」サイクルに おける「学習」とは？  仮説を立てる  仮説のもととなるデータは「計測」のなかで取得される  フィードバックから、仮説が正しかったのかを検証する
「構築 – 計測 – 学習」サイクルに おける「学習」とは？  仮説を立てる  仮説のもととなるデータは「計測」のなかで取得される  フィードバックから、仮説が正しかったのかを検証する  フィードバックは「計測」からもたらされる
「構築 – 計測 – 学習」サイクルに おける「学習」とは？  仮説を立てる  仮説のもととなるデータは「計測」のなかで取得される  フィードバックから、仮説が正しかったのかを検証する  フィードバックは「計測」からもたらされる  進む方向を決定する
MicroServiceArchitecture
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」のために
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」のために  「構築 - 計測 - 学習」サイクルを回していくためには  「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」のために  「構築 - 計測 - 学習」サイクルを回していくためには  「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。  環境の作成の高速化
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」のために  「構築 - 計測 - 学習」サイクルを回していくためには  「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。  環境の作成を機械化  仮想化、コンテナ
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」のために  「構築 - 計測 - 学習」サイクルを回していくためには  「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。  環境の作成の高速化  仮想化、コンテナ  Infrastructure As Code
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」のために  「構築 - 計測 - 学習」サイクルを回していくためには  「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。  環境の作成の高速化  仮想化、コンテナ  Infrastructure As Code  Blue Green Deployment
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」のために  「構築 - 計測 - 学習」サイクルを回していくためには  「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。  環境の作成の高速化  仮想化、コンテナ  直接、機械を触る必要がなくなる  Infrastructure As Code  Blue Green Deployment
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」のために  「構築 - 計測 - 学習」サイクルを回していくためには  「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。  環境の作成の高速化  仮想化、コンテナ  直接、機械を触る必要がなくなる  Infrastructure As Code  人間が１台ずつ設定していく必要がなくなる  Blue Green Deployment
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」のために  「構築 - 計測 - 学習」サイクルを回していくためには  「測定」をする環境の作成にかかる時間を、短くする必要があります。 ※「測定」する対象も重要なのですが、ここでは割愛。  環境の作成の高速化  仮想化、コンテナ  直接、機械を触る必要がなくなる  Infrastructure As Code  人間が１台ずつ設定していく必要がなくなる  Blue Green Deployment  設定は必要になったタイミングで都度、実施  いらなくなったら、全部リセット
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」とは？
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」とは？  仮説を構築するためのデータを提供する
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」とは？  仮説を構築するためのデータを提供する  仮説を検証するためのフィードバックを提供する
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」とは？  仮説を構築するためのデータを提供する  仮説を検証するためのフィードバックを提供する  「学習」のプロセスでは上記が視覚化されることが必要
「構築 – 計測 – 学習」サイクルで 必要とされる「測定」とは？  仮説を構築するためのデータを提供する  仮説を検証するためのフィードバックを提供する  「学習」のプロセスでは上記が視覚化されることが必要  視覚化を「計測」「学習」のどちらでやるかは、考えなくてもよいと思う。  チーム一丸なので、どちらでも。
 そろそろ「マイクロサービス」の話を
ひとつの巨大なシステムでは、 「構築 - 計測 - 学習」サイクルを早く回せない
ひとつの巨大なシステムでは、 「構築 - 計測 - 学習」サイクルを早く回せない  リリースには時間がかかります
ひとつの巨大なシステムでは、 「構築 - 計測 - 学習」サイクルを早く回せない  リリースには時間がかかります  部署間の調整  システムの影響範囲の調査
ひとつの巨大なシステムでは、 「構築 - 計測 - 学習」サイクルを早く回せない  リリースには時間がかかります  部署間の調整  システムの影響範囲の調査  スケールアウトではなく、スケールアップが選択肢となることが多い
ひとつの巨大なシステムでは、 「構築 - 計測 - 学習」サイクルを早く回せない  リリースには時間がかかります  部署間の調整  システムの影響範囲の調査  スケールアウトではなく、スケールアップが選択肢となることが多い  チームや組織、コンポーネントの関係が密になりすぎているわけです
ひとつの巨大なシステムでは、 「構築 - 計測 - 学習」サイクルを早く回せない  リリースには時間がかかります  部署間の調整  システムの影響範囲の調査  スケールアウトではなく、スケールアップが選択肢となることが多い  チームや組織、コンポーネントの関係が密になりすぎているわけです  この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず）  APIを通じて、お互いがコミュニケーションすればよい
ひとつの巨大なシステムでは、 「構築 - 計測 - 学習」サイクルを早く回せない  リリースには時間がかかります  部署間の調整  システムの影響範囲の調査  スケールアウトではなく、スケールアップが選択肢となることが多い  チームや組織、コンポーネントの関係が密になりすぎているわけです  この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず）  APIを通じて、お互いがコミュニケーションすればよい  スケールアップではなく、スケールアウトが選択肢となる
ひとつの巨大なシステムでは、 「構築 - 計測 - 学習」サイクルを早く回せない  リリースには時間がかかります  部署間の調整  システムの影響範囲の調査  スケールアウトではなく、スケールアップが選択肢となることが多い  チームや組織、コンポーネントの関係が密になりすぎているわけです  この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず）  APIを通じて、お互いがコミュニケーションすればよい  スケールアップではなく、スケールアウトが選択肢となる ⇒これが、「マイクロサービス・アーキテクチャ」の原型です
ひとつの巨大なシステムでは、 「構築 - 計測 - 学習」サイクルを早く回せない  リリースには時間がかかります  部署間の調整  システムの影響範囲の調査  スケールアップ  チームや組織、コンポーネントの関係が密になりすぎているわけです  この密接すぎる関係を解決すれば、チーム、組織が自由にリリースできる（はず）  APIを通じて、お互いがコミュニケーションすればよい  スケールアップではなく、スケールアウトが選択肢となる ⇒これが、「マイクロサービス・アーキテクチャ」の原型です 「マイクロサービス・アーキテクチャ」は、 現実世界の課題を解決しようと 試行錯誤したうえで出てきたもの
マイクロサービス・アーキテクチャの一般化  ２０１４年、マーティン・ファウラーとジェームス・ルイスにより  「マイクロサービスの前提条件」という記事を公開 ※http://martinfowler.com/articles/microservices.html  現在、マイクロサービスについて議論されるときは、この記事の内容が意識されている（はず）
「マイクロサービス・アーキテクチャ」へ  トップダウンで、こちらに舵を切ることが重要です  ボトムアップではうまくいきません。
「マイクロサービス・アーキテクチャ」へ  トップダウンで、こちらに舵を切ることが重要です  ボトムアップではうまくいきません。  組織を変更する必要があります
「マイクロサービス・アーキテクチャ」へ  トップダウンで、こちらに舵を切ることが重要です  ボトムアップではうまくいきません。  組織を変更する必要があります  「失敗」を糧とする文化が必要です
 以上です。
おまけ（時間が余れば）  実際に構築するマイクロサービス（のようなもの）を構築するなら  “The Tweleve-Factor App”(http://12factor.net/)を知っていたほうがいいです  日本語訳もあります（http://12factor.net/ja/）
謝辞  今回、スライドに利用した画像は、こちらのサイトよりお貸しいただきました
さいごに  ご清聴ありがとうございました

More Related Content

PDF
[Slide]闇アジャイラーvs光アジャイラーforDevLOVE(EnergizedWorkLT祭)
masashi takehara
 
PDF
アジャイル開発の現在・過去・未来～今を知り、源流を訪ね、先を見据える～
Kenji Hiranabe
 
PDF
【17-E-1】自動化はどこに向かうのか～まだ開発・運用の自動化で消耗しているの？～
Masahito Zembutsu
 
PDF
『運用屋さんのためのVBA入門』 ～ 運用方法論 運用工程設計・自動化概論 〜
Hirokazu Hatano
 
PDF
ソフトウェア設計のすすめ
Yoshimura Soichiro
 
PDF
2015.08.29 JUS共催勉強会資料
umidori
 
PDF
Why Agile Now ? - leanstartup and ARC
Kenji Hiranabe
 
PDF
金融業界向けセミナー 量子コンピュータ時代を見据えた組合せ最適化
Fixstars Corporation
 
[Slide]闇アジャイラーvs光アジャイラーforDevLOVE(EnergizedWorkLT祭)
masashi takehara
 
アジャイル開発の現在・過去・未来～今を知り、源流を訪ね、先を見据える～
Kenji Hiranabe
 
【17-E-1】自動化はどこに向かうのか～まだ開発・運用の自動化で消耗しているの？～
Masahito Zembutsu
 
『運用屋さんのためのVBA入門』 ～ 運用方法論 運用工程設計・自動化概論 〜
Hirokazu Hatano
 
ソフトウェア設計のすすめ
Yoshimura Soichiro
 
2015.08.29 JUS共催勉強会資料
umidori
 
Why Agile Now ? - leanstartup and ARC
Kenji Hiranabe
 
金融業界向けセミナー 量子コンピュータ時代を見据えた組合せ最適化
Fixstars Corporation
 

Similar to MicroServiceArchitecture (20)

PPTX
Engineer is Hero !! DevOps MSA and AI
Yoshio Terada
 
PPTX
Relationship betweenddd and mvc
Takao Tetsuro
 
PPTX
20180525 system department manager microservices
kounan13
 
PDF
設計/アーキテクチャ設計 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第19回】
Tomoharu ASAMI
 
PDF
クラウド運用のためのストリームマイニング
Shin Matsumoto
 
PDF
ソーシャルウェブ と レコメンデーション －第４回データマイニング+WEB勉強会＠東京
Koichi Hamada
 
PDF
企画プロセスツールキット2011
Kent Ishizawa
 
PDF
マイクロサービス時代の動画配信基Ruby×go=∞
DMM.com
 
PDF
Azure アプリケーション アーキテクチャ ガイド 紹介
Kazuyuki Nomura
 
PDF
20230206_SD輪読＆座談会#41_kitazaki.pdf
Ayachika Kitazaki
 
PDF
【de:code 2020】 SaaS で迅速に IoT を実現 - Azure IoT Central 最新アップデートと活用術
日本マイクロソフト株式会社
 
PPTX
Kspin20121201 kobayashi
Osamu Kobayashi
 
PDF
DSL駆動によるクラウド・アプリケーション開発
Tomoharu ASAMI
 
PDF
Mahout Canopy Clustering - #TokyoWebmining 9
Koichi Hamada
 
PDF
デブサミ2010 これからのアーキテクチャを見通す
Yusuke Suzuki
 
PDF
minneで学ぶクラウド脳
Uchio Kondo
 
PDF
DX認定制度システム開発裏話：技術編
Arichika TANIGUCHI
 
PDF
モダンな開発現場になるためのお作法としてのツール活用
智治 長沢
 
PDF
インフラセキュリティブートキャンプ #seccamp
Masahiro NAKAYAMA
 
PDF
実装(1) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第30回】
Tomoharu ASAMI
 
Engineer is Hero !! DevOps MSA and AI
Yoshio Terada
 
Relationship betweenddd and mvc
Takao Tetsuro
 
20180525 system department manager microservices
kounan13
 
設計/アーキテクチャ設計 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第19回】
Tomoharu ASAMI
 
クラウド運用のためのストリームマイニング
Shin Matsumoto
 
ソーシャルウェブ と レコメンデーション －第４回データマイニング+WEB勉強会＠東京
Koichi Hamada
 
企画プロセスツールキット2011
Kent Ishizawa
 
マイクロサービス時代の動画配信基Ruby×go=∞
DMM.com
 
Azure アプリケーション アーキテクチャ ガイド 紹介
Kazuyuki Nomura
 
20230206_SD輪読＆座談会#41_kitazaki.pdf
Ayachika Kitazaki
 
【de:code 2020】 SaaS で迅速に IoT を実現 - Azure IoT Central 最新アップデートと活用術
日本マイクロソフト株式会社
 
Kspin20121201 kobayashi
Osamu Kobayashi
 
DSL駆動によるクラウド・アプリケーション開発
Tomoharu ASAMI
 
Mahout Canopy Clustering - #TokyoWebmining 9
Koichi Hamada
 
デブサミ2010 これからのアーキテクチャを見通す
Yusuke Suzuki
 
minneで学ぶクラウド脳
Uchio Kondo
 
DX認定制度システム開発裏話：技術編
Arichika TANIGUCHI
 
モダンな開発現場になるためのお作法としてのツール活用
智治 長沢
 
インフラセキュリティブートキャンプ #seccamp
Masahiro NAKAYAMA
 
実装(1) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第30回】
Tomoharu ASAMI
 
Ad

MicroServiceArchitecture

Editor's Notes

  • #33: それぞれの組織が、自己の「責任」を果たそうとする とても正しく、素晴らしいことで、それを否定するつもりはないのです （誤解されそうなので、ここ強調！）
  • #37: 一丸となるには、結集軸が必要となります。 ・自分の組織や仕事への影響は出るでしょうが、それを甘受できるようになるなにかが。
  • #61: アジャイル開発が隆盛：２０００年前後。 ２００１年、「アジャイルソフトウェア開発宣言」 一方、MapReduceのGoogleの論文は、2004年
  • #63: アジャイル開発が隆盛したときには、まだこの、計測は難しかった。 ２００１年、「アジャイルソフトウェア開発宣言」 一方、MapReduceのGoogleの論文は、2004年
  • #64: アジャイル開発が隆盛したときには、まだこの、計測は難しかった。 ２００１年、「アジャイルソフトウェア開発宣言」 一方、MapReduceのGoogleの論文は、2004年
  • #65: アジャイル開発が隆盛したときには、まだこの、計測は難しかった。 ２００１年、「アジャイルソフトウェア開発宣言」 一方、MapReduceのGoogleの論文は、2004年
  • #76: 「発見」っていうのは言い過ぎなので、訂正
  • #78: http://readwrite.jp/startup/29950 に失敗を従容すること そして有名な６原則が書かれている。 英語だと、こちら？ http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/ 「Amazonは一つのことだけに携わる小さなチームの集まりで出来ており、そのために急速なイノベーションが可能になっている」とベゾス氏は述べている。 これらのチームは、以下にある「公開されたAPI」に（強制的に）沿って互いにコミュニケーションを取っている。 　－全てのチームはサービスインターフェイスを通じてその機能やデータを公開しなければならない。 　－チームのコミュニケーションはインターフェイスを通じて行われる。 　－インターフェイスを通じたもの以外のあらゆるプロセス間通信は許可されない。 　　直接的にリンクすること、他のチームのデータを直接見ること、共有メモリモデルによる 　　コミュニケーション、バックドアやその他の手段すべてに対してこれは適用される。 　　唯一許可されるコミュニケーションは、ネットワーク越しにインターフェイスを叩くことのみである。 　－どのようなテクノロジーを使っていたとしてもこのルールは変わらない。 　－どのようなサービスインターフェイスも例外なく公開されることを前提に、 　　根底からデザインされなければならない。つまり、チームはインターフェイスを 　　開発者に公開できるようにプラン設計を行わなければならない。例外は認められない。 そして、これらを選択肢の1つだと考えているAmazonの従業員たちに対し、ベゾス氏はこう締めくくっている。 「これを守れない社員はクビにする。では、今日もいい日を」