課題図書
デッドライン読書会#04の課題図書はオライリー社の「マイクロサービスアーキテクチャ（前半）」です。前半の範囲は１章〜６章でした。表紙はミツバチです。
※デッドライン読書会とは何かについてはこちらのポスト：「読書×締切ではじめる「デッドライン読書会」を始めました」をご参照ください。
本を読んだ感想
本書について
本書はオライリー・ジャパンから2016年に出版されました。今回の範囲の章は次のとおりです。
- 1章：マイクロサービス
- 2章：進化的アーキテクト
- 3章：サービスのモデル化方法
- 4章：統合
- 5章：モノリスの分割
- 6章：デプロイ
運用やセキュリティ、スケーリングは7章以降になります。
前半全体
書名としてマイクロサービスアーキテクチャ（以降、MSAと略）でのアプリケーション構築・開発の詳細を議論しているのかと思いましたが、少し上位概念が多い印象。しかしながらよく考えてみれば、それはそうで、組織とアプリ/システムが一致するコンウェイ法則を体現したようなアーキテクチャ（というよりか、パターン？）であることからも、開発プロセス（CI、CDなど）、設計論（DDD）、インフラのあり方（インフラ構築の自動化、クラウド）、組織のあり方も関連するとなると、それなりに語るべき範囲は広くなるんだなぁと認識しました。
1章でそうそうに「MSAは銀の弾丸じゃないよ」と著者も言っており、その後の内容も慎重なイメージがありました。マイクロサービス化するための境界線の見つけ方、そのタイミングは適切な位置をじっくり時間をかけ把握し掴んでから実施すべしとのこと。
私自身MSAのアプリは作ったことがないですが、APIベースのアプリなら経験はちょっとあります。それを踏まえて具体的に学びに繋がった箇所について以下「個別」でまとめておこうかと思います。
個別
- MSAにおけるデータの持ち方
- サービス間でのDB統合は極力避けるべし。
- DB上のトランザクションが完結するように、マイクロサービスの境界を作るべし。
- REST/JSONだけが王道ではない
- サポートツールが優れているからとの理由で、著者はややXMLを推している。
- でも今ではますますJSONがデファクトかとも思います。
- APIエンドポイントのバージョンニングにおける過去バージョンの維持方法
- 内部的にV1エンドポイントへのすべてのリクエストをV2リクエストに変換する。これによりアプリ全体を二重に管理・メンテナンスすることを防ぐことができる。
- ユーザインターフェイスの作り方
- API合成するか、UI部品合成するか、フロントエンド向けバックエンド（BFF）を作るか、などの手法が選択できる。
- アーキテクトは都市計画家
- なるほど、詳細に立ち入れないときもあるが、システム全体（都市全体）と、それぞれのマイクロサービスの役割（土地の用途）、マイクロサービス間のIF（道！？）に着目することが重要な任務。私としてはイメージしやすかった良いメタファーでした。
次回（#05）
スケジュールはGoogleカレンダーで分かるようにしています。第5回は次の要領です。
- 書籍
- マイクロサービスアーキテクチャ
- 後半戦、７章〜最後まで
- デッドライン
- 感想交換1Week（6/12〜17）
- 読書する時間2Week（6/18～7/1）
- ブログポスト期限（7/2）
- 感想交換1Week（7/3-8）
コメント
[…] ← デッドライン読書会#04「マイクロサービスアーキテクチャ（前半）」… […]
[…] […]