マルチクラウドのピッチは常にクリーンに聞こえる。ベンダーロックインを回避する。特定のタスクに対して最も安価なプロバイダーでワークロードを実行することでコストを最適化する。独立した障害ドメインに分散させることで回復力を向上させる。理論上は説得力のあるケースだ。実際には、マルチクラウド展開で運用しているチームは、しばしばその逆の状態を説明する。運用上の複雑さが倍増し、オブザーバビリティが半減し、1つではなく2つのクラウドが存在することによってのみ発生する信頼性の問題のカテゴリだ。私が密接に協力したチームは、当時のGPUの利用可能性と価格設定の良さから、AWSへのマルチクラウドワークロードとGCPでのML推論パイプラインへの移行を行ったが、その後8ヶ月間、予期せぬインシデントクラスに対処することになった。それはアプリケーションのせいでも、どちらかのクラウドプロバイダーのせいでもなく、それらの境界に存在していた障害だった。負荷がかかったときにのみ現れるデータ転送レイテンシのスパイク。クロスクラウド呼び出し中にのみトリガーされる認証トークンの有効期限のエッジケース。本番稼働前のすべてのテストをパスし、午前3時に本番で失敗するネットワークポリシーの相互作用。個々の問題は難しくなかった。診断ツールがそれぞれ内側を指しており、障害はどちらのツールも見ていない領域に存在していたため、それらは難しかった。