（前置きもなく始めます。）

Kale

Kubeflow Kale - Kubeflow Automated PipeLine Engine

ML × Kubernetes といえば Kubeflow がとても有名です。
その中で、Kubeflow Pipelines というパイプラインを構築できる機能があるのですが、ぱっと見 DSL 書かなければいけないのがなんとなく心理的ハードルがありました。（ということで私は触ってないです。）

Kale は Jupyter Notebook の cell metadata を利用して、Notebook から Kubeflow Pipelines のワークフローに変換してくれる OSS です。
コードを書き換えることなく、セル間の依存関係を UI で設定していくだけなのでとても楽です。

今日、ちょうどチュートリアルが投稿されていたので詳細はそちらをご覧ください。

An End-to-End ML Workflow: From Notebook to Kubeflow Pipelines with MiniKF & Kale

その他のリンクは以下の通りです。

Flyte

Flyte - Lyft’s Cloud Native Machine Learning and Data Processing Platform, Now Open Sourced

Kubernetes の登場とともに、ワークフローエンジンも色々登場しました。
その中でも最も有名なものの一つは Argo です。前述の Kubeflow Pipelines でも Argo が利用されています。

Flyte もワークフローを構築できるのですが、Argo と比較して、環境の分離（マルチテナンシー）があったり、Python コードで定義するようになっています。（Argo は YAML）設定したいものが複雑になると、YAML よりもコードの方が可読性は良いな、という当たり前の結論に AWS CDK を触って最近達しました。（最終的に生成されるのは YAML ですが。）Operator を作ることで拡張する感じは Airflow に似ているのかな？と思いました。

Declarative Specified in Protocol Buffers

というあたりも少し興味深いです。

詳細は Kubecon での発表資料/動画をご覧ください。

Buf

Buf - A new way of working with Protocol Buffers

Flyte で Protocol Buffers の話をちょっと出しましたが、proto ファイルの共有（というか、インターフェースの共有とスタブの生成）はみなさんどう実現しているのでしょうか。私の知っている限り列挙します。

git submodule
生成しておく（例：Generated Java code for Google APIs)
Buzel
stormcat24/protodep

そんな中で、uber/prototool を眺めていると、こんな issue があり、そのまま散策しました。
Updated README for Buf

Buf ではBuf Image Registry の提供を予定しているようです。
引用ですが、以下のような機能を想定しているようです。

Language-specific stubs, for every version of protoc and associated language plugins.
Tarballs that contain your .proto files alongside Bazel build rules, to allow easy consumption for Bazel repositories
Hosted documentation for your Protobuf APIs

Buf Image は FileDescriptorSets を拡張するような形になっています。spotify/proto-registry でも FileDescriptorSet を用いているので界隈ではそういうもののようですね。私個人でも動的にメッセージを生成したいなと思った時があり、この辺りで出会いました。
AWS でも「Amazon EventBridge のスキーマレジストリの紹介」というのがあったりしたので、Buf Image Registry は楽しみです。

jk

jk

宣言的だ！といって YAML で書いてるうちに、「本当に、これ、YAMLで書きたかったんだっけ？」ということありませんか？
私はワークフローエンジンでも、Infrastructure as Code でも経験しました。
近頃は、AWS CDK や Pulumi が登場して、個人的には、条件分岐や繰り返し処理をしたい場合は、こういったものを利用した方が良いなという結論になりました。（前述の通り、よく考えると当たり前。）

jk is a data templating tool designed to help writing structured configuration.

ということで、jk は Javascript で記述して、 YAML や JSON を生成できるOSSです。ライブラリ（Kubernetes や grafana）を利用することで、より簡潔に書けるようになる感じは、 AWS CDK の Constructs と同じような雰囲気を感じます。
ロードマップには、 Typescript サポートも入っているので楽しみです。

ちなみにこの OSS は Multi-Cluster Parameterized Continuous Deployment for Kubernetes という記事で遭遇しました。Pulumi と比較して、なぜ jkcfg なのかみたいなところもさらっと書いているので読んでみてください。