これもおすすめされたので読んでみました。 結構読むのに時間がかかった印象だったけど、意外と前回の読書エントリーから1ヶ月くらいしかあいてないのでいつもどおりのペースっぽい。 内容の割には時間がかかってる、みたいなのはあったかも知れない。
本書は、モノリスからマイクロサービスアーキテクチャへと移行するための実践的なガイドです。マイクロサービスが自分たちのシステムに適しているかを判断するところから、ビジネスを維持しながらモノリシックなシステムを少しずつマイクロサービスに切り替えていく方法、さらには、マイクロサービスアーキテクチャが成長するにつれて起こる課題への対処の仕方まで、豊富な例やシナリオを用いて解説します。また、モノリスやデータベースを分解していくのに役立つ様々なパターンやテクニックも扱います。
以下気になった点をメモ。
- マイクロサービスは選択肢を買い与える
マイクロサービスにはコストがあり、そのコストが手にしたい選択肢に見合うものかどうかを判断しなければならない
- 前評判通り割とずっとこういう話が書かれている
- ジョン・コッターの8段階のプロセス： 企業変革は正しい手順で進めよ | GLOBIS 知見録
これが組織変革のための唯一のモデルというわけではないが、私はもっとも役立つモデルの1つだと考えている。
- 各ステップについてこういう感じで考えると良いよみたいなことが書いてある
- 2つの意思決定 - タイプ１vs. タイプ２
タイプ1やタイプ2といった用語はあまり説明的ではなく、実際に何を意味するのかを覚えるのは難しい。そこで、私はタイプ1を不可逆的、タイプ2を可逆的と呼ぶことにしている。
- 不可逆的な意思決定は慎重に行う必要があるが、可逆的な意思決定は比較的気軽に行え、マイクロサービスアーキテクチャへの移行は後者であるとのこと
- 実際は不可逆的な意思決定と可逆的な意思決定のどちらかではなくグラデーションの中にあるとのこと
- 答えではなく、問いを模倣しよう
他の組織が行ってきたことからインスピレーションを得ることは確かにある。しかし、他の組織が行ってきたことが自分の文脈でも通用すると決めつけてはいけない。
他所の構造を真似してはいけないのだとしたら、どこから始めればいいのだろうか？ デリバリーチームの役割を変えようとしている組織と仕事をするとき、私はまず、その企業内でソフトウェアのデリバリーに関わる全ての活動と責任を明確にリストアップすることから始めるようにしている。そして、その次に、それらの活動を既存の組織構造にマッピングする。
- 答えを模倣しがちなのでこの指針は便利そう
- 最近自分が考えたことでいうと、このあたりが近いんだろうなと思っている: 開発プロセスの変遷モデル - shimobayashiパブリック
- トランザクション
- 2相コミット - Wikipedia
- サガパターン - AWS規範的ガイダンス
私の経験では、ビジネスプロセスをサーガとして明示的にモデル化することで、分散トランザクションの課題の多くを回避できる。
- ハイアウトプットマネジメントかなんかでも文章そのものよりも文章化を通じて得られた理解の方が大事であり目的みたいな話があった気がするけど、そういった点も含めてサーガがおすすめであるケースが多いとのこと
マイクロサービスアーキテクチャへの移行を直近で検討しているわけではないので、個人的にはこのあたりが気になった。
マイクロサービスアーキテクチャへの移行に限らずシステムの段階的移行に使えそうなノウハウが色々と書かれていて、題名から受ける印象よりも広い範囲で使える内容の本だと思う。
ちなみに、オライリーの本なのでKindle版は無くてオライリーの電書ストアでePubを買うことができる。 エラスティックリーダーシップとかと違ってPDFではなくePubなので、Google Play Bookとかにインポートしてもちゃんとハイライトとかできて快適。 Kindleだとコピー制限だのなんだのがあるけどGoogle Play Bookだとそういうの無いので、個人的にはどちらか選べるならGoogle Play Bookのほうが好み。
次は何を読もうかな。
