雪泥鴻爪--IT技術者の随筆

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

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

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

では今の時代でしたらどうすれば良いか？

ライフサイクル: K8S
ネットワーク: Istio, kupper, Knative
状態: Cloudstate, dapr
バインディング: Camel, dapr, Knative
との提示がありました。

「境界線はどんどん分からなくなったよ。」の質問に対して、下記の提示がありました。

Service runtime と　Mecha runtime（メカ）が一緒になってサービス提供するので、「マルチランタイム」という話ですね。


つもりは、マルチランタイム・マイクロサービスアーキテクチャは、マイクロサービスアーキテクチャより疎結合ですね。

マイクロサービスアーキテクチャには明確な目標があります。変更への最適化です。アプリケーションをビジネスドメインに分割したこのアーキテクチャでは、分離され、独立したチームによって管理され、独立したペースでリリースされるサービスを通じて、ソフトウェアの進展とメンテナンスに最適なサービスバウンダリを提供します。

Mechaアーキテクチャはまた、ミドルウェア非依存にマイクロサービスを最適化します。マイクロサービスは相互には独立していますが、組み込まれる分散プリミティブには強い依存性を持っています。Mechaアーキテクチャはこの２つの要件を別々のランタイムに分離することで、別々のチームによる独自のリリースを可能にします。このような分離は"Day-2 Operarions"(パッチやアップグレード)を向上するとともに、長期的にはビジネスロジックの集合ユニットのメンテナンス性も改善します。この意味から、Mechaアーキテクチャは、最もフリクションを起こすバウンダリに基づいてソフトウェアを分割したマイクロサービスアーキテクチャが、自然な形で進化したものであると言えます。このような最適化は、ソフトウェアの再利用や進化という形で、コードの過度な分散と引き換えに究極的なスケーラビリティに最適化された関数モデルよりも多くメリットをもたらします。

まとめ：　
今まであまり見えてこないミッドウェアレイヤーのものもサービス化にしましょう。
メカサービスと呼びましょう。
Sidecarもメカサービスの一つで。
コアビジネスロジックサービスは、入手可能（off of shelf）なメカサービスに搭乗し、メカサービスを操縦して、バリバリ仕事しましょう。

参考
Mecha：将Mesh进行到底