フィオラノ ソフトウェア ジャパン ブログ
    Twitter
  • Facebook
  • Google+

マイクロサービス (その5) –賢さをどこに求めるか–

miroservice-banner

前回 (その4) は、機能性の低いパイプ (Dumb pipe: 土管) のアーキテクチャとして、仮想的なバスを提示しました。

今回は、“smart endpoints and dumb pipes (賢いエンドポイントと機能性の低いパイプ)” の一方である “smart endpoint (賢いエンドポイント)” について考察してみたいと思います。
ビジネス ロジックを複数のマイクロサービスからなるコレオグラフィとして実現し、マイクロサービス間の通信はライトウェイトなメッセージング サーバーで構成される仮想的なバス (Dumb pipe: 土管) によって支えるアーキテクチャが良いと説明しました。
このアーキテクチャによって、オンプレミスやクラウド上に分散されて配置されるマイクサービスを連携し、1つのビジネス ロジックとして実行することが可能になります。

VirtualBus
土管とコレオグラフィ

マイクロサービス (その4) — 仮想バス アーキテクチャ —

miroservice-banner

前回は “smart endpoints and dumb pipes (賢いエンドポイントと機能性の低いパイプ)” の意味することにについて考察しました。

今回は、マイクロサービス間の連携を支えるこの “smart endpoints and dumb pipes” の具体的なアーキテクチャについて考えてみます。

 

マイクロサービスとは、複数のマイクロサービスが連携して業務処理を実現するアプリケーション アーキテクチャです。
単一の機能にしぼった小さな (マイクロな) サービスを連携させることで、大きな処理を実現するアプローチは、UNIX シェルのパイプのエッセンスを有しています。

ハブ&スポークの問題点 –バス トポロジーとの対比 —

hubSpoke_jp2

1.EAI 製品の登場

過去、企業の IT インフラは複雑化の一途をたどるスパイラル状態にありました。既存のレガシー システムに数多くのパッケージ アプリケーションを加えていき、メンテナンスの困難な情報サイロを作り出してしまっていたのです。
このような状況では、ビジネス データもまた各アプリケーションに分散され、情報のサイロ化をも生じています。ビジネス データがこのような状況に陥ると、意思決定に必要な情報をタイムリーに得ることが非常に難しくなります。
1990 年代に登場した EAI (エンタープライズ アプリケーション統合) 製品は、上述の状況を改善することを目的としたものでした。この当時の EAI 製品は、中央にブローカーと呼ぶ “ハブ” を配置し、各アプリケーションは中央のハブを経由して連携する、いわゆる “ハブ&スポーク” の形式を採っていました。