マイクロサービスとは何か？小さく、独立してデプロイ可能なサービス

マイクロサービスは、小さく、独立してデプロイ可能なサービスであり、単一のビジネス能力を担い、ネットワーク越しに他のサービスと通信します。

マイクロサービスは、システムを多数の小さなサービスに分割し、それぞれが独自のcodebase、データストア、リリースのペースを持ちます。1つの大きなdeployの代わりに、数十のサービスをそれぞれのスケジュールでdeployします。その独立性こそが目的そのものであり、それがCI/CDの話を単一のモノリシックなbuildよりも興味深いものにしています。

サービスをマイクロサービスにするもの

マイクロサービスは、1つの能力をエンドツーエンドで担います。独自のコード、独自のデータベースまたはストレージ、そして明確なAPI境界です。システムの他の部分とリリースを調整することなく、build、テスト、deployが可能です。通信はネットワーク越しに、通常はHTTPまたはmessage busを介して行われます。

チームが採用する理由

独立したdeploy: 1つのチームが他をブロックせずにリリースできます。
的を絞ったスケーリング: アプリ全体ではなく、負荷の高いサービスだけをスケールできます。
技術の自由: 各サービスが独自のstackを選べます。
障害の分離: 1つのサービスの障害が残りをダウンさせる必要はありません。

CI/CDの変化

モノリスは1つのpipelineを持ちますが、マイクロサービス群はサービスごとに1つのpipelineを持ちます。それは1つの遅いbuildの代わりに多くの小さく速いbuildを意味しますが、同時により多くの維持すべきpipeline、より多くのartifact、そしてサービスが単独ではなく一緒にどう振る舞うかをテストする必要も意味します。

新たなテストの負担

ユニットテストはシンプルなままですが、サービス境界をまたぐ破綻を捕捉するために、コントラクトテストと統合テストが必要になります。あるサービスの自身のpipelineを通過する変更でも、consumerを壊す可能性があるため、継ぎ目のテストがコードのテストと同じくらい重要になります。

deployの調整

独立したdeployは、2つのサービスが一緒に変更されなければならなくなるまでは利点です。後方互換性のあるAPI、feature flag、そして慎重な順序付けにより、サービスを1つずつリリースできます。その規律がなければ、「独立した」deployは静かに結合したものになります。

マネージドCIでのマイクロサービス

数十の小さなサービスは数十の頻繁なpipeline実行を意味し、そこはまさにqueue時間とcold startが積み重なる場所です。マネージドrunner（Latchkeyのような）はwarmな容量を準備しておくため、サービスごとのbuildが一気に発生しても、列で待つのではなく即座に処理されます。

重要なポイント

マイクロサービスは小さく、1つの能力を担い、独立してdeployします。
多くのサービスは多くのpipelineを意味し、コントラクトテストと統合テストの必要性がより強くなります。
「独立した」deployを実際に独立させ続けるのは、後方互換性です。