第IV部 ケーススタディ ・ 第20章
本章は「ドキュメント20-1：モノリスを分解すべきか？」（2022年執筆）の1本のみを掲載する。マイクロサービスは2005年に紹介されて以来、最も後戻りのきかない意思決定の1つとされてきたが、業界の関心は一周して戻りつつある。2010年代に多くの大規模事業者がモノリスからマイクロサービスへの移行に取り組んだが、Kelsey Hightower の2017年の象徴的なツイート「分散モノリシックアプリケーションの欠点にみんなが気づいたら、モノリシックアプリケーションが再び流行するだろう」が示すように、現在は両方を少しずつ抱える組織が多い。本章は、両アプローチを中途半端に抱えて身動きが取れなくなった架空の組織「Theoretical Compliance Company」を取り上げる。著者は方針だけでなく探究と診断まで読むことを勧めている。
方針の骨子は次のとおり。第一に、ビジネスユニット（事業単位）ごとに独自のコードリポジトリでモノリスから独立して活動できるべきだが、多数のサービスをプロビジョニングするべきではない。つまり、他のビジネスユニットのモノリスで作っても十分なら、判断に迷う限界的なケースでは「分割しない」を選ぶ。第二に、ビジネスユニットのモノリス間で通信が必要な場合は、gRPC を使い「新規の」連携を作る。他の改修（HTTP/JSON など）を使っている既存の通信は、移行が必要なほどの問題がない限り無理に変えない（緊急ではない改修）。第三に、新しいビジネスユニットのモノリスを作る際は、新しいサービスのインフラ作成は許可する。
追加の留意点として、可能であれば既存のサービスをビジネスユニットに統合する。既存サービスをモノリスに戻すかどうかは判断の難しいケースだが、トップダウンの強制移行はせず、自然な改修のタイミングで寄せていく。基本的には2段のサービス（ビジネスユニットのモノリス＋それ以下のサービス）に留めることを目指す。
探究と診断のパートでは、Theoretical Compliance Company の現状を率直に分析する。同社は B2B 向けのコンプライアンスソリューションを複数提供しており、構成は複雑だ。約500名のエンジニアと2,000のサービスを抱え、その500名のエンジニアリング組織に組織全体としては機能しているが、サービスとサービスの間に多数のオーケストレーション・ネットワーク・セキュリティのレイヤーが挟まり、コストが膨らんでいる。事業の利益率も毎年5〜10%のフリーキャッシュフローの改善が求められる水準にあり、運営コストの圧縮が経営課題になっている。
診断の核心は、サービスを過剰に増やしすぎたことの代償だ。新プロジェクトごとに平凡なサービスを次々と作る慣習が、横断的な調整コスト・インフラのオーバーヘッド・移行の難しさを生んでいる。サービスが多すぎると、どのコードがどこで動くかを把握しづらくなり、緊急時の対応も遅れる。判断に迷う限界的なケースでは、新サービスを足すよりプラットフォームチームの提供する共通基盤に寄せるほうが、無駄を減らせる。インフラストラクチャを支えるプラットフォームチームへの負荷を増やさない余地もここに残されている。
著者は、自社の B2B コールセンターのケースなど具体例を引きながら、サービス分割の判断は「コードベースとして独立して動くべきか」「2段構成に収まるか」というシンプルな問いに落とし込めると示す。トップダウンの一斉移行ではなく、自然な改修のタイミングで段階的に寄せる現実路線を採る。最後に著者は、この方針が Stripe・Calm・Carta のいずれを題材にしてもほぼ同じ内容になっただろうと述べ、細部は企業ごとに違っても大枠の考え方は企業をまたいで適用可能だと結論づける。
効果的な戦略を見極めるうえで細部は極めて重要だが、本ドキュメントが示すとおり、戦略の大枠は企業をまたいで適用できる。著者は、ある企業の具体的なアプローチをそのまま別の企業にコピーしようとすれば悲惨な結果を招くだろうと釘を刺す。一方で、大枠の考え方（流行ではなくコストと制約から判断し、限界的なケースでは分割しないを選び、段階的に寄せる）を適用する分には、非常にうまくいったと振り返る。サービスアーキテクチャの判断は、技術的な流行論ではなく、自社の制約・コスト・運用負荷から導くべきだというのが本章の核心である。