なんでドッカーが悪者扱いされてるの？

彼らはそうしたくないと思うよ。夜中の1時に電話が鳴りっぱなしで、すべてが崩壊してるのを見たエンジニアやサポート技術者に聞いてみて。これがAWS全体の障害だとわかったときの気持ちを。

複数のクラウドを管理・展開するための（認知的）オーバーヘッドは、ほとんどのチームにとってはあまり価値がないよね。専門家を雇ったり、2つ以上のクラウドの詳細を把握し続けるのは、小さくて素早く動くチームには現実的じゃない。シンプルさはアップタイムに繋がるし、単一のクラウドソリューションが一番シンプルな解決策だと思う。大企業にとっては、主にコスト削減が目的だね。N百万で良いディスカウントを交渉する方が、N/2百万より簡単だから。それに、AWSを選んだことでクビになった人なんていないしね ;)

クラウドプロバイダーからのネットワーキング（同じクラウド内の別ゾーンへの移動も含む）は、$0.02/GBだよ。これ、すぐに積もり積もるからね。

誰もがAWSのリージョンがダウンすることに対して耐性がないときに、これは正当化できない出費だよね。それに、クロスクラウドのオーケストレーションはほぼ死んでるし、どのプロバイダーも100%独自のクソみたいなもので、コントロールプレーンは…Kubernetesだし。結局、Kubernetesに落ち着いちゃった。

すべてのクラウドプロバイダーは安いコンピュートを提供してるけど、ネットワークの出口は信じられないくらい高いよね。マルチクラウドを試みると、巨額のトラフィック請求書が待ってるから、これは偶然じゃないと思う。

多くの企業の災害計画の考え方は、災害が起きた後に作ることなんだよね。ちゃんと計画を立てるには、時間やお金、トレーニングが必要なんだ。フェイルオーバーはやってる？ちゃんと機能してる？バックアップの状況はどうなってる？フェイルオーバー中にやるべき作業リストは？どれくらい時間がかかるの？そもそもフェイルオーバープランはあるの？サービスは「スプリットブレイン」に耐えられるの？特定の場所でしか動かせないサービスはある？残念ながら、こういう計画は多くの場合、手遅れになってから行われるんだよね。

もしあなたが、すでにVendorAのクラウドにデータを保存している人々にサービスを提供している会社なら、別のクラウドに移るのは高くつくし、仕事を獲得するのも難しくなるよ。もしVendorAがクライアントのベンダーだったら、あなたのサービスもVendorAのクラウドで動くように作ることになる。私の会社もプラットフォームに依存しないつもりで始めたけど、結局はすべての潜在的なクライアントが同じクラウドを使ってるから、ずっとシンプルになっちゃった。大量のデータを持ってる人たちは、複数のベンダーからのストレージ料金が価値あるものだと経理を納得させるのは難しいよ。

なんか、重ね着みたいな感じだね。クラウドシステムはすでに冗長性を考えて設計されてるのに、その上にさらに冗長なレイヤーを追加するのは、ダブルコンドームみたいなもんだし、複数の投資ファンドに投資するようなもんだよね。

クラウドは出口料金で予算を調整してるみたいで…それが原因でクロスクラウド通信を設定するのが高すぎるんだよね。クロスリージョン冗長性も高すぎることが多いし、一部のクラウドやアプリケーションではクロスアベイラビリティゾーンも高すぎる。 （単一のクラウドでのクロスリージョン冗長性は、グローバルなサブシステムに障害が発生した場合や、壊れたサブシステムが複数のリージョンに押し出される前に症状が出る場合、うまくいかないことがある。）さらに、クラウドがダウンしている間に別のクラウドに負荷を移すのは難しいこともある。結局、年に数時間のために多くの作業が必要になるんだよね。多くのアプリケーションにとっては、ダウンタイムを我慢して他のことにお金を使った方がいい場合が多い。