マイクロサービスを構築することから学んだ一つの教訓

2026年おめでとうございます！

昨年の目標の一つは、もっと本を読むことでした。3冊という控えめな数字で年を終えましたが、2024年の1冊という数字からは改善されています。

私が読んで多くのことを学んだ本の一つは、Sam Newmanの「Building Microservices（第2版）」でした。この本から得た何百、いや何千もの教訓について話すことができますが、特に今システムを構築している全ての人に覚えておいてほしい教訓が一つあります：なぜマイクロサービスを採用するのか。

マイクロサービスは、他のサービス指向アーキテクチャやモノリスよりもスケールしやすいと言われていますが、それらがもたらす複雑さは、モノリスをスケールするために必要な複雑さよりも大きいことがよくあります。マイクロサービスの選択は、アーキテクチャ上の決定というよりも、組織上の決定です。これにより、チームは顧客にエンドツーエンドで独立して価値を提供できます。チームが一つ以上の製品価値パイプラインを所有することを可能にし、製品の疎結合、チームの責任、そして正しく行われた場合は配信速度を高めます。注：配信速度についてもっと知りたい場合は、本を読むことをお勧めします。本全体を通して、デプロイメントの疎結合と配信の健全性に関する素晴らしい洞察があります。

これは、NetflixやAmazonのような企業が、チームを非常に有能な人々（フロントエンド、バックエンド、インフラストラクチャ、ネットワーキングなど）の小さなグループに分割し、全体システムの非常に小さな部分に責任を持たせる方法を反映しています。この構造により、チームは互いに疎結合され、マイクロサービス内で顧客にとって最善のことを決定する権限を与えられます。もちろん、これには長い長所と短所のリストが付いてきますが、本当にそれらを探求したい場合は、本を読むことをお勧めします。

これの素晴らしい例がコンウェイの法則そのものです：

画像クレジット：「Conway's Law」— Sketchplanations by Jono Hey

チームが自律的でドメインに焦点を当てたユニットに分離されると、自然に独立した疎結合のアーキテクチャを作成します。この構造により、彼らは特定のドメインの所有者となり、それが顧客やステークホルダーへの価値提供を簡素化し、加速させます。

タグ: microservices