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

マイクロサービス (その3) — 土管 (Dumb pipe) の意味 —

miroservice-banner

前回は、マイクロサービスについてUNIX のパイプ機能をアナロジーとして取り上げ説明しました。
今回は、マイクロサービス間の連携を支える “マイクロサービスにおけるパイプ機能” について考察してみたいと思います。

Dumb Pipe (土管) ?

マイクロサービスを提唱したJames Lewis氏が Martin Fowler氏と共に著した『Microservices』*1という記事の中で、「Smart endpoints and dumb pipes」*1というセクションを設けて、マイクロサービス間の連携について説明しています。

このセクションではまず、対極にある smart pipe を説明しています。smart pipe の例として ESB (エンタープライズ サービス バス) などのアプリケーション連携製品をあげています。

マイクロサービス (その2) – パイプライン —

miroservice-banner

前回 (その1) は、マイクロサービス アーキテクチャについてモノリシックなアプリケーションと比較して概説しました。今回は、マイクロサービス間のコミュニケーションに焦点をあててマイクロサービス アーキテクチャを掘り下げていきます。

UNIX のパイプ

マイクロサービス アーキテクチャは、クラシックな技術ではありますが UNIX のパイプ機能になぞらえることができます。

UNIX のパイプ機能は、最初のシェルが作られた 1970 年代に誕生しています。このブログを読まれている方の中には、UNIX のシェルを直接使用してコマンド実行をしたことがない人もいるかもしれません。簡単に説明してみます。

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

hubSpoke_jp2

1.EAI 製品の登場

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