はじめに
Quoraの翻訳記事です。
- 原文は参考にリンクがあります。
- インデントや見出しは原文に近い形となるようにしています。
- 文中リンクは、原文についているリンクを紐付けています。
- 全て翻訳すると、記事が長くなりすぎて読みづらくなるので特に評価のよかった回答4つを翻訳しています。
目次
- Rocky Lhotka, CTO at Magenic (2000-present)
- Jeff Meyerson, Software Daily host
- Tia Mongla, Product Specialist at LambdaTest (2017-present)
- Matt McLarty, Co-author of Microservice Architecture from O'Reilly
Rocky Lhotka, CTO at Magenic (2000-present)
SOAと「マイクロ」サービスは、アーキテクチャ、メリット、デメリットの点で有用な違いはありません。基本的に「マイクロサービス」とは、SOAが10年前に採用に失敗したため、SOAのブランド名を変えただけのものです。
私たちの業界では、常に新しい名前で同じ概念を繰り返しています。しかし、それでよいのです。
なぜ良いのかというと、テクノロジー、プロセス、人々の期待は時間の経過とともに進化し続けるからです。時には何十年も何度もブランディングを変える必要があるかもしれませんが、通常、うまく機能させることができます。
1990年代初頭、ASP（アプリケーション・サービス・プロバイダー）のトレンドは、基本的には現在のクラウド・コンピューティングと呼ばれているものを運営していました。しかし、実際に成功するまでには、何度もブランド名を変えて再実装しなければなりませんでした。
SOAやマイクロサービスも同じです。この10年間で多くのことが変化し、進化してきました。マイクロサービスが広く普及するかもしれない。あるいは、さらに多くのことが変わるまで、あと10年、もしくは20年以上待つ必要があるかもしれません。
SOAが失敗したところでマイクロサービスが機能するようになるかもしれない、この10年で何が変わったのでしょうか？いくつかの例を挙げましょう。
- コンテナベースのデプロイメントと（プライベート、パブリック、ハイブリッド）クラウドコンピューティングファブリック（AWS、Azure、Kubernetesなど）
- より多くの組織がアジャイルを採用している
- DevOps (またはユニットテストを伴う自動化されたCI/CD)
- JavaScript/TypeScript や C# などの言語には、非同期プログラミング（IOブロック、並列、分散）を扱うためのファーストクラスの構造体が用意されている
- 成功した分散システムを実装したことのない開発者はほとんどいない
- 「master document」に基づいたサービスの定義のアイデアはSOAで試みられ、（そのほとんどが）否定されたこと
基本的に、技術は進歩し、プロセスの採用も進み、（私はそう考えたいが）より多くの人々が分散コンピューティングとサービスベースのアーキテクチャの結果をよりよく理解するようになりました。
しかし、そうは言っても、マイクロサービスが主流になることはないでしょうし、サービスベースのシステムが主流になるまでには、少なくともあと10年は技術/プロセス/人の進化が必要だと思います。
言い換えれば、10年前のSOAと同じように、私たちは多くのケースで、最新かつ最高の技術を使ってN層のクライアント/サーバアプリケーションを再実装するだけになるのではないかと思います。そして、これは悪いことではありません。なぜなら、これらのすべての進歩により、nティアの開発、デプロイ、および管理は10年前よりもはるかに優れたものになり、1990年代半ばにnティアが主流になったときよりもはるかに優れていたからです。
Jeff Meyerson, Software Daily host
言葉の誇張を避ける1つの方法は、バズワードを定義することです。
- サービス指向アーキテクチャ(SOA): コンピュータソフトウェア設計におけるアーキテクチャパターンの一つで、アプリケーションコンポーネントが通信プロトコルを介して他のコンポーネントにサービスを提供すること。
- マイクロサービス: 複雑なアプリケーションは、言語にとらわれない API を使用して相互に通信する小さな独立したプロセスで構成されるソフトウェアアーキテクチャのスタイル。
Software Engineering Radioのエピソードでは、過去（SOA）と現在（マイクロサービス）の重要な区別として、ホストとゲストが両者の違いを引き離しています。
マイクロサービスとは、ここ10年ほど前から話題になっているSOAのことです。SOAサービスが多くの場合、デプロイメントモノリスに実装されているのに対し、マイクロサービスは独立してデプロイ可能でなければなりません。古典的なSOAはよりプラットフォーム主導型なので、マイクロサービスはあらゆる面でより多くの選択肢を提供します。
もしUberがSOAで構築されていたら、彼らのサービスはこうなるかもしれません。
GetPaymentsAndDriverInformationAndMappingDataAPIAuthenticateUsersAndDriversAPI
もしUberがマイクロサービスで構築されていたら、彼らのAPIはもっと似たようなものになるかもしれません。
SubmitPaymentsServiceGetDriverInfoServiceGetMappingDataServiceAuthenticateUserServiceAuthenticateDriverService
より多くのAPI、より小さな責任のセット。
Tia Mongla, Product Specialist at LambdaTest (2017-present)
従来のSOAは、大規模なアプリを開発し、必要に応じてその中にコードで機能を追加していくというモノリシックなアプローチをとっていました。しかし、SOAの場合は依存性が高いため、マイナーアップデートを適用してもすべてを作り直さなければなりません。現在、マイクロサービスアーキテクチャには、明確に定義されたインターフェースを持つ複数のモジュールを個別に作成し、それらを組み合わせてスケーラブルでテスト可能な製品を作ることを求められています。提供までに1年かかったかもしれない製品やソフトウェアは、マイクロサービスアーキテクチャによって数週間で提供することができます。
データベース - SOAはマイクロサービスアーキテクチャがマイクロSQLを使用するのに対し、大規模なRDBMSで構成されています。
SOAが命令型プログラミングに重点を置いているのに対し、マイクロサービスアーキテクチャはレスポンシブアクターに基づいたプログラミングスタイルを採用しています。SOAモデルは通常、オーバーサイジングされたRDBMSを抱えているのに対し、マイクロサービスは従来のデータベースに接続できるNoSQLやマイクロなSQLなどのデータベースを頻繁に使用しています。2つのスタイルの本当の違いは、一つの統合的なサービスを作成するために用いられるアーキテクチャ手法にあります。
通信速度 - SOAでは、マイクロサービスアーキテクチャで使用されているメッセージングメカニズムに関しては、比較的遅いESB（Enterprise Service Buses）を使用しています。
しかし、マイクロサービスは現在のトレンドであり、マイクロサービスに適用される、異なるテスト手法について変化する必要があります。
Matt McLarty, Co-author of Microservice Architecture from O'Reilly
より詳しい回答は、こちらのInfoWorldでの私の記事をご覧ください: SOAから学ぶ：マイクロサービス時代への5つの教訓
SOAとマイクロサービスを比較しようとするときにはまず、比較の文脈を決める必要があります。典型的なSOAスタイル（SOAP）のWebサービスとマイクロサービスの違いを知りたいのか？典型的な技術スタックの違いに興味があるのか？SOAとマイクロサービスアーキテクチャの概念的な違いを知りたいか？それとも、SOA運動（2002年～2010年）とマイクロサービス運動（2014年～）の違いを知りたいのか？
私はさらに踏み込んで、なぜそのような質問がされているのかを聞きたい。特定のシステムアーキテクチャに対してどちらのアプローチを取るべきかを判断しようとしているのか？マイクロサービスは単なる流行であり、SOAのような悪口になるのではないかと思っているのか？
それらの文脈や意図をできるだけ多くカバーするべく、私は以下のように主張したい:
SOAとマイクロサービスアーキテクチャは概念的に似ている
より高いレイヤーにおいて、SOAとマイクロサービスアーキテクチャは、複雑で分散したソフトウェアシステムを自己完結型の小さなビジネスドメインに沿ったコンポーネントに分解しようとしています。こうした分解は2つのアーキテクチャの狙いではありますが、アーキテクチャを実装しようとしているすべての人がそのようにしてきたわけではありません（それについては後で詳しく説明します）。
マイクロサービスアーキテクチャは、SOAよりもサービスの実装に焦点を当てている
SOAは、サービスがどのように構築されるかよりも、サービスがどのように相互作用するかに関心を持っています。マイクロサービスアーキテクチャの原則は、相互作用を考慮していますが、マイクロサービスインスタンスのエフェメラリティ、システムの自動化の必要性、マイクロサービスアーキテクチャを成功させるための組織的な要因についても話します。
SOAとマイクロサービスの両方において、規模はほとんど重要ではない
マイクロサービスの「マイクロ」はちょっとした誤記です。マイクロサービスアーキテクチャのサービスは、特に初期の段階では、かなり粗い粒度になっていることが多いです。サービス自体の規模よりも、サービスを開発・運用する機能横断チームの規模の方が小さいままであるべきです。逆に、SOAはサービスの大きさに制約を与えることはありませんでしたが、サービスの再利用を目的としていたことがサービスの粒度に影響を与えていました。サービス規模に基づいてマイクロサービスとSOAを比較したり、基礎となるデータモデルに関連してマイクロサービスの最適なサイズについて話している人を見かけたら、注意してください。
実際には、SOAとマイクロサービスはその時代の産物である
SOAは、大規模な組織内でITに多額の資金が投入され、中央集権化が進んでいた時期に普及しました。その結果、統合コストの削減やサービスの再利用の促進を目的に、多くのSOAの取り組みが開始されました。これもまた、運用面でのITILの動きの絶頂期にあったため、結果的にビジネスの成果は期待通りとはならず、取り組み自体が導入企業のコアビジネスから切り離されてしまうことが多かったのです。一方、マイクロサービスは、アジャイルやDevOpsの動きを踏襲したポストモバイルの動きであるため、よりコアビジネスの取り組みとの結びつきが強く、成長のための取り組みとの整合性が取れています。この動きが最終的に成功するかどうかを判断するのはまだ早いですが、この動きはよりポジティブなものになっています。
マイクロサービスの動きは、SOA運動の興亡に影響されている
最後に、マイクロサービスの動きが、その前に登場したSOAの動きをかなり意識して生まれた事実を避けては通れません。例えば、Lewis氏およびFowler氏の元のブログ記事にある「smart endpoints and dumb pipes」の原則は多くの企業のSOAイニシアチブが、ビジネスロジックをESBのインフラストラクチャに押し込みすぎたことをかなり意識した一手です。とはいえ、EAIやOOPがSOAに知見を与えていたように、SOAの実装を通じて学んだベストプラクティスの多くは、マイクロサービスのベストプラクティスとして吸収されてきました。これらの技術にとらわれないソフトウェアアーキテクチャのベストプラクティスと、プロビジョニングやスケーリングの障壁を取り払ったクラウドネイティブの技術を組み合わせることで、マイクロサービスは新しいアーキテクチャの種になりますが、SOAを近い祖先とするものであることは間違いありません。
これについての詳細は、この記事のトップにある記事を参照してください。