我々は今年初め，マイクロサービスという用語を巡る最近の議論の興隆を記事で取り上げた。これはアーキテクチャに対する，まったく新しいアプローチなのだろうか。それともSteve Jones氏ら一部の人々が指摘するように，SOAの単なる別称に過ぎないのだろうか。記事に対するコメントを見る限り，読者の大半(あるいはコメントをくれた読者の大半)は，マイクロサービスとはSOAそのものであり，新たに名前を付ける必要はないという考えのようだ。その記事の公開後にSteveが公開した別の記事でも，マイクロサービスはまさにサービス指向デリバリ(Service Oriented Delivery)そのものであり，SOAとの違いを見出そうとする試みに意味はない，と論じている。
[...] マイクロサービスは，特定の企業向きの機能実装に適したルールを諦める一方で，より広範なサービス指向アーキテクチャに対して忠実に実装を選択することで，優れたサービスを提供するものです。適切なコンテキストに配置される限り，どのような方向からもその価値を損なうことはありません。
Arnon Rotem-Gal-Oz氏も議論に加わっている。
氏も同じく，Fowler氏とJames氏によって定義されたように，マイクロサービスはSOA以上のものではない，ただWS-*やESBの厳しい要件に関連するSOAの"誤った解釈"を取り除いたものなのだろう，という考えだ。さらに氏は，マイクロサービスとは正確には何なのかを求めて，James Hughes氏の文章を引用している (氏の使用したリンクは，本記事執筆時点では無効になっていた)。
何よりもまず，マイクロサービスとはいったい何なのか？ 実際のところ，簡潔かつ厳格な定義というものはありません。しかしながら，さまざまな人たちと会話した結果から，マイクロサービスとは10～100LOCあたりで収まるシンプルなアプリケーション，というのがひとつのコンセンサスのようです。
氏によると，Jamesも後になって，コードの行数はサービスを比較する方法として非常に不適切な方法である，と同じ記事の中で認めているという (サイズよりも使い方が重要だという記事をJanも書いているが，それと同じだ)。それでも氏は，Jamesの言うコンセンサスの方を重視したいようだ。
では100LOCのサービスは，どうやって作ることができるのでしょうか？ フレームワーク (Finagleや，Jamesの言及しているSinatraなど)を頼ってシリアライゼーション/デシリアライゼーションコード(protobuff, thrift, avroなど)を生成すれば可能です – 要するにスマートなサービスホストを構築せよ，ということなのです。もうひとつの方法は，Erlangのスーパバイザ階層を利用して開発することです。冗長性の少ない言語(Javaなどに対して前述のErlangやpython, scalaなど)の採用が，LOCを削減するひとつの手段になります。
氏の意見のポイントは，10～100行のサービスの方が"本物のサービス"よりも機能が明示的だ，という点にある。また氏は，サービスが(氏の言う"ナノサービス"に向かって)小さくなることで，管理のオーバーヘッドやシリアライズ/デシリアライズのコスト，セキュリティを考慮する必要性が増すとも考えている。氏の言うように，基本的にサービスは小さくなればなるほど，それを寄せ集めて意味のある"全体"にまとめ上げるために必要な労力は大きくなるのだ。
ナノサービスは，サービスの粒度が過度に小さくなったアンチパターンです。(通信やメンテナンスなどの)オーバーヘッドがその有用性を上回るサービスがナノサービスなのです。
氏もSteveらと同じく，マイクロサービスはSOAの別名に過ぎないと結論付ける。数年前，SOAが流行語であった初期の段階ならば，別名を付けるのも悪いことではなかったかも知れない。しかしSOAを支えるコンセプトが十分に確立され，理解されている今日では，別名は何の役にも立たないというのが氏の意見だ。
本来SOAと呼ぶべきものに対して，それでもなお新しい名前を付けたいのならば，マイクロサービスというのはいかにもお粗末だと思います。ナノサービスになってしまったり，あるいは最新のシリアライズ形式を気取ってホスト上で動作するだけの，旧式Webサービスのコード片に陥ることにもなりかねません。
マイクロサービスという用語は新しくないし必要でもない，と多くの人々が認めている事実に相反して，マイクロサービスのサポートを売り物にするフレームワークは増え続けている。したがって大多数がSOAの別名であると理解していても，業界としてはおそらく，この用語を受け入れざるを得ないのだろう。