Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

原文はマーティンファウラーの記事です。

#マイクロサービスとSOA (Microservices and SOA)

マイクロサービスについて語る時によく言われるのが「へぇー、この考え方って10年ぐらい前に流行ったただのサービス指向アーキテクチャ(SOA)だよね、10年前に見たわー」だ。この目線からのツッコミにも利点はある。マイクロサービスのスタイルというものはSOA派の人たちが支持していたものとよく似ているからだ。でも問題はあって、SOAが意味するものはバラバラすぎて、「"SOA"と呼ばれている何か」がここで述べているスタイル(訳注:マイクロサービス)とはまるで違うなんてことがすごくよくある。そういう場合は往々にして、一枚岩なアプリケーション群をESBで統合することに主眼が置かれていたりする。

特に、サービス指向のいけてない実装はこれまでいくつもいくつも見てきた。複雑な部分をESBの中に押し込めようとして[7]何年も取り組んだけれども、何百万ドルも浪費して何の価値も提供できなかったとか、モデルに統制をかけて変更を積極的に抑制してしまい、問題点の向こう側にあるものを見えにくくしてしまったとか。

確かに、マイクロサービスのコミュニティで使われているテクニックの多くは、大きな組織の中でサービスを統合してきた開発者たちが、その経験の中から育んできたものだ。「読み取る側は寛容に(Tolerant Reader)」パターンはその好例だ。Webを活用するという取り組みがなされていて、単純なプロトコルを使うというアプローチはそういった経験をふまえている――中央集権的な規約を避ける反応だ。そういうものによって複雑さが生まれてしまうのは正直言って息が詰まるからね(複数の概念体系を管理する1つの概念体系が欲しくなってしまうような時はいつだってひどく困った事態に違いない)。

SOAによく見られるこのような症状の結果として、マイクロサービス派の中にはSOAのレッテルを貼られるのを全力で拒否する人がいるんだ。他の人はマイクロサービスはSOAの一形態だと考えている[8]けどね。「正しくなされたサービス指向」って感じで。どちらにせよ、SOAにはいろんな意味がありすぎるわけなので、こういったアーキテクチャスタイルにぴったりくる言葉には意味があるってこと。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment