自動テストの難しさと意味上の制約（機械翻訳された日本語で書かれた）

YAMLの壁に苦しんでいるすべての人は、セマンティクスをより意識する必要があります。通常のコンピューター言語は機械語にコンパイルでき、比較的小さく固定された意味上の制約がある

通常のCPUの場合、ISAとABIに示すように、それらが存在すること、プログラムカウンター、スタックポインター、および破棄できるレジスタを予測できます。 パブリッククラウドの特派員は非常に多様です

HPCでの並列処理を意識した最適化には事前実行が必要であるため、kubectl、heat、ansibleおよびvagrantを使用した宣言型クラウドオーケストレーションには常に事前実行が必要です。

クラウドオーケストレーションで必要なメタレベル（リソース割り当て）ステートマシンの構築は、MPIを使用するHPCアプリケーションよりも非常に脆弱です。

私たちのフィールド経験から、そのような構築には、さまざまな組織化された統一リソースラベル付け規則（Linux udevからKubernetesラベル、ノード名へのパスまで）が含まれる場合があります。私たちは毎日新しいものを発明する必要があります。

それは摂食と繁殖に最適化された脳にとって大きな負担です。 YAMLの壁は、組み合わせの性質の心理学的負荷です。

一部のテストを自動化してCI / CDプロセスに統合しようとする場合（ため息）

実際には、テストの構築に失敗する前に、このようなテストの前提条件を知ることはできません。定義に含まれるコンテナー、リソース、ポイントツーポイントデータパスが含まれます。

オーケストレーションの宣言は、自動テストの「意味上の制約」です。私たちが宣言するものは、テストできるものの境界です。

おそらく私たちは、私たちの体、部屋、または町など、私たちが言うことの「大まかな事前実行」を実行する世界のモデルを持っています。 したがって、間違った宣言を書きたくない場合は、最初にクラウド回路基板を脳にマッピングする必要があります。

クラウド宣言の意味的依存関係は、必然的にDSLの構文-意味論の相互設計について考えることを余儀なくさせます。

JSON / YAMLのおかげで、解析について心配する必要はありません。私たちの問題は、一般にコンパイル時および実行時の制約チェックです。

私の知る限り、コンパイラー設計入門コースではオプティマイザーについて言及していません。上級コースでは通常、典型的なCPU設計のみを取り上げていると思います。リソース認識型のクラウド展開は、基盤がなく脆弱な領域です。 

おそらく、基盤は見つかりません。したがって、私たちの選択は次のとおりです。（1）YAMLの壁に取り組み、アドホックな最適化に苦痛な努力を続ける（2）無益な自動化を放棄する ...あなたのは？