クラウドロックインのリスクを最小限に抑えるためのアーキテクチャ戦略？

Question

クラウドベースのシステムのベンダーロックインのリスクを軽減する最良の方法は何かを理解したいと思います。

たとえば、Amazon EC2やWindows Azureなど、さまざまなシステムを導入したいと考えていますが、必要に応じてこれらのシステムを別のクラウドベンダーに移行するコストを最小限に抑えたい。

少なくとも、ベンダー固有のソリューション（Amazon Queue Serviceなど）に依存するほど、私は本質的にロックされています（少なくとも私はそうだと思いますが）。このリスクをより良く理解してください。

これを軽減するためのアーキテクチャ戦略はありますか（たとえば、スクリプトが別のマップへの移植性が高いため、マップの削減に頼っている） O/Sや他のものより優れたスタックがあるか（Linux、LAMP？） JCloudsを使用していますか？

理想的には、たとえば、EC2にデプロイできるがAzureまたはApp Engine（またはその逆）に簡単に移行できる仮想システムを設計したいと考えています。

私は一般的にJavaで書いていますが、ScalaとPython（またはJython）の選択的な使用を考えていますが、一般的にはまだJVMベースのままです。私は多くの並列処理を行う傾向があり、SQLと非SQL（ただし、NoSQLは必要ない）ストレージとデータ操作技術の両方に頼っています。

ありがとうございます。私はあまりにも非現実的ではないと思う。私の意見で

Answer 1

、あなたが記述問題への唯一の建築パターンは次のとおりです。などのストレージ、キュー、のようにそれぞれの抽象化レイヤーを作成し、抽象化

は、様々なベンダー間で提供されているリソースを使用してに固執することを確認しますそのうちの。

これが役に立ちます。私は、クラウドプロバイダー間でサービスの多様性を考えれば、それは非常に簡単な仕事だとは思わない。

Answer 2

私はIgoreKに同意する。コードでこれをやっているなら、抽象度がかなり高い。それについて。

もう1つの選択肢は、IaaSクラウドのアプローチです。アプリケーションを仮想マシンの役割のみに基づいて設計します。ほとんどのクラウドプロバイダーは、Amazon、Azure、Rackspaceなどの仮想マシンの役割を提供しています。マイグレーションは、コードの変更がはるかに少ないことを意味します。

Answer 3

正直、あなたの質問は、誤った前提のビットに基づいています。あなたが使用するように選択したプラットフォームを最大限に活用しようとするのではなく、ロックインを避けることを目指しています。

問題を解決するには、インフラストラクチャをホットスワップ可能（ベンダーロックインを避けるなど）にするのではなく、実際に使用するIaaSプロバイダについてをに、可能な限り最高のものを活用してください。

Answer 4

マイクロソフトのカスタマーアドバイザリーチームは優秀なsample on how to do thatです（私はここからプロジェクトをダウンロードしたと思います）。そこにはたくさんのコードがあり、物事を「自由」にするための抽象概念があります。明らかに、抽象化の場合と同様に、新しい複雑さのレイヤーを導入するので、実際にそれを適用する前にすべてを確認してください。

ほとんどの場合、それ以下です。ロックインはあなたが望むものではありませんが、必要が生じた場合には "修正"するのは難しいことではないでしょう。しかし、今、満足する必要があることが重要であるか、プロジェクトを終了して後でリファクタリングする必要があるかどうか、自分自身に尋ねてください。