マイクロサービスアーキテクチャに関する記事をずっと書きたいと思っていましたが、常に2つの理由で躊躇していました。一つは、このテーマを深く掘り下げていくうちに、自分が知っていることは当たり前のことのように思え、もう一つは、まだ研究を重ねる必要があるように思えてきたことです。一方で、より幅広い読者層に向けて議論すべき点が既に存在しているとも感じています。ですから、異なる意見をお持ちの方は大歓迎です。
コンウェイの法則とビジネス、組織、情報システムの関係
もう一度引用します。
「（広い意味で）何らかのシステムを設計する組織は、最終的にはその組織内のチームの構造を反映した構造の設計を行うことになります。」
— メルヴィン・コンウェイ、1967年
私の考えでは、この法則は情報システムに直接関係するものではなく、事業を組織化することの実現可能性に関係しています。例を挙げて説明しましょう。ライフサイクルが非常に長く、企業（これはタイプミスではありませんが、私はこの用語がとても気に入っていて、勝手に拝借しました）を組織化することが理にかなっている、比較的安定したビジネスチャンスがあるとします。当然のことながら、このビジネスを支えるシステムは、組織的にもプロセス的にも、このビジネスに相応しいものになるでしょう。
情報システムのビジネス指向
例を挙げて説明しましょう。ピザビジネスを立ち上げるビジネスチャンスがあるとしましょう。バージョンV1（ここでは情報化以前と呼びましょう）では、この会社はピザ屋、レジ、宅配サービスといった機能を提供していました。このバージョンは、周囲の環境の変動性が低い状況下で長く存続しました。その後、バージョン2が登場し、より進化し、モノリシックなアーキテクチャを持つビジネスに情報システムを中核として活用できるようになりました。そして、ここに、モノリスに対する甚だしい不公平さがあると私は考えています。 モノリシックアーキテクチャはビジネスドメインモデルと一致しないもしそうなら、システムは全く機能しないでしょう。これはコンウェイの法則と常識に反するからです。いいえ、モノリシックアーキテクチャは、ビジネス開発のこの段階、つまりシステムが既に構築され運用されている段階においては、ビジネスモデルと完全に整合しています。アーキテクチャのアプローチに関わらず、サービス指向アーキテクチャバージョン3とマイクロサービスアーキテクチャバージョンNはどちらも同じように機能するという、実に素晴らしい事実があります。では、何が問題なのでしょうか？
すべては流れ、すべては変化します。それとも、マイクロサービスは複雑さに対抗する手段なのでしょうか?
先に進む前に、マイクロサービス アーキテクチャに関する誤解をいくつか見てみましょう。
マイクロサービス・アプローチの支持者は、モノリスをマイクロサービスに分割することで個々のサービスのコードベースが削減され、開発アプローチが簡素化されるとよく言います。しかし、私の意見では、この主張は全くのナンセンスです。正直なところ、モノリスと均質なコード内での明白な相互作用が複雑に見えるでしょうか？もしこれが真実なら、すべてのプロジェクトは当初マイクロサービスとして構築されるはずです。しかし、実際には、モノリスからマイクロサービスへの移行の方がはるかに一般的です。複雑さがなくなるわけではなく、個々のモジュールからインターフェース（データバス、RPC、API、その他のプロトコルなど）やオーケストレーションシステムに移行するだけです。そして、これは本当に複雑なのです！
異種スタックを使用するメリットについても疑問が残ります。可能だとは言いませんが、実際には滅多に起こりません（先行する - そうあるべきですが - メリットというよりは、結果としてのメリットです）。
製品ライフサイクルとサービスライフサイクル
上の図をもう一度見てください。ビジネスの個別のバージョンのライフサイクルが短縮していることに気づいたのは偶然ではありません。現代の状況では、バージョン間の移行の加速こそがビジネスの成功を決定づけるのです。 製品の成功は、ビジネス仮説をテストするスピードによって決まります。ここに、マイクロサービスアーキテクチャの重要な利点が隠されていると私は考えています。では、順番に見ていきましょう。
情報システムの進化の次の段階、サービス指向アーキテクチャ（SOA）に移りましょう。ある時点で、私たちは製品の中で 長寿命サービス — 製品バージョン間の切り替え時に、サービスライフサイクルが次の製品バージョンのライフサイクルよりも長くなる可能性があるという意味で、長寿命です。全く変更しない方が合理的です。 次のバージョンへの移行のスピードが重要しかし残念ながら、私たちはサービスに絶え間ない変更を強いられています。DevOpsの実践、コンテナ化など、思いつく限りのすべてが私たちにとって良いものです。しかし、これらはまだマイクロサービスではありません！
マイクロサービスは、構成管理の複雑さに対処する手段です
ここでようやく、マイクロサービスの定義的な役割について触れることができます。これは、製品の構成管理を簡素化するアプローチです。より詳細に言うと、各マイクロサービスの機能は、ドメインモデルに従って製品内のビジネス機能を記述します。これらは、短命なバージョンではなく、長期的なビジネスチャンスとして存在します。製品の次期バージョンへの移行は、文字通り気づかれることなく行われます。マイクロサービスを1つ、あるいはそれらの相互作用のスキームを変更/追加するだけで、突如として未来へと進み、モノリスのバージョン間を行き来し続ける競合他社を置き去りにすることができます。ここで、事前に定義されたインターフェースとビジネス機能を備えた、かなり大量のマイクロサービスが存在すると想像してみてください。そして、例えば図を描くだけで、既製のマイクロサービスから製品の構造を構築します。おめでとうございます。プラットフォームが完成しました。これで、ビジネスを立ち上げることができます。夢のようです。
所見
- システムアーキテクチャは、コンポーネントのライフサイクルによって定義される必要があります。コンポーネントが製品バージョン内で存続する場合、マイクロサービスアプローチを用いてシステムの複雑さを増大させる意味はありません。
- マイクロサービスアーキテクチャはドメインモデルに基づくべきである - ビジネスチャンスは最も長く存続する領域だからである
- コンポーネントの変更率の増加により、配信の速度と品質に対する要求が高まるため、配信プラクティス (DevOps プラクティス) とオーケストレーションはマイクロサービス アーキテクチャにとって最も重要です。
出所： habr.com
