ブロックおもちゃのように部品の組み合わせによってシステムを構築するのはITエンジニアにとって長年の夢であり、これまで多くの試みがなされてきたが成功してこなかった。しかしインターネットの普及を背景に、HTTPプロトコルを活用してシステム部品をつなぐ手法が近年盛んになっている。このような取り組みを企業で有効活用するためには、SaaSを部品として考える必要がある。
ITR Insight 2016年冬号「マイクロサービスの価値と活用指針」（#I-316012）において、企業システムがビジネススピードやアジリティの向上を支援するためには、これまでの企業システムの「モノリシック」構造（膨大な数のプログラムが複雑に組み合わされた一枚岩のシステム）から小さい単位のサービスの集合体である「マイクロサービス」アーキテクチャを段階的に採用する必要があると述べた。
この考え方は従来のSOAとは異なり、構造やルールがシンプルであることから、今後のITアーキテクチャの主流となる可能性が高く、企業システムの企画や基本設計を行う際には必ず採用可否の検討を行うべきであるとITRでは考えている。
しかし、国内企業においてマイクロサービスに対する正しい理解が進んでいるとはいえない。「このいろいろなサービスを部品としてつなぎシステムを構築する」という考え方が、これまで多くの先人が挑戦し失敗してきた「部品（コンポーネント）によるシステム構築」と同じであると誤解する人も少なくない。
「部品化」によるシステム構築の代表的な取り組みには、CORBA（Common Object Request Broker Architecture、1990年頃〜）、EJB（Enterprise JavaBeans、1998年頃〜）やDCOM（Distributed Component Object Model、2000年頃〜）があげられる。これらの技術の推進者は、普及のためには「標準」や「規格」を開発者に守らせることが重要という考え方が根底にあり、そのためには「ライブラリの充実」「インタフェースの統一」「集中管理」などの活動が必須と考えた。しかし、現実には、それらを守るためには開発者側の学習が必要であり、これらの技術が包括的で複雑なアーキテクチャであったことから習熟カーブが緩やかだった。このため、そのような多大な努力をするよりも「自分で作った方が早い」と考えた開発者が多かったことが、これらの取り組みが成功に至らなかった最大の要因である。つまり、これまでの「部品化」の試みでは、「標準を維持する」コストよりも「独自に作る」コストの方が低かったために標準や規約を守る開発者が増えなかった。
これに対し、マイクロサービスの考え方では、各種部品を「つなぐ」ことが主眼であり、つながれる部品側のアーキテクチャや実装には何も制約がない。どのようなOS、開発言語／フレームワークを使ってもよい。「つなぐ」仕掛けは、Webの成功要因の1つである超軽量プロトコル「HTTP」を活用するだけの、極めてシンプルな構造となっている。
つまり「マイクロサービス」の真の価値は「マイクロ」性にあるのではなく、「RESTでシンプルに多種多様なシステム部品をつなぐ」ことにある。マイクロサービスを検討するに当たって、サービス粒度の規定や標準化を優先的に取り組もうと考えている企業は、誤った判断をしているといえよう。