あとブログはかけませんでしたが
当たりの話を聞いて、なんとなく、思ったところがあって、もやもやしたままだったところを、現時点の感想レベルで 自分なりに残しておこうと思います。
結論
現時点で 分散管理が必要な状況ではないので知見は増やすとしても、手を動かすことを含めて静観。
ビルド環境（E2Eテスト含む）のコンテナ利用は良さそうだから検討したい
理由
知見だけで静観
今は分散システムよりも、ちゃんとしたプロダクトを作るための基盤を自分なりに考えているので、そちらを優先しておきたい という 大変 個人的な理由です。
コンテナ利用は試したい
Javaのバージョンアップを考えると、気軽にテストを実行できる環境を作っておきたいから、です。
ちゃんとバージョンが代わっても動くのか？というのを きちんと確認するのなら、複数バージョンのJavaが導入されている環境ではなくて 独立した環境にしておきたいです。
そして、そういった環境相違をスクリプトで制御できるDockerをはじめとしたコンテナの利用は有効だと思っています。
思うところをツラツラ
デファクトとは？
とある記事で、k8s やIstio があっという間にデファクトスタンダードの地位を確立するから、今のうちに勉強をしておいた方がよいでしょう、というのを見て「確かに」と思う反面「デファクトになるから勉強する」というところには疑問も。
デファクトになるか ならないか を予見して勉強する分野を決めるのは、それっぽいけど 結構 博打だと 私が思っています。
学びたいから、学ぶ。今 面白そうだから 学ぶ。仕事で使うから 学ぶ。という感じのところを 拠り所にしないと「また外れた、、( ;∀;)」となりそうな気がするからです。
分散システムを構築したいという要求があって、そのときに自分の方式思想にフィットするものを選定する、もしくは 今後 分散システムを構築する際の知見を増やしておきたいので、今 知見が集まっているk8sやIstioを使ってみる というのは良い考えだと思います。
進むであろう標準化
より良い仕組みであればあるほど、もう しばらくすれば、統一インターフェース的なものが策定されると思います。
そうすると、標準実装としてk8sやIstioは扱われるかもしれませんが、引き続き デファクトであるか というと それは分からない という感じです。
数年したら k8sもIstioも、組み込まれた基盤 として存在することはあっても、それ自身の形のままで デファクトとして存在はしていない気がしています。
現時点においても、GCPを基盤として開発している人は、知見としては必要だけど、それはDevOps環境として認識しているだけという感じで、既に そういう立場にいる人たちだというのが 私の理解です。
もし明日、GCPの基盤が k8s以外になったとしても、DevOpsインターフェースが変わらずリリースが無事できるのであれば なんら問題は無いでしょう。
やりたいことはDevOpsであって、k8sやIstioを使うことではない、ということです。
どこを目指す？
立場と目的によって、それを学習するか、利用するか、気が付きもしないのか、みたいな感じで 分かれるところじゃないかな？と。
結局は、技術者としての立ち位置と優先度だとは思います。
作り上げられている過程に参加することで、多くの知見が集まり 学べるから ということで先行者になる（なりたい）という人もいれば、ツールの１つとして 安心して利用したいだけ という人もいます。
私は、先行者に対する羨望はありつつも、実体として（実力として）利用者のレベルな人です*1。
良く分からないけどコマンド叩いたらアプリが動いたので一旦それで良しという人もいれば、内部の仕組み（思想）を分かってこそ技術者であるという人もいます。
アプリに興味がある人と、OSのようなモノが動く仕組みに興味がある人、違って当たり前かな、というところです。
知見は定期的に集めておこう
実際のところ、分散システム云々以前でも、システムとして 集約（集中管理）を基盤とした モノリシックといわれるものであっても セッション共有やDBレプリケーションという形で複数サーバーの論理集約はありました。
雑な整理ですが、セッション共有・DBレプリケーションの基盤が自己完結管理できるものであったところから、外部サービス（マイクロなサービス）が相手になる、という意味で複雑度が増しているという感じです。
例えば、サーキットブレーカーが必要になるというのが その一例です。
機能要件（業務仕様で決める）・非機能要件（フレームワークで決めてくれている）くらいの分類で十分というか それ以上は分からないという人もいれば、エンジニアたるものフルスタックエンジニア*2であるべしという人もいます。
DBレプリケーションについて考えたことが無いなんて信じられないという人もいれば、レプリケーション何それ？という人もいます。
私としては、ちょうど中間くらいの感じで、頭の体操含めて 知見は定期的に集めておこう という感じです。
進む抽象化（Javaを使う立場として）
Javaというか Jakarta EE を使う立場としては、Payara（PayaraMicroを含めて）のような EEサーバーの内部に k8sやIstioのような仕組みが組み込まれて 抽象化されて標準インターフェースで操作できるようになるんだろうな（してほしいな）というのがオチです。
これは Cloud FoundryなどのPaasも同じく。
Cloud Foundry におけるNATS（ルーティングをするところ）や、EEサーバーにおけるDAS（管理サーバー）のように、冗長化できない単一障害点を解消するために、Istioのような仕組みが使われるのではないかな？というのが 私の勝手な想像です。
本音
私は、別にTomcatやPayaraの設定値で はまったり、チューニングをしたいわけではなく、ただ システムを構築したいだけです。
ということで、一番求めているのは「Javaで作ったマイクロなサービスをイイ感じに論理集約してくれるようなPaas」です。
当面は マイクロなサービスを連携するほどの規模の開発はしないし、自分がやりたいことを優先して そっち系は静観していたら 求めるものが世に現れるだろう、と、楽観的に構えることにしました。
さいごに
どうでも良いところですが、言い訳として。
「マイクロなサービス」というのは、「マイクロサービス」というものに対して、私は厳密な理解をしていないというだけです。*3
雰囲気だけでも伝われば、まぁ良しという割り切りです。
