マイクロサービスアーキテクチャとは

システムを、協調して動作する小規模なサービスに分割したアーキテクチャのこと。
サービスの境界をビジネスの境界に合わせることで、特定のコードがある場所を明確にし、大規模かつ複雑になることを回避する。

優れたサービスにするために

下記を念頭に置く必要がある

サービス間の結びつきを疎結合にすること。
1つのサービスの変更に対して、単独でデプロイが可能となる。

関連する振る舞いを一緒に配置し、関連しない振る舞いは別の場所に配置すること。
振る舞いを変更したい場合、1箇所変更するだけでリリースが可能となる。
また、コードが把握しやすくなり、重複したコードが発生しにくくなる。

言語やコードの依存関係に依っても異なるため、明確な回答はない。
Jon Eavesという方が、マイクロサービスを「2週間で書き直せるもの」と特徴付けている。

サービスごとに異なる技術を使う判断ができる。
最大公約数的になることが多い標準化された汎用的な手法を選ぶのではなく、ジョブごとに適したツールを選ぶことができる。

あるコンポーネントに障害が発生していても、その障害が連鎖しなければ、問題を分離してシステムの残りの部分を機能させ続けることができる。

モノリシックサービスでは、すべてを一緒にスケールさせないといけないが、マイクロサービスでは、必要なサービスだけをスケールできる。

モノリシックサービスは全体をデプロイする必要があり、影響が大きくリスクが高くなる可能性があるが、マイクロサービスでは、1つのサービスに変更を加え、残りのサービスとは独立してデプロイすることができる。

アーキテクチャを組織に一致させることができ、1つのコードベースで作業する人数を最小化し、チームの大きさと生産性を最適化する。
(小規模コードベースで作業する小規模チームの方が、生産性が高い傾向にある)

機能を再利用する機会を広げることができる。
外部の第三者にI/Fを提供している場合、状況が変わったら別の方法で組み立てられる。
モノリシックアプリケーションの場合は、機能分割や別機能としての作り込みが必要となる可能性がある。

サービスのサイズが小さいことで、さらに優れた実装に置き換えるコストやすべてを削除するコストが管理しやすくなる。
(巨大で扱いにくいレガシーシステムは誰も触りたくない)