こんにちは。マクニカソリューションズのminepiccoです。
これからマイクロサービスについて何回かに分けて書いていきたいと思います。
マイクロサービスやその周辺テクノロジーは、マクニカでも取り組みを進めている領域のひとつです。

早速ですが、みなさん「マイクロサービス」という言葉を聞かれたことはありますか？
---
マイクロサービス（英語：microservices）とは、ソフトウェア開発の技法の1つであり、1つのアプリケーションを、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体として構成するサービス指向アーキテクチャ（service-oriented architecture; SOA）の1種である。マイクロサービスアーキテクチャでは、各サービスはきめ細かい粒度を持ち、軽量なプロトコルを用いて通信を行う。アプリケーションを異なる小さなサービスに分割することの利点は、モジュラリティが高くなることである。これによって、アプリケーションの理解、開発、テストがより簡単に行えるようになり、アーキテクチャの腐敗に対する弾力性が向上する。マイクロサービスによる開発を行うことで、開発が並列化され、少人数の自律的なチームにより、各チームが所有するサービスを独立に、開発、デプロイ、スケールさせることが可能になる[2]。また、継続的リファクタリングを通して、個々のサービスのアーキテクチャ全体を置き換えることも可能になる。マイクロサービスベースのアーキテクチャでは、継続的デリバリーと継続的デプロイが可能になる。 
(出典:『マイクロサービス』ウィキペディア (Wikipedia): フリー百科事典）
---

現在の日本企業のシステムには、特定用途の専用のシステムとして設計されたもので、最初の設計書ベースに開発されている、いわゆるWaterfall型の開発によるものが多く存在します。
こういったシステムは後々の頻繁な仕様変更はあまり想定していないものが多く、後から機能追加したり、修正を入れたりすると、システム全体に影響を及ぼすため、容易に手をつけることが出来ないことが多いです。
こういったシステムを、よくモノリシック(一枚岩)と表現されます。

マイクロサービスは、こういったモノリシック(またはモノリス)なシステムではなく、サービスごとに独立した形で開発する方法です。
サービス単位で独立するため、コード自体も非常にシンプルで軽量になるため、メンテナンスしやすくなります。
また、他のサービスから独立させることで、メンテナンスによる影響範囲も抑えられます。

[図 モノリシックからマイクロサービスへ]

一言にマイクロサービスといっても、既存のモノリシックなシステムに手を入れてマイクロサービスに作り変えるのは容易ではなく、今正常に動いているものに手を入れるリスクが伴います。
今動いているシステムはそのままに、新機能の箇所だけマイクロサービスで追加開発したり、新規のシステムのみをマイクロサービスの対象とする企業が多いですし、一般的と考えられます。
また、何でもマイクロサービス化するのが正解とは必ずしもいえません。
マイクロサービス化により、開発スピード向上などのメリットはあるものの、管理対象のコンポーネントが増えるため、運用監視やセキュリティパッチ適用などのオペレーションが増えるデメリットもあるためです。

マイクロサービスを運用するためには、マイクロサービス運用に即した自動化ツールを導入することが推奨されます。
ちなみにマイクロサービスはDockerなどのコンテナで実現されるケースが多く、ツールによって多くのオペレーションは自動化されますが、当然、従来とは異なる開発、オペレーションが必要となりますので、ツールの導入と教育のコストが必要です。
こういった背景から、自社のシステムに本当にマイクロサービスが必要なのかを、事前によく検討する必要があります。

マイクロサービスに適したシステムとそうでないシステムの例

一般的にはコンシューマー向けのシステムなどはマイクロサービスが向いているといわれます。コンシューマー向けのシステムでは、ユーザビリティの優劣により、簡単に競合に顧客が流れてしまう恐れがあるため、より市場の需要にマッチしたシステムを、より早くリリースし続ける必要があるためです。
次回、より具体的な例でマイクロサービスへのアプローチを考えていきます。ご期待ください！