由于云計算行業(yè)的飛速發(fā)展，現(xiàn)在很多企業(yè)都致力于將關鍵企業(yè)應用程序遷移到公共云。在某些情況下，企業(yè)團隊在云遷移中遇到了困難，并且成果有限。但可以通過所學到的經(jīng)驗教訓在隨后的嘗試中改進結果。

如果企業(yè)正在尋求對任務關鍵型應用程序進行現(xiàn)代化改造，并且計劃將云遷移作為此過程的一部分，那么借鑒他人的經(jīng)驗則可以事半功倍。

因此，本文將通過這些知識來構建企業(yè)管理者需要考慮和解決的主要領域的 10 個步驟，以最大限度地提高成功遷移云的機會。

1、建立遷移架構師角色

在開始云遷移之前，需要建立遷移架構師角色來領導這項工作。遷移架構師是系統(tǒng)架構師級別的職位，負責規(guī)劃和完成遷移的所有工作流程。他們的核心職責應包括定義使遷移成功所需的必要重構、設計數(shù)據(jù)遷移策略、定義云解決方案要求以及確定遷移優(yōu)先級和生產(chǎn)切換機制。

在大型遷移項目的過程中，必須做出許多決策和技術計劃，而擁有一個負責遷移各個方面的遷移架構師對于項目的成功至關重要。

2、選擇云集成級別

當企業(yè)將應用程序從本地數(shù)據(jù)中心遷移到云時，可以通過兩種方式遷移應用程序 - 淺層云集成或深層云集成。

對于淺層云集成(有時稱為“提升和轉移”)，企業(yè)將本地應用程序移動到云中，并且為了運行應用。任何應用程序更改都足以讓它在新環(huán)境中運行，不使用云獨有的服務。此模型也稱為提升和轉移，因為應用程序“按原樣”提升并移動或轉移到云中。

對于深度云集成，企業(yè)可以在遷移過程中修改應用程序以利用關鍵的云功能。企業(yè)可以使用先進的自動擴展和動態(tài)負載平衡，或者它可能與將AWS Lambda等無服務器計算功能用于部分應用程序一樣復雜。它還可能涉及使用特定于云的數(shù)據(jù)存儲，例如Amazon S3或DynamoDB。

3、選擇單一云或使用多云

在開始云遷移之前，請對此問題進行思考：是想選擇一個云提供商并遷移您的應用程序，以便它針對該單一環(huán)境優(yōu)化運行，還是希望應用程序在多個云提供商上運行?

優(yōu)化應用程序以與特定的云提供商一起工作相對簡單。開發(fā)團隊只需學習一組云 API，應用程序就可以利用云供應商提供的一切。

這種方法的缺點是供應商鎖定。一旦企業(yè)更新了應用程序以僅與一個提供商合作，將應用程序移動到另一個提供商可能需要與原始云遷移一樣繁雜的流程。此外，擁有單一云提供商可能會對企業(yè)與云提供商協(xié)商重要條款(例如定價和 SLA)的能力產(chǎn)生負面影響。

而且，它也變得更加復雜。使用多個云提供商有幾種不同的模型：

(1) 一云一應用。另一個云中的另一個應用程序。也許最簡單的多云方法在一個云提供商中運行一組應用程序，在另一個云提供商中運行另一組應用程序。這種方法使企業(yè)可以提高與多個提供商的業(yè)務杠桿作用，以及將來在何處放置應用程序的靈活性。它還允許企業(yè)針對運行它的提供程序優(yōu)化每個應用程序。

(2) 跨多個云提供商拆分應用程序。一些公司選擇在一個云提供商中運行應用程序的一部分，而在另一個云提供商中運行它的其他部分。這種方法讓企業(yè)可以利用每個提供商提供的關鍵優(yōu)勢(例如，一個提供商可能具有更好的 AI 功能，而另一個提供商可能以其數(shù)據(jù)庫速度而聞名)。這里的風險是企業(yè)的應用程序與兩個提供商的性能相關，任何一個提供商的任何問題都可能影響應用程序的客戶體驗。

(3) 將應用程序構建為與云無關。使用這種方法，企業(yè)可以在多個提供商上同時運行應用程序，或者將應用程序負載分散到它們之間。該模型為企業(yè)在供應商談判中提供了最大的靈活性，因為企業(yè)可以輕松地將負載從一個云提供商轉移到另一個云提供商。缺點是會造成很難使用每個云提供商的關鍵功能，從而降低了將應用程序托管在云中的好處。

4、建立云 KPI

關鍵績效指標 (KPI) 是企業(yè)收集的有關應用程序或服務的指標，用于衡量其執(zhí)行情況是否符合預期。云遷移的最佳 KPI 顯示了企業(yè)正在進行的遷移是如何進行的，闡明了可能潛伏在應用程序中的可見或不可見的問題。也許最重要的是，云遷移 KPI 可以幫助企業(yè)確定遷移何時完成并成功。

云遷移 KPI 有幾個關鍵類別：

對于每個類別，確定哪些指標對自身業(yè)務最重要，哪些指標將受遷移到云的影響最大。

5、建立績效基準

基線是測量應用程序或服務的當前(遷移前)性能的過程，以確定其未來(遷移后)性能是否可以接受。基線可幫助團隊確定遷移何時完成，并驗證預期的遷移后性能改進。還可以在云遷移期間參考基線來診斷出現(xiàn)的任何問題。

管理者需要決定衡量的每個 KPI 設置基線指標。確定將收集數(shù)據(jù)多長時間以確定基線。選擇較短的基線期(例如一天)可以讓團隊更快地行動，但可能無法收集到具有代表性的績效樣本。選擇更長的基線時間(例如一個月)顯然需要更多時間，但可以提供更具代表性的數(shù)據(jù)。

團隊管理者還需要確定是否只想收集平均或代表性的基線數(shù)據(jù)，或者是否希望包括在“高峰”或“關鍵”時期收集的數(shù)據(jù)。無論哪種數(shù)據(jù)收集模型適合所在行業(yè)，請務必明確定義要收集的數(shù)據(jù)類型和時間段。

6、優(yōu)先考慮遷移組件

企業(yè)管理者還必須決定是一次遷移整個應用程序，還是將其逐個組件或逐個服務遷移到云組件。

首先，確定服務之間的連接以及哪些服務依賴于哪些其他服務。使用依賴關系圖來決定應該遷移哪些組件以及以什么順序遷移。從具有最少依賴關系的服務開始通常是有意義的。

在這種情況下，需要首先遷移最內(nèi)部的服務，然后跟進最外部的服務——通常是最接近客戶的服務。另一種方法是從最接近客戶的服務(最外部的服務)開始，這樣就可以控制對客戶的所有影響。

7、執(zhí)行任何必要的重構

企業(yè)可能希望在遷移應用程序和服務之前對其進行其他工作，以便它們在云中盡可能有效和高效地工作。例如，他們可能想要重構應用程序：

因此，它可以有效地與可變數(shù)量的運行實例一起工作，以允許動態(tài)擴展，從而可能節(jié)省云服務成本。

這樣，企業(yè)的資源利用率就可以更好地利用動態(tài)云功能，例如根據(jù)需要動態(tài)分配和取消分配資源的能力，而不是提前靜態(tài)分配資源。

在遷移之前遷移到更加面向服務的架構，以便企業(yè)可以更輕松地將單個服務遷移到云中。

8、創(chuàng)建數(shù)據(jù)遷移計劃

遷移數(shù)據(jù)是云遷移中最棘手的部分之一。數(shù)據(jù)的位置會顯著影響應用程序的性能。當數(shù)據(jù)訪問方法仍然主要是在本地時將數(shù)據(jù)移動到云會顯著影響性能。如果數(shù)據(jù)仍然在本地，但訪問它的服務駐留在云中，情況也是如此。

數(shù)據(jù)遷移的選項包括：

• 在本地數(shù)據(jù)庫和云數(shù)據(jù)庫之間使用雙向同步機制。將所有數(shù)據(jù)使用者移至云后，刪除本地數(shù)據(jù)庫。
• 使用與基于云的數(shù)據(jù)庫單向同步的本地數(shù)據(jù)庫，并允許消費者僅連接到本地版本。準備就緒后，禁用對本地版本的訪問，以便基于云的版本成為主數(shù)據(jù)庫，并啟用基于云的消費者對新數(shù)據(jù)庫的訪問。

9、切換生產(chǎn)

企業(yè)何時以及如何將生產(chǎn)系統(tǒng)從舊的本地解決方案切換到新的云版本?答案取決于應用程序的復雜性和架構，尤其是數(shù)據(jù)和數(shù)據(jù)存儲的架構。

有兩種常見的方法：

• 一次性完成。等到將整個應用程序或服務移到云上并驗證它可以在那里工作，然后將流量從本地堆棧切換到云堆棧。
• 一次做一點。移動一些客戶，測試一切是否仍然有效，然后再移動一些客戶。繼續(xù)此過程，直到將所有客戶轉移到基于云的應用程序。

10、查看應用程序資源分配

即使在完成將所有內(nèi)容遷移到云之后，還有一些事情需要考慮。最重要的是資源優(yōu)化。云針對動態(tài)資源分配進行了優(yōu)化，當靜態(tài)分配資源(例如服務器)時，企業(yè)并沒有利用云的優(yōu)勢。

當遷移到云中時，請確保團隊制定了將資源分配給應用程序的計劃。當需要為云中的應用程序分配額外的資源時，供應商通常可以隨時從供應商處獲得幾乎任何數(shù)量的資源。

文中的十 個步驟涵蓋了很多內(nèi)容，但在云遷移過程中，還應該考慮其他事項。例如，創(chuàng)建安全可靠的云環(huán)境顯然是所有云遷移的關鍵部分。幸運的是，主要的云提供商提供了重要的工具和資源來幫助企業(yè)構建和維護一個安全的系統(tǒng)。