雲が増えればパワーも増える？マルチクラウド アーキテクチャに隠された 11 の秘密をご存知ですか?

[[415285]]

クラウド コンピューティングにはさまざまなオプションがあるため、CIO からインターンに至るまで誰もが圧倒される可能性があります。24 GB のメモリを搭載したサーバーは良さそうですし、新しい AI 画像分類システムも同様です。ああ、それは何ですか？長期オブジェクトストレージですか?私にもZBをいくつかください。

1 つのクラウド プロバイダーがこのような優れたオプションを提供しているのであれば、2 つ、3 つ、またはそれ以上のプロバイダーを選択しない理由はありません。宿題が机の上に山積みになったり、レシピがどんどん複雑になってキッチンカウンターのスペースを隅々まで占領してしまったりした経験は、ほとんどすべての人が持っているでしょう。現代の建築家がインターネット全体で利用可能なすべてのリソースを活用したいと考えるのは当然のことです。

マルチクラウド アーキテクチャが理にかなっている理由は、それがいくつかの実用的なニーズを非常によく満たすからです。クラウドが増えるということは、API の選択肢が増え、データセンターの場所が増え、AI アルゴリズムが増えることを意味します。十分な AI アルゴリズムがあれば、機能する可能性のあるアルゴリズムが必ずいくつか存在します。マルチクラウド サービスにオープンなアーキテクト チームは、新しい改善点が出現したときにそれを柔軟かつ最大限に活用できます。

マルチクラウド アーキテクチャが人気を集めているもう 1 つの理由は、企業がベンダー ロックインから解放されたいと思っていることです。契約の更新時期が来るたびに、元のサービスプロバイダーは、競合他社を参入させるまで、その機会を利用して価格を値上げしていました。企業が最初からマルチクラウドの俊敏性をアーキテクチャに組み込んでいれば、ベンダーの営業チームが価格を引き上げたい場合でも、別のベンダーのクラウド サービスに簡単に切り替えることができます。企業にとって、わずか週末で業務を別のプロバイダーに移行できる機能は魅力的です。

しかし、これらすべての利点には代償が伴います。競争上の優位性を享受できるほど機敏であることには、いくつかの副作用もあります。その一部は、数週間、数か月、あるいは数年後まで明らかにならないこともあります。ここでは、ユーザー エクスペリエンスを低下させる可能性のある、マルチクラウドの潜在的な危険性をいくつか紹介します。

独自のツールにアクセスできない

現代のクラウド サービスの多くのコンポーネントは、純粋に商用の製品です。メーカーはさまざまな RAM 容量のインスタンスを販売しており、ユーザーによって Linux のフレーバーに対する好みは異なります。一見普通のオプションの中には、独自の強力なツールを提供するものもありますが、これらのツールは独自のものです。 Oracle の Master Database、Google の Firebase、Microsoft の .Net スタックなどがその典型的な例です。

マルチクラウドでは、ユーザーが独自のツールを別のクラウド サービスに複製することが難しいため、独自のツールを十分に活用することが難しくなります。他の選択肢を確保し、いつでも他のベンダーのサービスに切り替えることができるようにすることが目標である場合、本当に自分に適したオプションを享受できない可能性があります。自由な選択の最大の代償は、ユーザーが決して良いツールを入手できないことです。

選択肢は制限される

時には他の選択肢がないことは悪いことであり、決定を下すには時間がかかります。選択肢が制限されると、ユーザーは大量のスプレッドシートとチェックリストを作成し、それを審査機関に提出して審査を受けることを余儀なくされますが、節約できる額はおそらくごくわずかです。

メーカーの変化に注目

クラウド コンピューティングの多くのコンポーネントは、互換性のある商用製品です。これらのコンポーネントは互換性がありますが、チームが注意しなければならない微妙な違いがまだあります。たとえば、あるクラウド サービスが他のクラウド サービスよりも早く PHP 8 に切り替えた可能性があり、別のクラウド サービスの価格設定と課金モデルが高帯域幅の使用に適していない可能性があります。サプライヤーとパートナーが増えると、ユーザーへの電子メール通知とビデオ会議が増え、年次対面会議での宣伝に費やす時間が増え、チーム全員の仕事も増えます。 「マルチクラウドの自由」の代償として、ユーザーは長期間にわたり、多数のベンダーからの発表、プレスリリース、電子メールに注意を払い、警戒する必要がある。

コード障害の可能性が増加

若者は誠実さを測るために「冗談だよ／冗談じゃない」といった言葉を好んで使うが、基準設定者も同様だ。理論的には、インターネットは、インターネット上のすべてのものが相互運用可能であることを保証する、慎重に作成された標準と切り離すことはできません。この発言は理にかなっていますが、実際には完全に真実というわけではありません。 Ubuntu、Python、またはその他のいわゆる標準バージョン間には常に小さな違いがあり、コードがこれらの違いに遭遇すると、異常な動作をしたり、クラッシュしたりすることがあります。複数のクラウド サービスでコードを使用する場合、コードにこのような小さな違いが発生する可能性が高くなります。奇妙なことに、こうした質問は土曜日の夜や休日に出てくる傾向があります。

遅れ

パケットを世界のどこか別の場所にあるデータセンターに送信するよりも、同じラック内のマシン間で送信する方が高速です。南極の安価なストレージを活用したい場合、マルチクラウド戦略ではレイテンシが長くなる可能性があります。多くの場合、一部のパケットはすぐに送信する必要がないため、遅延の問題は重要ではありません。たとえば、多くのバックグラウンド計算では高速性は必要ありません。しかし、アプリケーションの相互作用するコンポーネントをサポートするメイン ルーチンの場合は、コア マイクロサービスに近いほど効果的です。

トレーニング時間を増やす

クラウド サービスを選択するということは、ユーザーがサービス プロバイダーのビジョンと独自のインターフェイスを学習し、習得する必要があることを意味します。複数のクラウド サービスを選択するということは、ユーザーが複数回学習して習得する必要があり、チームは専門知識を継続的に蓄積する必要があることを意味します。このプロセスを簡素化する製品が利用可能です。

たとえば、Backblaze は Amazon S3 バケットをエミュレートするストレージ API をリリースしました。残念ながら、このタイプの製品は多くなく、ユーザーにとって N 個の選択肢は N 個のトレーニング セッションを意味します。

価格の罠

人気のオープンソース オペレーティング システムを実行する最新のインスタンスは、コモディティ化しているようです。ユーザーは、時間あたりの料金が最も安い製品を選択することが多いですが、そのような製品には重要な隠れたコストがいくつかあることに注意することが重要です。たとえば、一部のクラウド サービスでは、センターから送信されるデータに対して料金を請求します。一部のクラウド サービスは、長期的にはより良い収益をもたらす可能性があります。クラウド サービスの価格モデルには多くの考慮事項があり、ユーザーが最も低価格のクラウド サービス製品を選択したい場合、選択肢を慎重に評価する必要があります。これらのクラウド サービス製品は単なる商品のように見えますが、その価格モデルは通常の商品とは大きく異なります。

統合性が低い

ユーザーがクラウド サービス製品を選択した後も、やるべき作業は多く残っており、プロセス全体はユーザーが製品を提供するようなものです。チームが魔法のような力を発揮してコード レイヤーに重要な機能を追加できるとしても、最小限のコードしかアクセスできない場合は、それ以上の作業を行うことは非常に困難になります。多くの仕事では創意工夫をあまり必要とせず、多くのタスクは最も簡単な方法で達成するのが最善です。ユーザーの要件が高い場合は、クラウド サービスを 1 つだけ選択するのが最善の選択肢となる場合があります。その理由は、マルチクラウド アーキテクチャでは、多数のクラウド サービス オファリングの統合が最小限しか実装されていないためです。

割引はありません

クラウドベンダーは、大量購入、特に長期使用を約束する顧客に対して、大幅な割引を提供します。俊敏性を維持し、いつでも新しいクラウド サービスに移行できるようにしておくことは、ベンダー ロックインを回避するだけでなく、ベンダー割引を利用できないことも意味します。ユーザーが複数のクラウド サービスに費用を分散すると、ベンダーが大量購入に対して提供する割引を享受することが難しくなります。

信頼のジレンマ

ビジネスでは誰も信用してはいけません。ユーザーは、1 つのサービス プロバイダーに全面的に信頼を置かないことが賢明です。自由な選択はより多くのメーカーを信頼することを意味しますが、このアプローチはメーカーからの失望や裏切りの可能性を倍増させます。ユーザーはすべてのクラウド プロバイダーを信頼しているわけではありませんが、マルチクラウド アーキテクチャを運用するには、より高い信頼が必要です。信頼を数値化できる場合、マルチクラウド アーキテクチャに必要な信頼は、単一のクラウド プロバイダーに必要な信頼よりも数倍大きくなります。

さらなる法的な抜け穴

1 つのクラウド サービス プロバイダーに固執する利点の 1 つは、プロバイダーが責任を回避することが難しいことです。ユーザーがある会社から火災保険を購入し、別の会社から洪水保険を購入したとします。浸水により電気火災が発生した場合、ユーザーは、請求額の支払いは相手方の責任であると信じて、両社が言い争う状況に遭遇する可能性があります。複数のクラウドを選択するということは、ユーザーが複数のデフォルト契約に署名し、多くの契約を交渉する必要があることを意味します。これはまた、これらの契約と契約の間に抜け穴が多くなり、ユーザーがこれらの抜け穴を踏む可能性が高くなることを意味します。