#tl; dr
今後のために、DevOps/MLOps実務を体系的にマスターしておこうシリーズ
私の場合、とっかかりとして、フロントエンド言語のTypescript(ts)と、バックエンド言語のScala/Python(with Sparkエコシステム)をつなげるところから取り組むの良いと思った。
判断理由:
1) フロントエンド開発者(js/tsユーザー)にpythonは親和的
※js/tsユーザーが併用するプログラム言語の定番の一つがpythonとなっているらしい ★１
2) tsのモデル定義とsparkのモデル定義の親和性が高い
※Typescriptのインターフェース定義とSpark向けのcase classが特に類似。
3) tsとsparkとの相互呼び出しが容易となりつつある（「jsii」の魔法）。
※例、jsiiによって、typescriptで書かれたnodejsアプリのテストをScala/Pythonで行うことが可能に。
4) terraform/ansible/docker/hashi stackあたりはなんとかなる私の課題は、今風のフロントエンド。
★１の出典 : JavaScriptユーザーが使う"第2のプログラミング言語"、第1位はPython
[1] nodejs上のTypescriptエコシステムの成熟。
型有りなjs互換言語であるTypescript。jsと比べ敷居が高いところもあるのだろうが、バックエンドを型有り言語(C#/Scala etc.)で書いているエンジニアにとってはTypescriptは安心できる選択肢だ。web開発に外せない選択肢となっているnodejs上でTypescriptを動かす際のノウハウも蓄積されている模様。
以下では、Typescript on nodejsの近年の解の一つらしい、Nest.jsフレームワークを例に取る（フレームワークの流行り廃りはあるにしても、Typescript on nodejsは、今後も標準的な選択肢であり続けるたろう。）
参考 Nest.jsは素晴らしい
[2] バックエンドとフロントエンドの狭間。
インターフェースを持つTypescriptのモデル定義は、C#やScalaと親和的だ。
一例を上げよう。
↑のNest.js素晴らしい記事、Nest.jsによるUserインターフェースの作成のところで作っておられるUserモデルのインターフェースuser.interface.tsは以下:
export interface IUser {
id: string;
name: string;
kana: string;
email: string;
postcode: string;
address: string;
phone: string;
password: string;
admin: boolean;
createdAt: Date;
updatedAt: Date;
}
対して、対応するSpark向けのscalaのクラスは例えば、以下のようになる:
case class IUser (
id: String,
name: String,
kana: String,
email: String,
postcode: String,
address: String,
phone: String,
password: String,
admin: Boolean,
createdAt:TimeStamp,
updatedAt:TimeStamp
)
機械的な置換で行けてしまうレベルだ(ここではscalaとしたが、Typscript同様に型アノテーションのあるPython(PySpark)でも同様)。Sparkに永続化するプロパティはString/Int/Boolean/TimeStampといった基本的な型のみを使うのが実務的に簡易である。フロントエンド側も同様の書き方で安全に書いていけるならば、話が早い（nest.jsは概観するに、安全かつ生産的に書いていけそうな気がする...実際に自身で書くかどうかは別にして)。
Typescriptで書かれたnode.js上からjsonを生成し、(間にKafka等を挟んだり、準ストリーム処理にしたりして)sparkに流し込むことができれば、後はどうとでもなる。バックエンド側では、Sparkはデータストア間のデータハブを記述する標準解の一つだ（csv,cassandra,hive,neo4j,機械学習基盤 etc.をつなぐ）。
[3] jsiiを介し、Python/ScalaでTypescripe on nodejsのテストが可能に。
以下の記事で知った、AWS謹製のjsii。
TypeScriptで書いたプログラムをPython等で動かす魔法の「jsii」を紹介
jsiiによって、TypeScriptのコードをPython/JVM言語(Scala)/C#から直接に呼出すことができるようになるということだ。つまり、PythonやScalaでTypescriptのテストコードを書けるということだ。実運用に入ったシステムでは、フロントエンド側の事情(サービス拡張等)によりTypescriptのモデルは変化していくもの。モデルの変化に併せ、継続的にデータの授受をテストできることはありがたい（cf. 型がないデータ（例、CSV）をsparkの世界に持ち込む際のテストはなかなか面倒）。
次回から手を動かす。
最近、パフォーマンスを追求したwebフロントエンドを持つシステムの裏方（データ基盤）をサクッと作ることを個人的にお勉強してきた。フロントエンドの技術には疎くなっているが、Svelte/typescript/nodejs/firebase...と順に触りながら、感覚を掴みんできた。今後も、nestjs/SSR/ts2elm...と手を動かしながら、バックエンドspark側とのつなぎをお試ししたい。nodejsとDockerをターゲットにCI/CDできるgithub actionが役に立ってくれるかな、と期待。