マルチクラウド神話は崩壊: ワークロードのポータビリティが幻想である理由

マルチクラウド神話は崩壊: ワークロードのポータビリティが幻想である理由

マルチクラウド モデルは業界で認知度が高まっており、企業は複数のクラウド プロバイダーからさまざまな IT サービスを取得し、同時に一部の IT 作業をローカルに展開したままにしています。しかし、マルチクラウド モデルの問題は、あるクラウドから別のクラウドにワークロードを移動するプロセスがベンダーが約束したほどスムーズではないことに企業が気付いたときに発生します。

ただし、先に進む前に、マルチクラウド モデルについて説明する必要があります。

[[210207]]

マルチクラウドの定義

ここ 1 ~ 2 年で、IT 業界ではマルチクラウドの概念が登場しました。一般的には、企業が 1 つ以上の SaaS サービス (人事やメール サービスなど) を使用し、ソフトウェア開発に PaaS サービスを使用するだけでなく、仮想マシン上で作業するために IaaS サービスも使用するモデルを指します。

「一部のクラウドプロバイダーは特定のワークロードに特化した機能を備えているため、複数のパブリッククラウドサービスを同時に利用する顧客が増えている」と、ガートナーのテクノロジーおよびサービスプロバイダー調査部門のリサーチディレクター、マシュー・チュン氏は述べた。

これらの専門サービスには、Microsoft Azure の SQL Server や、Google Cloud の人工知能 (AI) およびデータ分析サービスなど、多くの主要なエンタープライズ アプリケーションが含まれます。 AWS のような大手企業も多くの具体的な機能やサービスを持っており、毎年新しいものをリリースし続けています。

「混合」クラウドソリューション

クラウド移行の初期段階では、多くの企業が「リフト アンド シフト」アプローチを通じて IaaS サービスを使用し、ワークロードをローカル モデルから移行します。このモデルでは、多くの場合、企業は従来のサーバーを置き換えるために仮想マシンを構成し、実際にはクラウド アーキテクチャでローカルに展開された環境を複製します。

意図的か否かにかかわらず、多くの企業はワークロードを複数の IaaS プラットフォームに展開しています。これは、データ主権、反拘束力、または冗長性の問題が原因である可能性があります。

ハイブリッド クラウド製品やサービスを宣伝するベンダーは、こうしたことはまったく問題ではなく、ユーザーがより優れたクラウドを発見したり、他の企業が必要とする新しい機能やサービスを導入したりすると、作業をあるクラウドから別のクラウドに簡単に移行できると約束しています。

しかし、企業が移行先のクラウドが自社のワークロードに適していないと判断した場合、移行はそれほど簡単になるのでしょうか?ハイブリッド クラウド ベンダーは、移行はコピー アンド ペーストと同じくらい簡単であると常に人々に信じ込ませようとしますが、実際には、そのプロセスは困難を伴います。

マルチクラウドモデルの神話を打破する

まず、異なるベンダーのサーバー インスタンス (データベース) の特性は大きく異なる場合があり、パッケージや仮想マシン イメージなどのオープン フォーマットが利用可能であるにもかかわらず、実際にはほとんど使用されていません。さらに、従来の 3 層アプリケーションでは通常、別々のサーバー クラスター上のデータベースにアクセスする必要があり、移行が複雑になります。つまり、あるクラウドから別のクラウドに作業を移行する場合、仮想マシンは理想的な選択肢ではありません。

もちろん、企業にはコンテナという別の選択肢もあります。 Docker テクノロジーとその名を冠したプラットフォームの登場以来、コンテナは開発者にアプリケーション コードのパッケージ化を容易にし、それを公開してローカルまたはクラウドで実行できるようにする手段を提供してきました。

仮想マシンと比較すると、コンテナには移植性という大きな利点があります。コンテナのサイズは通常数十メガバイトですが、オペレーティング システムとアプリケーション全体を含む仮想マシンのサイズは通常数ギガバイトです。

一般的に、コンテナーは実際には Linux テクノロジであり (最近導入された Windows コンテナーを除く)、現在企業のすべてのシステムで実行されている従来のエンタープライズ アプリケーションではなく、パブリック クラウド上でいわゆるオンプレミス ワークロードを実行するために主に使用されます。

仮想マシンと比較すると、コンテナ技術は現時点では未成熟であるため、そのエコシステム全体が急速に構築されており、コンテナベンダーもセキュリティ、高可用性、主要リソースに関するさまざまなソリューションを提供しています。

しかし、その場合でも、ワークロードが VM やコンテナ上で完璧に実行されるとは限らないため、あるクラウドからワークロードを単純に抽出して別のクラウドに移動する可能性は低いと Cheung 氏は言います。代わりに、人々は他の機能やサービスに頼る傾向があります。さまざまなクラウド プラットフォーム間の違いは非常に大きいため、ワークロードが非常に単純で分離されていない限り、ワークロードを別のクラウドに単純に移動することは困難です。 「現在、異なるパブリッククラウド間でワークロードを移動するのは非常に困難です」と Cheug 氏は言います。

Red Hat の OpenShift プラットフォームは典型的な例であり、ユーザーは Docker とコンテナを使用してアプリケーションを構築およびデプロイできます。ユーザーはローカルにデプロイできるだけでなく、Microsoft Azure、AWS、Google Cloud Platform へのデプロイもサポートされます。理論的には、OpenShift を使用すると、ユーザーはこれらのプラットフォーム間で任意のアプリケーション コードを移動できるようになります。しかし、それでも依存関係の問題は残ります。ユーザーのアプリケーションが特定のクラウド プラットフォームの特定の機能やサービスに依存している場合、これらのアプリケーションを他のプラットフォームに移行することは困難になります。また、ベンダーロックインの問題により、より便利な機能やサービスが無駄になるため、ユーザーはそれらの機能やサービスを使用できなくなります。

サーバーレス コンピューティングの空約束

企業は、PaaS サービスに加えて、いわゆるサーバーレス コンピューティングも検討できます。これは、アプリケーションが使用量に基づいて課金されるモデルで、「Function as a Service」または「FaaS」と呼ばれます。 AWS の Lambda がその一例です。

ほぼすべてのサーバーレス プラットフォームは Python をサポートしているため、この言語で記述されたアプリケーションは、異なるサーバーレス プラットフォーム間で簡単に移行できます。異なるクラウドが異なる機能をサポートする場合、問題は再び発生します。共通のコード ベースが存在し、企業がクラウド固有の機能やサービスへのリンクを回避できない限り、移行プロセスはシームレスにはなりません。

クラウド ポータビリティの実現を妨げるもう 1 つの障害は、実際のデータにあります。コンプライアンスまたは規制上の理由により、特定の種類の情報を社外に移動することは事実上不可能です。

また、データ センターの所在地や、特定のワークロードを実行するために必要な認定レベルを持つベンダーが限られているなどの理由で、企業が他のクラウド ベンダー プラットフォームを選択する際に問題が発生することもあります。

さらに、関係するデータの量も問題になる可能性があります。もちろん、今日のユーザーは比較的高速なインターネット接続速度を享受できますが、さまざまな制限(サイバー攻撃、地理的な場所、ネットワークの安定性など)により、インターネットを介してデータを送信するプロセスには数日、あるいはそれ以上の時間がかかる場合があります。

ローカルからクラウドへのデータの移行作業は、ディスクベースのデバイスを介して実行でき、クラウド プロバイダーのデータ センターに発送するだけで済みます。 AWS の Snowball はそのようなソリューションです。ただし、クラウド サービス プロバイダーごとに異なる API とデータ ストレージ標準が使用されているため、あるクラウド プラットフォームから別のクラウド プラットフォームにデータを転送するプロセスはそれほど簡単ではありません。そのため、データの抽出と転送に大きな障害が発生します。同時に、クラウド プロバイダー間の価格モデルの違いにより、ユーザーがデータを抽出して送信するコストも増加する可能性があります。

企業は依然として注意が必要

上記の問題により、対応するクロスプラットフォームのクラウド管理ツールはまだ未熟であり、ガートナーは最近のレポートでこれを「新興かつ高度に細分化された市場」と表現しました。

クラウド コンピューティングおよびインフラストラクチャ ベンダーには独自の管理ツールがありますが、主に独自のソフトウェアとの統合方法に重点を置いています。サードパーティベンダーが何らかの形でマルチクラウド対応サービスを提供できるようにします。この状況により、IT 部門は、マルチクラウド環境を監視するために「最善の」管理ツールを組み合わせるか、機能が制限されたクロスプラットフォーム管理ツールを使用するしかありませんでした。

コンテナなどのテクノロジーがこの困難を克服しようとしていますが、現時点では、クラウド プラットフォーム間でのワークロードとデータのモビリティは依然として非常に重要な問題です。したがって、異なるクラウド サービスを使用することを決定した場合、異なるクラウド サービス プロバイダー間でワークロードを移動することは非常に困難でコストがかかる可能性があるため、企業はクラウド戦略を策定する際には慎重に行う必要があります。

<<:  企業はクラウドコンピューティングの支出に100億ドル以上を無駄にする:その理由

>>:  Shuren Cloud の Wang Pu: 3 つの主要な技術トレンドが PaaS の新たな変数を定義する

推薦する

惨めなウェブマスターは、記事を更新したり外部リンクを投稿したりする生活をいつ終わらせるのでしょうか?

SEO 作業に関しては、多くのウェブマスターが複雑で混沌としていると感じています。そうでなければ、彼...

JDアリアンツ保険はデジタル変革をリードし、30分で保険金請求を解決して利益を得ています

2020年2月、JDアリアンツ保険は、保険契約者である孫さん(仮名)から報告を受け、彼女が残念ながら...

安価な日本の専用サーバー: 月額 99 ドル、2*e5-2680/32G メモリ/1T HDD/50M 最適化帯域幅 (トラフィック無制限)

raksmart は現在、日本の東京データセンターの専用サーバーのクリアランス セールを行っています...

テンセントモバイル広告連盟の控えめな内部テストは、市場の大きな再編につながる可能性がある

複数のモバイル開発者が記者に対し、業界で長らく噂されていたテンセントの「広電通」モバイル広告連合が最...

百度百科事典ランキング神話の独占暴露

まず、質問させてください。中国で最高の SEO は誰だと思いますか? 答えは Fu Wei でも L...

権限を失わずに改訂するための手順2と3

多くの企業にとって、改訂は必須です。なぜ私がこう言うのか?それは、ほとんどの企業が自社の企業ウェブサ...

小泉:サイトがホームページに載っていない問題を解決する方法を教えます

フォーラムで、サイトがホームページに載っていない場合にどうすればよいかを尋ねる人によく出会います。こ...

百度の有名人検索の刷新後のユーザー体験の簡単な分析

今日、百度で有名人を検索したところ、百度がユーザー体験を向上させるために検索結果に新たな改善を加えた...

virmach-月額$1/KVM/256mメモリ/2CPU/15gハードディスク/1Tトラフィック/Gポート/フェニックス/ダラス

virmach はコンソール キャットに 5 回登場しており、最も古い登場はその年の 7 月です。こ...

これからのインターネットマーケティング必修コース:CEOに正しい個性を与える方法

2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っていますCEOマー...

PythonでSaga分散トランザクションを簡単に完了する

[[422283]]銀行間送金業務は、典型的な分散型トランザクションのシナリオです。 A が銀行間で...

SEO 最適化の価格はなぜこんなに高いのでしょうか?答えはすべてここにあります

ショートビデオ、セルフメディア、インフルエンサーのためのワンストップサービス以前、入札を行っていたク...

事例分析: Baidu が通常のウェブサイトの再設計をどのように扱うか

SEO 担当者であれば、改訂が検索エンジン上のウェブサイトに影響を与えることは誰もが知っています。影...

SEOVIPでウェブサイトページを最適化する方法をご覧ください

最近、人気のSEOIPウェブサイトの単一ページランキング効果は、SEOの世界ではもう一つの神話になっ...

中秋節と国慶節ゴールデンウィーク中にSEO作業を行う方法

SEO作業は継続的なものです。途中で長期間停止すると、ウェブサイトのランキングに影響します。中秋節や...