最近、あることをキッカケに、
Open PaaS熱が再燃して、その中で、
「Compose on Kubernetesがリリースされ、これによって、Open PaaSをDocker Composeで扱えるようになったらしい。」
ということが解り、評価をリスタートしてみる気になりました。
これには（、私は）、「Visual Studio Tools for Docker」、「Visual Studio Kubernetes Tools」を使うのですが、「Visual Studio Kubernetes Tools」が一体、何者なのか？イマイチ解らないので、「
Visual Studio Tools for Dockerの時」と同様に、「WebApplication1」的なモノを使用し、再び、評価してみることにしました。
しかし、昔、造ったDocker Composeに対応した「WebApplication1」を再実行する段階で色々とハマってしまい、「
以前の評価（OpenShiftでASP.NET Coreを動かしてみました）」そのままの「プラットフォーマー -> エンド・ユーザとスタックさせるには、更なる抽象化レイヤが必要だ。」なんて事を再び思いつつ、試行錯誤して、なんとか評価を完了しました（結局、Dockerから再入門した）。
＜参考＞
結論として、「Visual Studio Kubernetes Tools」では、「Azure Dev Spacesへのデプロイ」と「Helm Chartsの自動生成」ぐらいしかできませんでしたが、
「Docker for Windows で Docker Composeをテストし、そこで作成されたDockerイメージを、Azure Kubernetes Service (AKS)と言うK8sベースのマネージドなOpen PaaSにデプロイする。」
...程度の事は、昨今、比較的、容易に出来るようになっているようです（チュートリアルのPythonサンプル・アプリでしか試してないので歯切れが悪いですが、調査した感じでは、ASP.NET Coreアプリで同様のことも十分できそうです）。
ただし、各種のCLI（Dokcer、Azure、K8s）を覚える必要があることや、Dockerコンテナ・リポジトリへの登録、K8sのDeploymentマニフェスト ファイルの作成が手間だったので、Docker Compose を Azure Dev Spacesに直接＆自動でデプロイできるぐらいになると（Visual Studio Kubernetes Toolsの）UX的には良いンじゃないか？などと思ったりしました。
余談：冒頭の、Compose on Kubernetesは、結局、評価しませんでした。と言うのも、ステージング環境以降にデプロイするなら、ちゃんと、Deploymentマニフェスト ファイルを書けないとダメだよねー。なんて思ったりしたタメ。
...と言う事で、以前の評価から、１年半程経っていますが、SaaSをデプロイする先の Open PaaS基盤も、整ってきた感があり、いよいよSaaS時代への突入が始まるんじゃないか？と思ったりしています。
（...そう言えば、2016年に行ったスタートアップ試行の基盤は、.NET Framework、ASP.NET Identity2系、Windows Serverでした。それが、2019年では、.NET Core、ASP.NET Core Identity3系、Linux + Docker + Open PaaSという感じで、技術の転換速度の加速を感じています）。
また、最近、
docker の複雑化と重量化でローカルで動作保証するという概念が失われた結果、コード一行変えて40分のCI回して一つなにかチェックするみたいな人みかけるようになってしまった
...の様な情報を目にして、これについては、私も
以前から言及してはいましたが、ローカルのテスト環境も重要だな。と、改めて思ったりしました。
...とは言え、最近は調査も進んでおり、
と言う様な所まで、整って来ていると思います。
技術に追い付いている企業にとっては朗報、追い付いていない企業にとっては悲報。と言うことで、一概に喜べないような気もしています。
Open COBOL Solution WG
Docker for Windows上で Docker Composeでテストし、Open PaaSにデプロイできる (1)
