マイクロサービスアーキテクチャパターンは、単一のアプリケーションを、それぞれが独自のプロセスで実行され、軽量メカニズム（多くの場合、HTTPリソースAPI）で通信する小さなサービスのスイートとして開発するアプローチです。これらのサービスはビジネス機能を中心に構築され、完全に自動化されたデプロイメント機構によって独立してデプロイ可能です。これらのサービスの集中管理は最小限であり、異なるプログラミング言語で記述され、異なるデータストレージテクノロジーを使用する場合があります。その利点から近年非常に流行していますが、分散化の増加、整合性��低下といったコストが伴い、運用管理における成熟度が求められます。

「マイクロサービスアーキテクチャ」という用語は、ここ数年で、ソフトウェアアプリケーションを独立してデプロイ可能なサービスのスイートとして設計する特定の方法を説明するために登場しました。このアーキテクチャスタイルの正確な定義はありませんが、ビジネス機能を中心とした組織化、自動化されたデプロイメント、エンドポイントのインテリジェンス、言語とデータの分散制御など、いくつかの共通の特徴があります。

新しいアーキテクチャ用語と同様に、マイクロサービスとは何かを適切に定義することは難しいので、この講演では、関心を高めたジェームズと私の記事に基づいて、その問題に取り組むことから始めます。次に、マイクロサービスとSOAを比較し、アーキテクチャをよりモノリシックなアプローチと比較し、マイクロサービスアプリケーションをデプロイする前に正しく理解しておくべき重要な点を概説します。

モノリシックシステムが大きくなりすぎて扱えなくなるにつれて、多くの企業はそれらをマイクロサービスアーキテクチャスタイルに分割することに魅力を感じています。それは価値のある旅ですが、簡単なものではありません。私たちは、これをうまく行うには、単純なサービスから始める必要があるが、その後、ビジネスにとって重要であり、頻繁に変更される垂直方向の機能に基づいたサービスを引き出す必要があることを学びました。これらのサービスは最初は大きく、できれば残りのモノリスに依存しないようにする必要があります。移行の各ステップがアーキテクチャ全体に対するアトミックな改善を表すようにする必要があります。

gotoカンファレンスは、Sam Newman氏の著書「Monoliths to Microservices」についてインタビューを行うよう依頼してきました。これは、マイクロサービスとそれらをいつ使用するかについての一般的な会話になりました。Sam氏は、マイクロサービスの3つの主な理由を、独立したデプロイ可能性、データの分離、組織構造の反映であると考えています。私は最初のものについてはより懐疑的ですが、データと人々はソフトウェア開発の複雑な部分であると考えています。

分散システムは、プログラムに特定の課題をもたらします。多くの場合、複数のデータコピーを保持し、それらを同期させる必要があります。しかし、処理ノードが確実に機能すると信頼することはできず、ネットワークの遅延によって簡単に不整合が発生する可能性があります。それにもかかわらず、多くの組織は、データストレージ、メッセージング、システム管理、計算機能を処理する、一連のコア分散ソフトウェアに依存しています。これらのシステムは、同様のソリューションで解決する共通の問題に直面しています。2020年、Unmesh Joshi氏はこれらのソリューションをパターンとして収集し始め、開発を進めながらこのサイトに公開しました。2023年には、これらが「Patterns of Distributed Systems」という本で出版されました。このページでは、各パターンの簡単な要約と、oreilly.comのオンラインeBook出版物の関連チャプターへのディープリンクを提供しています。

モノリスを小さなサービスに分割する場合、最も難しい部分は、実際にはモノリスのデータベースに存在するデータを分割することです。データリッチサービスを抽出するには、常にデータの単一の書き込みコピーを保持する一連のステップに従うと便利です。この手順は、既存のモノリスを論理的に分離することから始まります。サービスの動作を個別のモジュールに分割し、次にデータを個別のテーブルに分割します。これらの要素は、新しい自律型サービスに個別に移動できます。

優れたフロントエンド開発は困難です。多くのチームが大規模で複雑な製品で同時に作業できるようにフロントエンド開発をスケーリングすることはさらに困難です。この記事では、フロントエンドモノリスをより小さく、より管理しやすい多くの部分に分割するという最近の傾向と、このアーキテクチャがフロントエンドコードで作業するチームの有効性と効率をどのように向上させることができるかについて説明します。さまざまな利点とコストについて説明するだけでなく、利用可能な実装オプションのいくつかについても説明し、この手法を示す完全なアプリケーション例を詳しく説明します。

多くの開発チームは、マイクロサービスアーキテクチャスタイルがモノリシックアーキテクチャよりも優れたアプローチであることを発見しました。しかし、他のチームは、それらが生産性を低下させる負担であることに気づきました。どのアーキテクチャスタイルと同様に、マイクロサービスにはコストと利点があります。賢明な選択をするには、これらを理解し、特定のコンテキストに適用する必要があります。

ここ数年、サービスベースのアーキテクチャは、より小さく、より焦点を絞った「マイクロ」サービスへと移行しています。このアプローチには、各コンポーネントを個別にデプロイ、スケーリング、保守できること、複数のチームで開発を並列化できることなど、多くの利点があります。ただし、これらの追加のネットワークパーティションが導入されると、モノリシックなインプロセスアプリケーションに適用されたテスト戦略を再検討する必要があります。ここでは、複数の独立してデプロイ可能なコンポーネントの追加のテストの複雑さを管理するためのいくつかのアプローチと、異なるサービスのガーディアンとして機能する複数のチームが存在する場合でも、テストとアプリケーションを正しく保つ方法について説明します。

P of EAAでは、「オブジェクトを分散させないでください」と述べました。このアドバイスは、マイクロサービスへの私の関心と矛盾しますか？

ここ数か月で、成功するマイクロサービスアーキテクチャを実現する唯一の方法は、最初にモノリスから始めることだ、と繰り返し聞いてきました。Simon Brown氏の言葉を言い換えれば、適切に構造化されたモノリスを構築できない場合、適切に構造化されたマイクロサービスのセットを構築できると考えるのはなぜでしょうか？この議論の最も最近の、そしていつものように非常に説得力のある表現は、まさにこのサイトのMartin Fowler氏によるものです。以前の草稿にコメントする機会があったので、これについて考える時間がありました。そして、私はそうしました。特に、私は通常彼に同意していることに気づき、私の見解を通常共有している他の人たちも彼に同意しているようだったからです。

モノリスから始めることは、通常はまさに間違ったことだと私は確信しています。

コンウェイの法則（1968年にメルビン・コンウェイによって定式化された）は、システムの設計はその設計者のコミュニケーションパターンによって制約されると述べています。Birgitta、Mike、James、そして私は、この原則の意味と、私たちのキャリアの中でどのようにそれが実現されてきたかについて議論します。マイクロサービスの概念への影響、ビジネス機能との整合性の重要性、逆コンウェイ操作の役割について説明します。

Infrastructure as Codeは、あらゆるソフトウェアシステムと同様に扱うことができるソースコードを通じてコンピューティングおよびネットワークインフラストラクチャを定義するアプローチです。このようなコードは、監査可能性と再現可能なビルドを可能にするためにソース管理に保持し、テストプラクティスと継続的デリバリーの完全な規律に従うことができます。これは、過去10年間で成長するクラウドコンピューティングプラットフォームに対処するために使用されてきたアプローチであり、今後コンピューティングインフラストラクチャを処理する主要な方法になります。

マイクロサービスアーキテクチャスタイルは、昨年話題のトピックでした。最近のO'Reillyソフトウェアアーキテクチャカンファレンスでは、すべてのセッションでマイクロサービスについて話しているようでした。誰の過剰な誇大広告検出器でも起動して点滅させるのに十分です。この結果の1つは、チームがマイクロサービスを導入することに熱心すぎるあまり、マイクロサービス自体が複雑さを招くことに気づいていないことです。これは、プロジェクトのコストとリスクにプレミアムを追加します。これは、多くの場合、プロジェクトを深刻な問題に陥れます。

人々とマイクロサービスアーキテクチャスタイルの利用について話すと、多くの楽観的な意見を耳にします。開発者は、より小さな単位で作業することを楽しみ、モノリスよりも優れたモジュール性を期待しています。しかし、他のアーキテクチャの決定と同様に、トレードオフがあります。特にマイクロサービスでは、運用に重大な影響があります。運用担当者は、単一の明確に定義されたモノリスではなく、小規模なサービスのエコシステムを処理する必要があるからです。そのため、特定の基本的な能力がない場合は、マイクロサービススタイルの使用を検討すべきではありません。

マイクロサービスアーキテクチャを使用しているチームの話を聞くと、共通のパターンがあることに気づきました。

1. 成功したマイクロサービスの事例は、ほとんどすべて、大きくなりすぎたモノリスを分割することから始まっています。
2. マイクロサービスシステムとしてゼロから構築されたシステムについて聞いたケースは、ほとんどすべて深刻な問題に陥っています。

このパターンにより、私の同僚の多くは、たとえアプリケーションが大きくなってマイクロサービスを使用する価値があると確信していても、新しいプロジェクトをマイクロサービスで開始すべきではないと主張しています。