マイクロサービスはサービス指向アーキテクチャ（SOA）から派生したものであり、疎結合の単機能サービスモジュールを組み合わせてコアアプリケーションを構成します。マイクロサービスはサービス指向アーキテクチャ（SOA）から派生したものであり、疎結合の単機能サービスモジュールを組み合わせてコアアプリケーションを構成します。
ここでは、SOAとマイクロサービスの類似点と相違点、そして企業がSOAやマイクロサービスを導入すべき理由（および導入すべきでない理由）を説明します。
サービス指向アーキテクチャ（SOA）は、再利用性を重視してソフトウェアアプリケーションを作成し、非機能要件（セキュリティ、拡張性、パフォーマンス）を確実に満たすことを目指すアプローチです。
マイクロサービスには決まったアーキテクチャがあるわけではありませんが、疎結合で軽量な複数の独立したコンポーネントでアーキテクチャが構成されるという点は共通しています。
マイクロサービスの場合、SOAのようにUIやデータベースなどのシステム領域に注目したチームではなく、製品やサービスなど複数のシステム機能にわたる特定のビジネス成果ごとにチームが編成されます。
サービス指向アーキテクチャとマイクロサービスアーキテクチャは、主に3つの点で異なります。
SOAは、エンタープライズレベルで運用されるアプリケーションやサービスのポートフォリオで構成されます。コーディングを適切に行うには、開発者がアプリケーションとそのすべての依存関係を完全に把握している必要があります。
一方、マイクロサービスはアプリケーションアーキテクチャです。1つのアプリケーションを、特定の機能を提供する複数の独立したサービスに分割します。つまり、各機能は確実に1つの作業を行うものであるため、開発者が各モジュールで作業を行うために必要な知識が少なくてすみます。ただし、機能間でのコードの再利用はしにくくなります。
簡単に言えば、マイクロサービスは内側（アプリケーション内部のアーキテクチャ）に目を向けたもの、SOAはエンタープライズレベルのアーキテクチャに関係するものだということです。
SOAは「粗い粒子」です。つまり、大規模なビジネスドメインの機能に焦点を当てています。そのため、各機能に多くの依存関係があります。
マイクロサービスは非常に「細かい粒子」です。1つの機能に焦点を当てた有界コンテキストをメッシュ状に組み合わせています。有界コンテキストは疎結合こそされてはいるものの、それぞれが独立しており、SOAのドメイン機能に比べて大幅に焦点が絞り込まれています。
マイクロサービスは粒子単位で構築できるため、SOAよりも拡張性が非常に優れています。
SOAの場合、通信を処理するソフトウェアが必要です。これまで企業は、SOAPなどのWebサービスアクセスプロトコルを使用して各機能の公開や相互通信を行っていました。しかし、企業のすべてのアプリケーションを接続すると、システムの拡張性に悪影響が生じ、保守の所要時間も長くなってしまいます。
そこで、SOAではエンタープライズバス（ESB）と呼ばれるミドルウェアツールが使用されるようになりました。ESBは機能間の通信を処理し、ポイントツーポイント接続数を減らします。しかし、ESBを利用すると単一障害点ができます。ESBがダウンするとすべてのSOAサービスにアクセスできなくなってしまうのです。
マイクロサービスアーキテクチャの場合、各サービスの運用や拡張は独立した形で行われます。単独の障害点もそれぞれが個別に抱えることになるので、マイクロサービスは回復性と俊敏性が非常に高く、各機能を個別にコーディングすることも可能です。
マイクロサービスアーキテクチャは、Netflix、Twitter、Amazonのような数百万人規模のユーザーへの対応も可能な拡張性の高いアプリケーションです。クラウドネイティブのアーキテクチャであり、高度な俊敏性と自律性の確保に重点を置いています。また、サービスの粒度が細かく独立しているため、サービスの継続的デリバリーを柔軟に実現できます。
では、マイクロサービスを使用しない理由などあるのでしょうか。
マイクロサービスではシステムを細かな要素に分けるため、非常に複雑になります。この複雑さによって問題が引き起こされるのです。
データベースの不可分性、一貫性、独立性、永続性（ACID特性）のルールを、マイクロサービスの機能のメッシュに常に平等に適用することができなくなるという点がそのひとつです。ACID特性で定義されている一連のルールは、システムのエラー、障害、事故が発生した際にデータの完全性を保証するためのものです。たとえば、不可分性ではシステム内のトランザクションは成功か失敗のいずれかでなければならないという条件が定められています。
しかし、マイクロサービスのメッシュではそう単純にはいきません。不可分性は、あくまで結果的に得られるものです。最終的にはシステム全体で一貫性が保たれますが、個別のトランザクションに関してはそうではありません。
そのため、マイクロサービスは構築、保守、運用がかなり難しいアーキテクチャだといえます。
ビジネス部門もエンタープライズアーキテクトも、マイクロサービスアーキテクチャに投資する前に、それがもたらす複雑さを認識しておく必要があります。マイクロサービスを導入した組織が、潜在的なメリットを大幅に上回る大規模なディスラプションに見舞われたという話も珍しくありません。
肝心なのは、自分の解決したい問題が何なのかを正確に理解することです。さらに重要なのは、既存のインフラを細分化したり分散させたりせずにすむシンプルなソリューションがないかを確認することです。
AmazonやPayPalのような提供サービスを持ち、1分間に数百万件ものトランザクションを処理できる、拡張性とパフォーマンスに優れたクラウドベースのシステムを必要としている場合であれば、複雑なマイクロサービスをあえて選択する必要があるかもしれません。
しかし、開発者を大幅に増やす必要が生じたり、プロセスが複雑になったりするなどの課題があることも忘れないようにしてください。
マイクロサービスは特効薬ではありません。メリットとデメリットがあり、実装に失敗するとうまく機能せず、課題をまったく解決できないこともあります。
マイクロサービスに付きものの重荷を背負いたくないという方は、「OutSystemsのマイクロサービスアーキテクチャ」または「OutSystemsのドメイン駆動アーキテクチャ」をご覧ください。
