１章 マイクロサービス
ヘキサゴナルアーキテクチャ
アプリケーションとドメインを中心に据え、プロトコルやDB、ストレージなどのインフラはポート＆アダプターで接続するアーキテクチャ。
⇒ ドメイン・セントラルな考え方であると理解。
システム大規模化の問題とは？
変更の必要な個所が分かりづらい
- 大きなシステムほど調査に時間がかかるし、変更するとテスト工数が大幅に増えてしまうというのはよくある事実。
似たような機能が散在し、バグの修正や実装が困難になる
- チーム別に類似コードが実装されており、影響調査依頼などで横展開されるが、担当者の前提知識によっては見逃されてしまうリスクがある。
対策にはコードの凝集性がポイントである
- 同じ役割のコードは「まとめておく」という考え方。
- 気になるのは、組織分割と役割分割は必ずしも一致しないこと。
- 現場では共有ライブラリ、モジュールの考え方がすぐに復活してしまうのが怖い。
単一責任の原則
- マイクロサービスでも重要な概念である。
変更する理由が同じものは集める、変更する理由が違うものは分ける
マイクロサービスのアプローチは？
- サービスの境界をビジネスの境界に合わせる。
⇒そもそものビジネス境界の定義が現場ではとても難しい（業種等によるだろうが）
⇒事務所管で分ける方法もあるが、事務処理自体も便宜的に振り分けられているものも多く、ビジネスとしての境界とは少し違う場合がある（事務所管は別だが、同じところを見ている、つついているといった状況）
マイクロサービスの最適なサイズとは？
- ２週間で書き直せるもの（Jon Eaves）
- 十分に小さく、ちょうどいい大きさであること
- 小ささはわからずとも、大きすぎるということは容易に理解できるだろう
- サービスがチーム構造とどの程度一致しているかも重要（組織面）
- 注意すべきは、サービスが小さいほど、マイクロサービスアーキテクチャの利点と欠点が最大化されること
【重要】自律性の黄金律
- 他は何も変更せずに、単独でサービスの変更やデプロイを行えるかどうか。
マイクロサービスの利点とは？
①技術異質性
- サービスごとに異なる技術を使うことができる。
- 運用を考えると、いろんな技術を使えないのでは？
②回復性（レジリエンス）
- サービス境界は明確な隔壁になる
- 障害が連鎖しないようにする隔壁が重要な考え方になる
- 隔壁があれば問題を分離し、残りの部分は機能し続けることができる
③スケーリング
- 必要な部分だけをスケールさせることができる
- モノリシックでは、必要な部分だけでなく全体をスケールさせる必要がある
④デプロイの容易性
- モノリシックなアプリケーションは全体をデプロイする必要がある
- マイクロサービスはサービス単位に独立してデプロイできる
- 問題の特定、ロールバックが迅速に対応可能
⑤組織面の一致
- 大規模なコードベースは問題が起きやすい
- 小規模チームの方が生産性が高い傾向にある
- マイクロサービスはコードベースを組織に合わせやすい
⑥合成可能性
- モノリシックアプリケーションでは外部からの入り口は粒度のあらいものがひとつある
- マイクロサービスでは、状況の変化に応じて組み立てなおせるようにできる（これを合成可能性といっているようだ）
- 実際、顧客チャネルとしてはWeb、ネイティブアプリケーション、モバイルWeb、タブレットアプリ、ウェアラブルなど多くのものが考えられる
⑦交換可能にするための最適化
- レガシーシステムでは古いプログラムが古いプラットフォーム上で動いている
- これに手をつけない、つけたくない理由は、大きすぎるゆえにリスクがあるため
- 個々のサービスサイズが小さければ、交換がしやすくなる
サービス指向アーキテクチャ（SOA）
- SOAでは、その考え方を適切に実現する方法について、十分な合意がされていなかった
- また、説明不足を原因として、多くの落とし穴が生じてしまった
マイクロサービス以外の分解テクニック
共有ライブラリ
- ごく標準的な分解テクニック
- メリット
- ライブラリを中心に組織化できる。
- デメリット
- 技術的多様性がない、通常は同じ言語かプラットフォームになる。
- 独立してスケールさせることはできない。 など
モジュール
- モジュールは接合部分が標準化・規格化されているものをいう。
- 言語によってはモジュールのライフサイクル管理が可能だが、すぐに他のコードと密結合になってしまう。
銀の弾丸などない
- 魔法のように、すぐに役に立ちプログラマの生産性を倍増させるような技術や実践はない。