ほとんど似た意味だが、SOAと言う単語は、使われすぎてどんどん抽象化してきてしまったが、Micro Servicesという単語は、まだまだ新しく、よりイメージが明確。

SOA とは
SOAとは、コンピューターのソフトウェア機能を独立した「サービス」という単位で実装し、それらをくみあわせてシステムを作り上げる考え方です。これは目新しい考え方ではありません。SOAという概念はもともと古くからいわれていました。ではなぜ最近になって急に脚光をあびてきたのでしょうか？それには相次ぐ企業の統廃合や事業再編、市場競争の激化といった市場環境に対して、企業のシステムが柔軟に対応しなければならなくなったという背景があります。しかし、今日の企業システムはひとつの企業内ですら異機種環境が乱立する複雑なIT環境となっています。さらに相次ぐ企業合併や再編により、企業同士のシステムを統合しなければならないケースも増えています。そんな中で、「複雑化するIT環境をいかに統合するか」という課題に対する解決策として、浮上してきたのがSOAという考え方です。異機種分散環境における、ソフトウェアの統合技術の考え方は旧来もありましたが、インターネットの普及やオープンスタンダードの技術が発達したことにより、再びSOAが注目されるようになったのです。
SOAとは、コンピューターのソフトウェア機能を独立した「サービス」という単位で実装し、それらをくみあわせてシステムを作り上げる考え方であると先ほど述べましたが、ではSOAの特長とは何でしょうか？それは大きく3つあります。

1. アプリケーションが業務処理などの単位でサービス化されていること、
2. オープンで標準的なインターフェースでサービスが定義され、呼び出すことが可能であること
3. サービスを組み合わせてアプリケーションを構築すること。

Micro Services とは

マイクロサービスの特徴が九つほど上げられています。

• サービスによるコンポーネント化：ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。
• ビジネスケイパビリティに基づく組織化：役割ごとにチームが構成されるのではなく、複数の役割が混在したチームがひとつのサービスを構築する。（コンウェイの法則！）
• プロジェクトではなくプロダクト：コンポーネントは期限のあるプロジェクトとして開発されるではなく、継続的なプロダクトとして提供される。
• スマートエンドポイント、ダムパイプ：サービス間のメッセージは、HTTP経由でAPI呼び出しされるか、RabbitMQやZeroMQといった軽量メッセージングシステムによる通信で交換される。
• 分散ガバナンス：サービスごとに言語やデータベースなどは統一されず、個別に適切なものが選択される。
• 分散データ管理：サービスごとにデータを持ち、統合されていない。
• インフラストラクチャ自動化：継続的デリバリが実現され、自動テスト、自動デプロイなどが採用されている。
• 障害設計：構成されるサービスの障害に耐性を持つように設計されている。
• 進化的設計：各サービスごとに変更が行なわれ、漸進的に設計がされる。

「マイクロサービス」のメリットをざっくり言うと「変化に対応しやすい」こと──ただしファウラー氏は“使い過ぎ”を警告

「マイクロサービス（Microservices）」という用語が、Web企業を中心に注目を集めています。マイクロサービスという言葉には、「おや？」と思わせる吸引力があると思います。ここでは、このマイクロサービスとは何か、いままでの考え方とは何が違うのかを見ていくことにしましょう。

マイクロサービスについて簡単に説明すると、システムを複数のサービスの集合体として構成し、サービス相互をRESTful Web APIのようなシンプルで軽量な手段で連携する手法です。その最大のメリットは、小規模なサービス群を疎結合する作りにすることにより、「一枚岩」（モノリシック）のシステムの複雑さから自由になることです。つまり、マイクロサービスの考え方を導入することで、変化に強いシステムを作ることができるのです。

マイクロサービスを深く知りたい方は、まず James Lewis氏、Martin Fowler氏による解説記事Microservices (2014年3月25日）をご覧ください（日本語訳もあります）。マイクロサービスの重要な特徴を9項目に分類して説明しています。この9項目はそれぞれ掘り下げる余地がある話題なのですが、その全部は説明しきれません。そこで「いままでの考え方と何が違うのか」「最も大きなメリット／デメリットは何か」を中心に見ていくことにします。

SOAとマイクロサービスの違いはなに？

このマイクロサービスの考え方を、ある年代以上の人に説明すると「SOAとどう違うの？」と聞き返される場合があるかもしれません。2000年代の初頭頃、企業情報システム開発の分野で「SOA（サービス指向アーキテクチャ）」という言葉がバズワードになった時期がありました。複雑化し、また個別分野ごとに“サイロ化”して変更が難しくなった企業情報システムを、サービスの集合として再定義し、変化に対応しやすいシステムにしようという掛け声が高まり、その解決策として期待されていたのがSOAだったのです。「変化に対応しやすいシステムを作ろう」という大きな目的については、SOAもマイクロサービスも共通点があります。

ではマイクロサービスとSOAの違いは何か？　ざっくり言うと、「複雑さ」が違います。

SOAの内容を見ると、大きな目的は同じでも、実現手法はいまのマイクロサービスとは対極と言っていいほど違います。まずSOAでは、サービスの切り口としてXMLで定義された「Webサービス」（SOAPやWSDLなど）が有力視されていました。現在の主流であるRESTful Web APIよりはるかに複雑な仕様群です。そして、Webサービスによりシステムコンポーネント間を結ぶためには、ESB（エンタープライズサービスバス）と呼ぶ複雑な（つまり高価な）ミドルウェアが必要だと言われていました。非同期メッセージへの対応、高負荷への対応、障害発生への対応、サービスレベルの保証、セキュリティなど、利用条件をエンタープライズシステムの伝統的な基準に合わせて厳しく設定すると、こうしたミドルウェアの必要性はもっともなように思われました。

このほかにも、「ビジネスプロセスコレオグラフィ」「ビジネスプロセスオーケストレーション」のような複雑な概念がたくさん登場しましたが、あまり定着しませんでした。関連して、ITガバナンスの重要性やEA（エンタープライズアーキテクチャ）の重要性も主張されていました。

ざっくり言うと、SOAは「難しく考え過ぎていた」ためにうまくいかなかったのです。

一方の「マイクロサービス」では、Webの文化から生まれたシンプルなRESTful Web APIをサービスの切り口にすればいいじゃないか、という考え方です。ESBのような重量級のメッセージングミドルウェアは使いません。

RESTfulの概念や実装を説明した書籍『RESTful Webサービス』（Leonard Richardson、Sam Ruby、邦訳はオライリー・ジャパン、2007年）
の巻頭には、Ruby on Rails開発者として有名なDavid Heinemeier Hansson氏が寄せた言葉が記されています。そこには、本書について「大仰な言葉もなく、またWebサービスはとても難しいから何かをするには大企業の実装に依存するしかないとWeb開発者を脅かすこともなく、それらの原理を使用する方法を示している」とあります。

このように、複雑過ぎて大企業でなければ実装できないようなXML WebサービスやSOAへの反発から、シンプルなRESTful Webサービスの考え方が生まれてきた経緯があり、マイクロサービスもまた、この流れの延長にある考え方と言えます。

先に紹介したJames Lewis氏、Martin Fowler氏によるマイクロサービスの解説記事には、マイクロサービスの9項目の特徴の1つとして「スマートエンドポイント、ダムパイプ」という言葉が出てきます。メッセージングの部分を複雑にし過ぎないことが、マイクロサービスの成功の大きな要素だったと言えるでしょう。インターネットの文化、Webの文化に親しんだ人にとっては当たり前の考え方ですが、旧来のSOAの考え方から見れば「コロンブスの卵」のような発想の逆転と言えます。

日本での成功事例報告も

マイクロサービスは、多くのサービスの内部ですでに取り入れられている考え方です。日本におけるマイクロサービス導入の早い段階での報告として、クックパッドの高井直人氏（所属は執筆時点）による解説「クックパッドとマイクロサービス」があります。2014年9月に発表された記事ですが、この時点で、クックパッドではマイクロサービスへの転換を開始して1年以上が経過していることが明かされています。文中、次のように力強くマイクロサービスの導入が語られています。

このようにクックパッドでは、新規のアプリケーションを独立したチームによる独立したサービスとして開発し、それらを連携させていくというアプローチをとるようになりました。私たちは、このアーキテクチャをマイクロサービス（Microservices）として位置付け、そう呼んでいます

クックパッド自体のコードベースは巨大なままですが、それぞれのサービスはそこから独立し、巨大なコードベースの重さにひきずられることなくスピード感をもってサービス開発ができています

巨大で複雑なシステムを抱えている組織にとって、マイクロサービスの導入はむしろ自然なことだったようです。前出の高井氏は次の個人Blogの記事「マイクロサービス（microservices）とは何か」では次のように述べています。

私個人としては、マイクロサービスという用語は、モノリシックなアーキテクチャを採用して成長してきたウェブ企業がその問題に対応していくなかで、自然と培ってきたテクニックやスタイルに名前がついたものとしてとらえています

マイクロサービスとは、突然出てきた新手法というよりも、Web開発の経験を積んだ複数の組織が同時多発的に自然に編み出したものと見た方が実態に近いのです。

マイクロサービスは組織の文化と密着する

マイクロサービスは、単にシステム開発の手法であるだけでなく、企業の組織や文化に深く関係するという考え方があります。開発組織の文化によりマイクロサービス導入の成否が決まるというのです。

ユニークなプレゼンテーションツールの開発元として有名なPreziのエンジニアリングマネージャJose Roca氏の「QCon Tokyo 2015」（2015年4月21日開催）での講演「マイクロサービスの実現に必要なのは、多くのコンピュータと新しい企業カルチャー！ ~マイクロサービスが変えるソフトウェアと組織のアーキテクチャ~ 」では、マイクロサービスは企業文化を変える、あるいは企業文化を変えないとマイクロサービスは機能しない、との考え方が示されていました。

「組織が複雑化すると『モノリシックエフェクト』により組織がサイロ化し、スローダウンしてしまう」とRoca氏は述べています。同社でのマイクロサービス導入は、単に技術的な取り組みというだけでなく、組織を適度に分割することとセットになっていたのです。Roca氏はまた「マイクロサービスは、テクニカルなアーキテクチャであり、組織の動きを加速するものでもある」とも述べています。

アジャイル開発が組織の文化と密接に結び付いていたように、マイクロサービスの導入も組織の文化に関わる取り組み抜きには成功しないのかもしれません。マイクロサービスの考え方は、開発組織を独立した複数の小さなチームに分割し、それぞれのチームが自らの利用技術を決め、継続的に開発していくスタイルを想定しています。ここで心配になることとして、日本的な受託開発の現場とマイクロサービスの考え方は相性が良くない場合も出てきそうです。

マーティン・ファウラー氏は安易なマイクロサービス適用を戒める

ここまでは、マイクロサービスのメリットが明らかになりつつあることを説明してきました。ところが、「マイクロサービスの使い過ぎは有害だ」という警告が、「マイクロサービス」の概念を広めた一人であるMartin Fowler氏から発せられています。

2015年5月13日付けで公開した解説記事MicroservicePremiumの中で、Fowler氏は「大半のシステムでは、マイクロサービスは必要ない」と発言しています。

この記事では、縦軸を「生産性」、横軸を「複雑度」に取ったグラフを使い、システムの複雑度が小さい段階でマイクロサービスを導入すると、モノリシックな作り方に比べて、かえって生産性が落ちてしまうことを説明しています。

マイクロサービスは、小さなシステムで最初から導入するような考え方ではなく、複雑度が高まってから考えればいい──このようにFowler氏は語り、マイクロサービスの早過ぎる導入を戒めています。こうした警告が必要になるほど、マイクロサービスの考え方は流行しているということでしょう。

ここまで見てきたように、マイクロサービスとは、何かの課題を解決するために登場した手法ではなく、システムの複雑さに取り組む開発組織の中から自然発生的に生まれたアーキテクチャです。開発組織の中で考え方が共有されていなければ、うまく機能しない考え方でもあります。これがマイクロサービスの大前提です。 Lewis氏とFowler氏の解説記事が述べる9項目の特徴と合わせて、マイクロサービスを理解する上ではとても大事なことだと思います。