クラウドベースのシステムについて質問があります。基本的な指針は、「従量課金制」、「サービスとしてのソフトウェア」、または「サービスとしてのインフラストラクチャ」です。これらは、サービス プロバイダーによる複数のオファリングです。
データベースとして SQL Azure を使用する Microsoft Cloud ベースのシステムがあるとします。明日、Amazon などの別のクラウド プロバイダーに移植したいと思います。
あるクラウドベースのサービス プロバイダーから別のサービス プロバイダーにアプリケーション データを移動するためのシームレスな移行アプローチを採用している状態ですか?
私の質問は、クラウドでアプリケーションを管理する方法に長期的に焦点を当てていました。
あなたの質問は、クラウドでホストされているデータに基づいて構築されたソリューションの移植性と読みました。これは日付のように難しい問題です。移植性の要件を指示する標準はありませんが、移植性の標準がないことを克服するのに役立つツール/サービスがあることは確かです。
このような移行で考慮したいくつかのポイント (注意すべき課題) は、次のとおりです。
サービス提供インピーダンス- クラウド プロバイダー間のサービス提供は、競争によって推進され、標準によって指示されます。たとえば、AWS IAM には Azure Active Directory への直接マッピングがありません。ただし、SAML 標準を使用してそれらをフェデレートすることはできます。AWS から Azure への移行を希望している顧客のために働いている場合 (会話のためだけに)、Out of Box ソリューションはありません。このために調整されたツールを構築する必要があります。一方、少なくとも IaaS ほど PaaS でなくても、逆 (Azure AD -> AWS) は可能です。クラウド サービス プロバイダー間のセキュリティ保護可能な粒度 (AWS ではポリシーを使用してオブジェクトを保護できます。Azure には SAS があり、同様の機能を提供するにはカスタム ビルドの SAS プロバイダーが必要です) は、セキュリティ上の最大の課題をもたらします。サービス インピーダンスは、たとえば Azure では、さまざまな種類の Blob (ページ、ページ、追加、ブロック。ただし、AWS には、S3 バケット オブジェクトのそのようなカテゴリはありません。ここで、Azure で Append BLOB を想定するという考えに基づいてアプリケーション ロジックを構築し、アプリケーションを AWS に移行しようとしている場合は、オブジェクトをダウンロードし、必要なデータを追加してから、新しいオブジェクトを削除するとともに、既存のオブジェクトを削除します。このような変更は、アーキテクチャの変更の結果をもたらす場合があります。
SLAインピーダンス- サービスは、クラウド サービス プロバイダー全体で共通の特定の基本単位で計測されます。ただし、請求に使用される測定単位とパラメーターには微妙な違いがあります。たとえば、AWS は、リージョン、サイズ、リクエストのボリューム、AWS インフラストラクチャからのデータ転送 (エグレス) のボリューム (GB 単位) に基づいて非構造化ストレージを課金します。一方、Azure では、リージョン、サイズ、要求のボリューム、Azure インフラストラクチャからのデータ出力のボリューム、および選択したデータ冗長オプションに基づいて、同じ非構造化ストレージに対して課金されます。したがって、移行中に、このような SLA の違いを測定し、ターゲット プラットフォームで適切なサービス プランを選択する必要があります。Azure から AWS に移行していて、現在冗長性ベースの SLA を持っている場合は、サービス提供を継続するために、より多くの料金を支払うか、AWS に他のサービスを導入する必要があるかもしれません。
ツールと API インピーダンス- クラウド サービス プロバイダーは、プログラム可能なインターフェイスに対して非常に多様なサポートを提供しています。しかし、それらは 2 つの間で類似している必要はありません。REST 通信プロトコル、JSON/XML 標準が私たちを救ってくれるかもしれません。クラウドをしばらく使用している人は、クラウドでサービスのライフサイクルを管理するのに役立つツールを確立している可能性が非常に高いです。そのような顧客をツールセットとともに移行するには、サービス プロバイダーが提供するツールを置き換えるために必要な労力と、サービス プロバイダーの API を使用して構築された独自のツールを変更するための労力を考慮する必要があります。
移行の課題では、オペレーティング システムのアナロジーを使用して (自分自身と顧客に) 課題を説明します。つまり、最初は、それぞれが特別な機能を持っていた OS がありましたが、それらはすべて、相互に互換性がなく、相互に通信してデータを交換することができませんでした。これは、この課題を認識し始めたビジネスに影響を与えました。ゆっくりと標準が進化し、現在ではデータを交換し、OS を相互に通信させることができます (仮想化)。クラウド プラットフォームを OS と見なし、そのようなインピーダンスを克服するための時間を与えます (どのくらいかはわかりません)。それまでは、あるサービス プロバイダーから別のサービス プロバイダーに移行する際に、お客様が挙げたようなツールやその他のいくつかのツール、およびビジネス コンテキストでの非常に具体的な移行の課題に対処するためのコンサルタント サービスを使用する際に、課題に直面することになります (これは確かにかなりの範囲で克服できます)。
私の質問に答える記事を見つけました
費用のかかるクラウド移行の 5 つの間違い - http://www.privatecloud.com/blog/?fbid=xEEiydK0SQY