我對基於雲的系統有疑問。基本指導原則是「按使用付費」，「軟件即服務」或「基礎架構即服務」。這些是服務提供商提供的多種產品。基於雲的解決方案 - 數據遷移面臨的挑戰？
假設我有一個以SQL Azure作爲數據庫的基於Microsoft雲的系統。明天，我想將它移植到另一個前亞馬遜雲供應商。
我們是否處於一種無縫遷移方法，用於將應用程序數據從一個基於雲的服務提供商轉移到另一個。
從長遠的角度來看，我的問題更側重於如何在雲中管理應用程序。
發現了回答我的問題
5個昂貴的雲遷移錯誤的文章 - http://www.privatecloud.com/blog/?fbid=xEEiydK0SQY
我看了你的問題，因爲便攜性在雲中託管的數據構建的解決方案的。迄今爲止，這是一個具有挑戰性的問題。沒有指導可移植性要求的標準，但確定有工具/服務可幫助您克服缺乏可移植性的標準。
幾個點（挑戰注意），我在這樣的遷移已經考慮的是 -
服務提供阻抗 - 雲供應商之間的服務產品是通過競爭帶動，由標準。例如AWS IAM沒有直接映射到Azure Active Directory。儘管您可以使用SAML標準聯合他們。如果您正在爲想從AWS遷移到Azure的客戶工作（僅用於交談），沒有Out of Box解決方案，您需要爲此構建一個定製工具。而反過來（Azure AD - > AWS）如果不是PaaS，至少可以作爲IaaS。雲服務提供商之間的安全粒度（使用策略在AWS中受保護的對象，Azure具有SAS並且需要定製構建的SAS提供商爲您提供類似的功能）會帶來最大的安全挑戰。服務阻抗也可以以Azure的形式表現出來，您可以擁有不同類型的Blob - Page，Append，Block。但是，在AWS中，S3存儲桶對象不存在此類別。現在，如果您已經構建了適用於Azure中的Append blob的應用程序邏輯，現在您正在將應用程序遷移到AWS，則需要編寫邏輯來下載對象，添加所需的數據，然後上載新的對象以及刪除現有對象。這樣的變化有時可能會帶來架構變化的後果。
SLA阻抗 - 服務是在雲服務提供商常見的某些基本單元上計量的。但是，用於計費的計量單位和參數存在細微差異。例如AWS將根據 - 區域，大小，請求數量，以GB爲單位的AWS基礎架構的數據傳輸出（出）量來收取非結構化存儲。而Azure將根據 - 區域，大小，請求量，來自Azure infra的數據出口量以及您將選擇的數據冗餘選項收取相同的非結構化存儲。因此，在您遷移時，您需要衡量此類SLA差異，並在目標平臺中選擇正確的服務計劃。如果您正在從Azure遷移到AWS並現在擁有基於SLA的冗餘，則您可能必須支付更多費用或在AWS中引入其他服務才能保持服務產品的連續性。
工具& API阻抗 - 雲服務提供商對可編程接口的支持非常多樣化。但他們兩人之間不需要相似。 REST通信協議，JSON/XML標準可以拯救我們。那些已經在雲端服務一段時間的人很可能會建立一些工具來幫助管理雲服務的生命週期。使用他們的工具集遷移這樣的客戶需要考慮替換服務提供商提供的工具所需的努力，以及努力更改使用服務提供商的API構建的任何專有工具的努力。
在遷移作業中，我使用操作系統類比來解釋（我和客戶）面臨的挑戰。即在一開始就有操作系統，每個操作系統都有特殊的功能，但它們都不兼容，互相通信和交換數據。這影響了企業開始實現這一挑戰。緩慢的標準發展，現在我們可以交換數據並使操作系統彼此交流（虛擬化）。考慮將雲平臺作爲操作系統，然後給它一些時間（不知道有多少）來克服這種阻抗。到那時，我們將面臨從一個服務提供商轉移到另一個服務提供商所面臨的挑戰（當然可以克服很大程度的問題），使用類似您所列的工具和更多的諮詢服務以及服務來解決業務環境中非常具體的遷移挑戰。
以下所有內容均由合適的供應商解決。 首先，雲遷移的主要風險是數據損壞 - 異常或冗餘或重複的數據，或缺少以前存在的數據 - 發生的原因是目標雲之間可能缺少最大同步。 其次，存在語義風險 - 沒有數據丟失或損壞，遷移被認爲是成功的，但有時遺留列和目標列的含義具有相同的含義，但是它們的測量不同並且數據的含義完全不同。 對我來說，那些是兩個主要問題，因爲我在過去遇到過一個不成功的供應商。雲遷移適當的服務並不便宜，因此我強烈建議爲您選擇正確的選擇。我已經變成了虛擬商品，我對他們作爲雲供應商感到滿意。再次，不是一項便宜的服務 - 但我相信如果你投入資金，你應該得到最好的。
TL; DR：構建跨IaaS提供者的最低公共標準。
這樣做的簡單答案是嚴格地將IaaS提供程序僅用於基礎架構，而不是用於其「服務」。
做到這一點的一個好方法可能只是在您的雲應用程序中執行terraform允許您執行的操作。有趣的是，像Docker，Kubernetes這樣的工具使基礎架構不可知的應用程序變得更加容易，並且幫助您實現這一目標的解決方案數量顯着增加。構建於Openshift，cloudfoundry等上的應用程序可幫助您在各個雲供應商之間進行標準化。還有更多的開發人員友好型工具也在涌現，它們使用k8s/docker來構建供應商不可知的應用程序：deis,dokku,hasura。免責聲明：我在Hasura工作。
具體回答你的問題：
假設我有一個SQL Azure的微軟雲計算爲基礎的系統作爲其 數據庫。明天我想將它移植到另一個雲提供商 ex-Amazon。
不，如果你這樣做，你不能成爲「多雲」。
我們是在我們有一個無縫的遷移方法爲 從一個基於雲的服務提供商的應用數據移動到另一個 的狀態。
我們還沒有完全存在。但我們正在朝着這個方向前進。請參閱我上面分享的細節。