マイクロサービスとコンテナの時代になりましたが、これで「ビジネスロジック開発に専念できた！」と思ったら大間違いです。
結局にライフサイクル、ネットワーク、状態、バインディングなど意識しないとだめですね。
従来のインフラ（VMも物理マシンも）、たとえばUnixのマシン上にたくさんのプロセス（Kernelを含めて）が動いていて、
メモリやネットワークやルーティングやストレージやDBやキャッシュやログやメールなどなど、
いろんな事をやってくれていて、実際に意識していない人がほとんどですよね。
でもコンテナになっても、これも必要、あれも必要、
ネットワーク系はサービスメッシュがほしいよねとか、
段たん見えてきました。

「分散アプリケーションに必要なものは何ですか？」に対して、下記のような回答がありました。

マルチランタイム・マイクロサービスアーキテクチャ

サービスメッシュ必読ガイド - マイクロサービス時代のサービス間通信管理
サービスメッシュは、(一般的にはマイクロサービスベースの)分散ソフトウェアシステム内における、すべてのサービス間"east-west"トラフィックを管理するテクノロジです。ルーティングのようなビジネス指向の機能運用に加えて、セキュリティポリシの適用やQOS(Quality of Service)、レート制限のような非機能サポートも提供します。一般的には(すべてではありませんが)サイドカープロキシを使用して実装され、すべてのサービスがそれを通じて通信するようになります。

サービスメッシュはデータプレーンとコントロールプレーンという、2つの高レベルなコンポーネントで構成されます。

データプレーンは"仕事をする(does the work)"もので、"[ネットワークエンドポイントを]出入りするすべてのネットワークパケットの条件付き変換、転送、監視"を役割としています。最近のシステムでは、データプレーンは(Envoy、HAProxy、MOSNなどのように)プロキシとして実装されるのが一般的で、サイドカーとして各サービスとともにプロセス外部で動作します。

コントロールプレーンは"仕事を監督する(supervises the work)"主体として、データプレーンの個々のインスタンスすべて -- 独立したステートレスなサイドカープロキシ群 -- を分散システムとして構成する役割を担います。

ユースケース

Strategies for Decomposing a System into Microservices
将系统分解为微服务的策略

ソフトウェアのオブジェクト指向設計やDBMSのER図設計には、
粒度についていつも難解な課題ですが、
マイクロサービスも同様で、サービスをどこまで細かく分割するかは、
今までベストプラティクスがなかった。

このドキュメントは、結構参考になるかもしれません。

美利好车lease.mljr.comは、レンタカーのサービスです。
このサービス自身は知りませんでしたが、いいドキュメントがあるので共有します。
何がいいかというと、チューニングの詳細があったので大変参考になります。

株式会社メルカリの導入事例：Kubernetes を駆使したマイクロサービス化でグローバルサービスの開発効率を劇的に向上

メルカリ米国チームでは、従来システム（大手クラウドプラットフォーム上に構築されたメルカリ API）を、Gateway API（wrapper）で包み込み、段階的かつ効率的なマイクロサービス化を実施。そして、その Gateway は Google Cloud Platform（GCP）上に構築されることとなりました。

「Kubernetes を導入したおかげで、インフラのことをほぼ何も考えずに開発をスタートできた」とのこと。それによって開発も順調に進み、ある機能（後述のサーチ機能）の開発において、通常なら 2 か月かかるところを 1 か月足らずで完成できたそうです。
「メルカリ米国チームには専従のインフラエンジニアが存在しないのですが、それでも何とかやっていけているのは Kubernetes のおかげでしょう。」
「最初は米国チームが採用した、Gateway API を使った方法ではなく、従来のモノリシックなメルカリ API から、マイクロサービス化された新機能を呼び出すという方式を採っていました。
ただ、実際にやってみると、やはりメルカリ API を経由させるやり方ではマイクロサービス化の恩恵を最大限に引き出すことができず......（苦笑）。
結果、米国と同様、メルカリ API を Gateway API でラップする方式に移行することになりました。
実は英国チームでも同様の問題を抱えているため、こちらは日英で共用できるものにしたいと考えています。」

マイクロサービスアーキテクチャにおける分散スケジューラ

Mesosマスタと通信できなくなったプロセスが強制終了されてしまうのだ。これは好ましくない設計選択だ、とCambell氏は考えている。現実問題として、分散システムのネットワーク分割は珍しいことではないので、このような状況ではプロセスを引き続き実行させておくことが望ましい。

Nomadのメリットは独自のゴシッププロトコル(gossip protocol)を使用していることだ。これにより、同一データセンタ内だけでなく、データセンタ間でのサーバ通信が可能になる。ネットワーク分割が発生しても、同じパーティション内のサービスは引き続き機能し、通信することができる。問題が解決すれば、最終的に一貫性を取り戻すことが可能だ。しかしながら、Nomadを実運用に使用しているアプリケーションを知らなかったので、移行のリスクを負いたくはない、と氏は考えた。

最後に選んだツールがKubernetesだった。Mesosに似てはいるが、いくつかのメリットがあった。まず挙げられるのが、ネットワーク分割の処理方法が異なり、発生時にインスタンスを強制終了しないという点だ。クラスタの状況を容易に確認可能なダッシュボードも備えており、アプリケーションを扱う場合の抽象化のレベルもそれほど高くない。

Martin Fowlerが3年前に書いたものですが、MicroservicePrerequisites

マイクロサービス導入時に必要な条件があります。

Rapid provisioning

Basic Monitoring

Rapid application deployment

实施微服务，我们需要哪些基础框架？

大変よくまとめられている資料です。