昨今、マイクロサービスへの関心が高まっています。マーティン・ファウラーによると、マイクロサービスアーキテクチャとは、「ソフトウェアアプリケーションを、独立してデプロイ可能な個々のサービスの集合体としてデザインする」方法のことです。

マイクロサービスにより、一般公開サイトや社内システムの機能を継続的に増やし続けられるとされていますが、これは小規模かつ独立した機能を定期的に追加することで実現されます。このアプローチは、大規模なモノリシックなアプリケーションのやり方とは対照的です（モノリスにおいては変更のエンジニアリング/テスト/デプロイは簡単ではありません）。個人的には、マイクロサービスのメッセージは説得力があると思いますが、そこにいくつかの落とし穴もあると考えています。例えばポリグロット・パーシステンスの問題などがあります。

ポリグロット・パーシステンスの長所として、各サービスに合わせて最も効率的なデータ格納方法を選択できることがあります。テキストファイルからセマンティックデータベースまで、さまざまな選択肢の中から選べます。これは、作業目的ごとに適切なツールを選択できるという点で優れています（何でもかんでもリレーショナルデータベースに入れようとしてうまくいかなかった、というケースは驚くほどたくさんありますし）。一方、各サービスごとに個別のストレージやデータベースを立てた場合、それらの保守は悪夢のように面倒になることも事実です。従来は、「アプリケーションごとにデータベースを準備する」方法が一般的であり、この結果、データベースが大量発生していました。現在、多くの企業がこういったデータベースの整理・統合を進めているところです。どのアプリケーションでどのデータを使っているのかの把握も困難になります。またどのデータが「正式/決定版」なのか、あるいは（正式/決定版でないとしたら）どのような状態のデータなのかということの把握も容易ではありません。

アプリケーションのニーズに応えるため、各形式のデータごとに特化したデータベースを準備してデータを格納する必要はありません。MarkLogicでは柔軟なデータモデルにより、この同一のシステム内に異なる種類のデータを格納できます。XMLドキュメントだけでなく、JSONドキュメント、バイナリ、テキスト、セマンティックトリプル、さらにはリレーショナルデータまで扱うことができます。各データタイプごとに別個のソリューションを複数準備する代わりに、MarkLogic1つですべてに対応します。これにより「ポリグロット（＝多様）」なデータを扱うことができ（素晴らしいです）、「ポリグロット」なベンダーや実装（ダメです）を回避できます。

プロジェクトにおいて各データタイプごとに違うベンダーを採用していたら（さらに各マイクロサービスごとだったらもっと大変ですが）、ITコストは間違いなく跳ね上がってしまうでしょう。また業務部門からのニーズに応えようとして、「ちょっと」データベースやサービスを追加することによる長期的および短期的コストも忘れないでください。またこういったサービスは、本番稼働を開始した瞬間にレガシーなインフラとなってしまいます。ポリグロットなベンダーを使わない、マイクロサービスやポリグロットなデータを考えるべきです。ここでの目的は、新機能の礎となるものを生み出したり、コストを削減したり、売り上げを拡大したりすることであり、予算を食いつぶしかねないものを導入することではないのですから。