企業に twin が要る理由と、Mithril がそれを実現する仕方

本番は、権限、拒否、障害、クラスタの形を試す場所ではない。twin は同じ名前を持ち、結果を適用しない複製である。Mithril はその複製を文書にし、reverse domain の部品を組み合わせて判定と応答を計算する。クラスタも同じ境界で宣言し、観測と照合する。

企業に twin が要るのは、知りたい問いを本番で聞いてはいけないからである。顧客データを持つ系に誰が届くか。残量が尽きたとき拒否はどんな形で返るか。今日動いているクラスタは、宣言したクラスタか。本番はすでに顧客と決済と身元が住んでいる場所である。そこを学習の場にすると、問いは障害と結びつく。変更を止めて委員会が納得するまで待つのも、もう一つの失敗である。資産は動き続け、その模型だけが古くなる。

twin は、その資産と同じ名前を持ち、結果を適用しない複製である。主体、バケット、キュー、クラスタは、問いに答えられる程度には実在する。効果は複製で止まる。セキュリティ、基盤、設計は、許可、拒否、障害、漂移を、顧客に請求するアカウントへ届く前に予行できる。

Mithril は twin を、もう一つのクラウドではなく文書にする。資産の各部は reverse domain で名づけた部品であり、部品は組み合わせる。身元、認可、残量、整合性、障害、TLS は、それらを必要とするサービスの下に並ぶ。一回の run はその鎖を歩き、呼び出し側が持ち帰れるものを二つ返す。クライアントが見る応答と、その応答を生んだ判定である。applied は false のままである。ランタイムはソケットを開かず、実ホストや秘密を名指す文書は実行の前に拒否される。

同じ境界がクラスタにもかかる。Docker と Podman は、どのサービスが在り、どれがどれに依存するかを述べた Mithril の文書として包まれる。その文書を描くと Compose になる。照合は、宣言と実際の観測を比べる。照合はコンテナを起動しない。企業が得るのは、自社の資産の予行である。クラウドのプロトコルを話す既存のエンジンの脇に置き、何が決まり、何を意図して適用しなかったかの記録が残る。