ここ数年，小規模なサービススイートで構成されたアーキテクチャを表現することばとして"マイクロサービス"という用語が拡がっている。QCon San Francisco 2012でもThoughworksのJames Lewis氏が，このテーマでプレゼンテーションを行った。氏はMartin Fowler氏と共同で，同じテーマの記事も書いている。これに対して，マイクロサービスは一部の人々が考えるような新しい概念ではない，所詮はSOAの焼き直しに過ぎないという意見を持って，最近この議論に加わったのがSteve Jones氏だ。その中で氏は，Lewis氏とFowler氏の記事の分析を順に追いながら，両氏のマイクロサービスの定義をOASIS SOA RM(Reference Model, 参照モデル)と比較する，という作業を行っている。
サービスによるコンポーネント化: OASIS SOA RMによると，
SOA (Service Oriented Architecture) とは，さまざまなドメインの所有管理のもとに分散された機能を整理，活用するためのパラダイムである。
Jones氏は次のように指摘する。
OASISの定義は「要するにサービスとは何なのか」をうまく説明しています。SOAにおけるサービスとは，要求と機能を引き合わせるためのメカニズムなのです。
- 第３者のために処理を実行する能力
- 第３者に提供する処理の仕様
- 第３者に対する処理実行の提供
続いて氏は，この件に関するLewis, Fowler両氏の発言を取り上げる。
サービスとは，明示的なコンポーネントインターフェースを通じて通信するプロセス外コンポーネントです。
ビジネス機能中心の構成: Fowler氏が間違った思い込みをしている，マイクロサービスは新しくはない，と氏が考えるのはこの点だ。OASIS SOA RMは機能(Capability)について，次のように定義している。
サービス提供者がサービス利用者に対して提供できる現実的効果
機能(処理を行う実体)とサービス(体系的な構造)とは区別されなければならない，と氏は指摘する。
私たちの10年にわたるSOAの試行錯誤，そしてOSASIS SOA RMに関わるすべての人々の多くの経験，そこから分かったのが，フレームワークの体系化とその動作との区別です。これが非常に重要だという理由は，サービス = 機能という考えでサービス開発に着手した結果，山のようなサービスを抱えることになる人々があまりに多いからです (まあ，そういう意味で言うなら，これがマイクロサービスということなのかも知れませんが)。
Folwer氏の書いたことは間違いではないものの，大事なことを忘れている，と氏は考えている。
新しい，ですか？ このようなアプローチに関するモデル，管理，チーム編成といった話題なら，私だって本を書いています。SOAの背景にある主原則についてならば，大勢の実践者グループによるSOA憲章(2009)もあります(個人的にはRMの方がよいと思っていますが)。ここでポイントなのは問題が２つあることです。ひとつはサービスと機能の混同，もうひとつは管理階層の重要性に関する認識の欠如です。
プロジェクトではなくプロダクト: Fowler, Lewis両氏の記事は，SOA RMの領域外としてこの話題を扱っている。しかし氏は，ここにも何ら新しいものはない，と言う。
Googleでちょっと検索してみれば，この分野にどれほど多くのものがあるのかすぐ分かるはずです。よいプロダクトもあれば，そうでもないものもありますが，いずれにしても目新しいものではありません。私は"プロジェクトではなくプログラム"という表現を使うようにしています。アーキテクトがプログラムのライフサイクル全般に対して"責任を取る"ことが必要だ，といつも言っているのです。繰り返しますが，彼らの主張が間違いだ，というのではありません。新しくはない，と言いたいのです。それが有効な手段であることは前から分かっていますが，コストという重大な問題があるのです。
賢いエンドポイントと愚かなパイプ: 氏はこの原則に全面的に同意するものの，これも新しいとは考えていない。またその表現も，次のように少し異なるものになっている。
OASIS SOA RMには"実行コンテキスト"という概念があります。これはサービスがコールされたり，機能が実行されたりする一場面を表すことばです。何らかの動作を伴うエンドポイントがスマートであることに疑いはありません。"メカニズム"と表現されるのもそのためです。これに対して"パイプ"の方は，ダムであるにせよ，そうでないにせよ(火星に行ったRoverの"パイプ"はそれなりにスマートなようですが)，その存在自体大した価値はありません。これはSOAの重要な発見です。SOA RMにもそれは明記されています。実行コンテキストは必要な内部配線がすべて完成している場所ですが，機能へのアクセスを提供するのはあくまでサービスですし，価値を提供するのは機能なのです。
分散型ガバナンス: ここもまた，氏がFowler氏とLewis氏に同意できる場所である。ただし ...
ガバナンスという面でSOAがマイクロサービス以上の存在であるというのは，間違ってはいないと思います。OASIS SOA RMで語られているSOAは，このような原則をすべてのIT資産に適用可能にするものです。特定の実装スタイルで実装されたものに限るわけではなく，ビジネススクールの教えるアプローチという意味において，すべてのIT資産を対象とするのです。
マイクロサービスとSOA: Lewis, Fowler両氏の記事は当初，SOAについては(十分には，あるいはまったく)言及していなかったようだ。Jones氏とのここ最近のやりとりの結果として，補足的な話題として付け足されたものであることが記事から見て取れる。しかしJones氏は，それを単に不十分なだけではなく，話題として無関係だと考える。
[...] SOAの真の定義ではありません。REST主義者(RESTafarians)が自分たちの方法のすばらしさを説明する時に愛用していた，古い"ビッグ"ESBやWS-*的なものを展開したに過ぎないのです。両氏の記事はマイクロサービス形式を"はっきり"説明した上で，"SOAには意味が多すぎる"という理由から，SOAに対するマイクロサービスの優位性を主張しています。私が根本的に同意できないのはこの部分です。実装アプローチとしてのマイクロサービスの優位性を言いたいのならば，マイクロサービス以外のSOAが有効に動作するアプローチに対して，マイクロサービスがどう適合するかを説明することが必要だという点がそうですし，そもそも相応なサイズ(12人)のチームから個人単位にサービスの範囲を変更することが，サービスの"マイクロ"化なのだと言えるのでしょうか。
結論として氏は，マイクロサービスには何の新規性もない，サービス指向デリバリ(Service Oriented Delivery)アプローチに過ぎないのだという，自身の意見を改めて述べている。アーキテクトや開発者はマイクロサービスよりも，定義が明確で実績も豊富なSOAをもっと活用した方がよいだろう。マイクロサービスに新しさを見出すよりも，"今日"のSOAを論じることが必要なのだ。氏は次のように述べている。
その事実を裏付けるものとして，参考例とされているNetflixでも，脚注にもあるように，実際には"小機能(fine-grained)SOA"という用語を用いています。もうひとつの参考例(Amazon)でもSOAという表現を使っているのです。
読者の意見はどうだろう？ マイクロサービスは単なるSOAなのだろうか，それとも根本的に異なるのだろうか？