昨年頃からマイクロサービスに関する記事やプレゼンテーションを目にする機会が多くなった。アンチパターンや原則，SOAとの関係を取り上げたものなど，その内容はさまざまだ。C2B2でコンサルティング業務を統括するMatt Brasier氏も先頃，後者のカテゴリの議論に加わっている。
ここ最近，マイクロサービスのコンセプトに関する議論が盛んです。その中には，マイクロサービスがSOAにいかに適合するかという議論もたくさんあります - マイクロサービスはSOAの棺に打つ最後の釘なのでしょうか。それともソフトウェアエンジニアリングを救う最新の万能薬なのでしょうか。
氏の記事ではSOAの原則はもちろん，マイクロサービスへと向かう潮流の背後にある理由についても，その概要を描いて見せている。記事全体を通じての目的は，この２つが原理的には多くの共通点を持ちながらも，SOAとマイクロサービスをターゲットとした製品は，それぞれが異なるユースケースを対象とした別のものである，という点を示すことだ。マイクロサービスを概説する中で，氏は次のように述べている。
コンポーネントを分離することにより，それぞれが独立したライフサイクルを持つと同時に，必要に応じたスケールアップが可能になります。さらに，コンポーネント間の技術的な依存性の多くを断ち切ることで，各サービスに最も適したテクノロジを使った実装ができるのです。大きな問題をいくつかの小さな問題にブレークダウンすれば，個々の問題の分析が容易になり，最適なソリューションに到達しやすくなります。
しかしながら，氏も言っているように，マイクロサービスにはさまざまなデメリットもある。これらの問題は，実際の開発に携わっている人々には十分に理解されているにも関わらず，公開や議論の機会が多いとは言えない。
このような問題の分解は，特にサービス間で異なるテクノロジやアプローチが使用されている場合において，ソリューション全体の複雑性を増大させることになります。統合ポイントのサービス間インターフェース化を推進して，そのインターフェースを明確に定義し，サービスレベルでの合意と非機能要件の明確な定義を行うことが重要です。
一般的にアーキテクトや開発者を支援するツールは現在まだ初期段階であり，従って今後これらの問題のいくつかは早晩に対処されることになるだろう，と氏は述べている。しかし，マイクロサービスには重要な問題がひとつある，と氏は言う。それはデータ管理と所有権だ。
以前はモノシリックアプリケーションだったものを複数の小規模サービスに分割した場合，それまで一箇所に保存されていたデータが，複数のマイクロサービスにストアされるようになるケースが少なくありません。これがデータ一貫性を維持する上で課題となって現れます。
マイクロサービス関連の製品はサービスコンポーネントのライフサイクルを重視する傾向がある，そのため開発者は，Dockerなど特定の実装アプローチの利用や，あるいは一般的には対話用プロトコルとしてRESTfulの利用を継続するように求められることになる，と氏は指摘する。
RESTfulサービスでは，データモデルとしてCRUDオペレーションを提供することを最も重視します。一方で，マイクロサービスアーキテクチャのサービスは，RESTfulに適するようなCRUD形式のサービスに容易に分割可能であるケースが少なくありません。その他のサービスでも，HTTPがトランスポートプロトコルである場合，RESTfulライクなサービスと見て適当であることが多いのですが，しかしサービスが100%，RESTfulの原則に固執する必要はないのです。
SOAについて，氏はまずマイクロサービスとの関連から述べている。
今日ではSOAのデメリットが語られることも珍しくはなくなりましたが，十分に検討すれば，そのデメリットのほとんどがマイクロサービスにも当てはまる上に，より具体的な例もあることに気付くはずです。同じことがメリットについても言えます。基本的にやっていることは同じ — 大きな課題を小さな課題に分割する，ということなのです。
氏はさらに，マイクロサービスの採用あるいは推進のリーダとしてしばしばその名が挙げられている企業が，自分たちのアーキテクチャを好んでサービス指向と称している点を指摘する。その一方で彼らには，その成果を達成する上で従来のSOA製品を無視する傾向がある。氏の見解によれば，それらはEnterprise Service Bus関連を基本としたアプローチを重視したものなのだ。このようなSOA製品の評価が低いのは，エンタープライズサイズのアーキテクチャではなく，ひとつのアプリケーションを開発するためにそれらを利用しているプロジェクトがあるからだ，というのが氏の意見だ。
こういった機能は，ビジネスユニットレベルのSLAを追跡するという方法で，このエンタープライズユースケースに主な焦点を当てています。大部分のSOA製品では，ひとつ，あるいは少数のプロトコルとメッセージフォーマットを使ったサービスとの通信が必須となっていて，それを可能にする接続ライブラリが提供されています。
氏が指摘したように，SOAとマイクロサービスは同じ原則を使用しているが，組織内で運用されるレイヤが異なっている。SOAは大規模なサービスのオーケストレーションを行うものだが，それぞれのサービスはマイクロサービスで構成されている場合もある。実際のところ氏は，マイクロサービスの存在意義はSOAの原則の成功にかかっていると考えているのだ。氏は記事を次のように結んでいる。
アプリケーションを開発しているのであれば，マイクロサービスフレームワークを採用することで，より多くのアジャイル性と，開発者としてのコントロールの機会を得られるでしょう。そうではなく，企業全体にわたる多くのビジネスプロセスのオーケストレーションが目的ならば，SOA製品がよりよいツールセットを提供してくれるはずです。