盡管早在上世紀70年代，某些公司便開始使用早期形式的“云計算”，但這個現今我們耳熟能詳的概念的起源最多只能追溯到十年前而已。在這么短的時間內，云服務供應商和使用它們的組織數量已發生了爆炸性的成長。
然而今天，企業對于可供他們選擇的云選項的選擇變得越來越聰明，并且發展出判斷哪些應用程序和數據應該，或不應該被托管在公有云中的標準。事實上，一些組織已經開始退出云。也就是，許多公司正將他們業務的某些部分從公有云中抽離，一部分的原因是由于他們在內部支持一個混合云的能力有了進展。
當組織退出云：原因與面臨的挑戰
這種反向遷移的趨勢，被越來越多的人稱為退云，有許多的驅動因素。其中包括未能實現預期的財務優勢，意外的安全和合規問題，以及無法完成所需要的與遺留系統的深層次整合，種種這些使公有云不再是一個可行的方案。
一旦一個組織已經決定要退云，要將其基礎架構和數據遷移回去本地或一個共同托管設施時，它必須解決一系列的挑戰。這個公司將很快發現，離開公有云是一個復雜性不比遷移到公有云更小的過程。事實上，在某些方面，想倒退出來可能是一個更復雜的任務。
通常來說，最大的問題都是如何優雅地處理那些在組織的應用之間存在的依賴關系。緊接著的第二個問題是時機的問題。廠商必須在公有云提供商的維護時段中作業，而那些時段并不總是與公司自己的時刻表同步的。
另一個障礙是，那些必須實施到公有云環境中的外部遷移工具多半無法使用的殘酷事實。以及最后，當工作人員和其他資源在計算能力轉移到公有云時被重新分配到他處，組織現在又必須準備再次重新擔負起云相關任務的責任。
如何退云：最佳實踐的新趨勢
隨著云的逆向遷移變得越來越普遍，一組最佳的實踐已經漸漸開始成型。對于那些有能力將組織轉移到云端，或執行任何其他類型的技術轉化的IT服務企業來說，毫不奇怪的，在退云的時候，那些相同的原則也同樣適用。以下是八個讓退云過程可以順利的最佳實踐：
1.建立資產清單
作為第一步，你必須建立一份在云端所有資產的完整清單，包括應用和基礎架構組件。這一步完成得有多徹底，直接關系到你項目的成功與否。只對你遷移到云端時創建的列表做臨場抽查是不夠的。從那時到現在，很可能已發生許多環境上的改動，而遺漏任何增加或修改過的資產也可能會帶來嚴重的后果。
2.構建依賴關系圖
類似于你投資在一個資產清單的時間和精力，你必須完成一個同樣嚴謹的依賴關系圖。同樣，任何錯誤或遺漏都將影響到你退云過程的成功與否。
3.將應用映射到基礎架構
又是一次映射，將應用映射回基礎架構。當這一步完成之后，你就有一個可以進行之后工作的堅實基礎。
4.理解SLA
服務水平協議(SLA)是反向云遷移的另一關鍵因素。保證組織能夠在整個過程中繼續滿足這些SLA是衡量成功的關鍵。這就需要對協議的每一個細微之處都有深入的了解。
5.專注于應用
相比系統來說，企業應更注重于應用的退云。通常，以系統為基礎的方法會導致關鍵因素的處理不當以及不夠滿意的結果。以應用為中心的遷移可以降低風險。
6.預留測試時間
鑒于反向遷移往往必須發生在很短的時間段內，廠商和/或與他們合作的組織有時在測試方面會有所節省。這幾乎是一個以后肯定會回來困擾你的錯誤。
7.重新分配資源
那些在計算能力被轉移到云端時被重新分配的人員和資源必須在退云的時候轉移回來管理業務。讓你的云服務團隊到位并且準備好切換將幫助你完成一個順利的過渡。
8.尋求專門致力于云業務的
不管是遷移到云還是從云遷移出來都不是一個能掉以輕心的過程。那些想要確保他們的轉換成功的公司應該同擁有一個專門從事云業務的廠商合作，而不是那些只是涉足云計算作為一個分支副業的公司。
展望未來
除了前面提到的退云原因，再加上企業可以越來越容易的在內部管理自己的云，多半意味著反向遷移的趨勢仍會繼續下去。為了減少未來將可能需要退云的可能性，公司應該在前期投入更多的時間和精力確定哪些應用更適合公有或私有云。
他們也應該開始把他們的IT部門視為服務代理。在一個IT即服務的環境下運維的IT部門可以讓IT變得更加靈活和更快響應。
最后，要真正充分利用不同類型的云所提供的優勢，組織應該明白，我們最終的目標是正面的商業成果，所以無論公有，私有或混合云，都只是達到目標的一種手段。
京公網安備 11010502049343號