遷移到 AWS 雲端：該做和不該做

假如有一天，有人告訴你必須遷移到 AWS/GCP/Azure/或其他任何雲端服務供應商，這很可能會讓你感到壓力山大，這還是輕描淡寫了。

在我的職業生涯中，我見證了不少遷移案例，在這篇文章中，我想分享一些想法，幫助DevOps工程師、架構師、經理或任何可能參與此類遷移的人。我主要聚焦於遷移到 AWS 的案例，一來是因為我在這方面有專長，二來是因為這相當常見，但我認為這些經驗同樣適用於任何其他雲端服務供應商。在這個案例中，我會講述從本地遷移到雲端的情況，因為在我看來，這種類型的遷移要比雲對雲的遷移難得多。我也會分享我自己對遷移中該做和不該做的看法。但請透過批判性思維來篩選這些建議，記住每個人都有自己的背景和經驗。對某人有益的事，對另一個人可能就不適合。

什麼是雲端遷移？

首先，我們來定義什麼是遷移。怎樣才算是遷移呢？我偏好以下的定義：

雲端遷移是將數據中心的能力移轉至基礎設施即服務（IaaS）提供商的過程。

「能力」是關鍵字。企業遷移的不是伺服器／虛擬機器／硬體／數據或其他任何事物。企業遷移的是其能力。

有七種遷移策略（或稱七R）：重新定位、重新託管（提升並轉移）、重新平台化、重新購買、重構／重寫、保留與退役。

例如，我見過公司為了替代原有在地部署的產品而開發新產品的情況。這產品從一開始就設計為良好架構且原生於雲端的，並將被雲端託管。這算是遷移還是綠地項目類型？根據上述定義，我們可以說這是一種遷移。這是遷移的重構策略。

如果我們購買了一個新的SaaS訂閱，以取代我們在地部署的一些軟體呢？這也是一種遷移：一種重新購買策略。

讓我們更深入探討這七種遷移策略：

重新定位。我們在地部署一些工作負載，並將它們原封不動地移至雲端。在限定情況下這是可能的；當我們遷移雲端中立的工作負載，或當一個平台可能是原生雲端的時。例子：將Kubernetes集群從在地部署遷移到雲端，或將VMware機器與VMware Cloud一起遷移。

重新託管。這也被稱為提升並轉移。我們將在地部署的虛擬機器／伺服器轉換為雲端中的虛擬機器。例子：將在地部署的虛擬機器遷移至EC2實例，使用CloudEndure，或創建EC2實例，安裝軟體並應用與在地部署相同的配置。

重新平台化。我們將一個工作負載遷移到一個雲端原生平台，而不重構系統。例子：將PostgreSQL遷移到AWS RDS或將Docker容器遷移到ECS。

重新購買。我們用SaaS替換某些自定義／遺留系統。例子：用SendGrid替換自定義的在地部署電子郵件系統，或用Salesforce替換CRM。

重構。我們改變應用程式的架構，使其成為雲端原生並使用管理的雲服務。這也包括從頭重建。例子：改變應用程式的代碼以將檔案上傳到S3而非本地儲存，或將應用程式容器化並遷移到ECS。

退役。我們決定如果不需要某部分工作負載將其淘汰。例子：由於遷移的應用程式使用CloudWatch，因此不再需要日誌伺服器。

保留。我們將其保留在地部署。通常，這是暫時的。例子：一個具有大量功能和定制的巨大Oracle數據庫，由於龐大的成本，決定不將其移至AWS。決定將其保留在地部署，直到在現代化階段用另一解決方案替代它。

我喜歡下面這張圖，它展示了每種遷移類型的高層次階段。作為處理遷移的捷徑表，這可能很有幫助。

遷移不宜做的事 我不推薦在進行遷移時做以下事情：

• 過快遷移。企業可能會想，「我們必須快速遷移到雲端。現在就來做提升並轉移吧！」最好不要立刻開始。你確定重新託管策略真的會比其他策略更快嗎？在一個案例中，我們嘗試遷移在地部署的虛擬機器，但因為機器上的作業系統相當老舊，這並不可行。一些作業系統級的依賴在AWS的硬體上無法工作。這需要大量的配置工作、自定義代碼和測試，而且最初的估計完全錯誤。最終，這變成了一次重新平台化。
• 評估你所擁有的，分析它，分析商業案例並思考。在這工程工作中，我們應該在行動前停下來思考。
• 沒有明確目標的遷移。你為什麼要遷移？如果你無法回答這個問題，你可能需要找到答案，或根本不遷移。我見過企業想要遷移到雲端以降低成本的情況。他們進行了提升並轉移遷移，卻沒有進行總成本分析。只有在事後，他們才意識到成本甚至比在共置中心時還要高。這次遷移可能被認為是不成功的。
• 為避免這種情況，定義清晰的目標並確定達成這些目標的目標狀態。如果成本是驅動因素，做出適當的計算並相應計劃。當你規劃目標狀態時，成本優化將是主要關注點。如果是因為可用性，測量它，定義SLO並在目標狀態中關注可用性。
• 避免黑盒遷移。不要將你遷移的工作負載視為一個黑盒。幾乎非常重要的是要清楚知道你正在遷移什麼、它有哪些技術要求、依賴關係以及其運作方式。這些資訊將使你能夠選擇正確的工作負載遷移策略。如果沒有做到這一點，很有可能會選擇錯誤的路徑，導致結果喪失。捕獲關於你系統的資訊是規劃時最重要的任務。
• 不要忘記良好架構的重要性。遷移是壓力重重的。這就是為什麼人們傾向於儘可能快速地完成它，只專注於一件事：盡快讓一切在雲端運作。他們忽略了良好架構框架的支柱。這是一個錯誤；它可能導致一系列不同嚴重程度的負面後果。不要忽視良好架構框架的支柱，否則你可能直到問題或風險已經出現時才知道。
• 不要對所有事情使用同一策略。制定一個涵蓋所有工作負載的統一計劃總是比較容易的。例如，決定進行提升並轉移，然後在雲端重新託管一切。但如果有些事情可以退役呢？如果有些組件可以輕鬆地重新平台化呢？通過分析工作負載的所有組件並為每個組件決定獨特的策略，你將節省大量資源。收集資料並適當規劃。

雲端遷移的做與不做？

做：進行雲端準備性評估。如果一個人搬家到一個新地方，他們應該考慮：

• 那裡的氣候會有所不同
• 那裡可能使用不同的語言
• 生活成本可能會有所不同，甚至更昂貴

當一家公司遷移到雲端時，他們應該問包括以下在內的問題：

• 我們考慮了所有風險嗎？
• 為了讓工作負載真正運作，需要改變什麼？
• 我們有足夠的人力資源來完成所有工作嗎？
• 我有完成一切所需的預算嗎？

雲端準備性評估是一種長格式的訪談，關於公司內不同的流程，以識別一家公司是否準備好在雲端運營。它基於雲端採用框架（CAF），使我們能夠了解為了成功遷移需要改變什麼。AWS提供了一個雲端準備性評估工具來涵蓋所有這些方面。我強烈建議你對所有考慮遷移的工作負載使用這個過程。

• 創建商業案例。描述商業案例。遷移的驅動因素是什麼？遷移解決了哪些問題？遷移應實現哪些目標？要具體：如果你打算降低成本，那麼計算出總和。如果你打算提高可用性，那麼定義一個清晰的服務等級目標（SLO）。這將是你遷移的首要推動力。所有其他的規劃都應該基於此。
• 自動化發現和數據收集。使用自動化的數據收集和分析來創建遷移組合。不要僅依賴手工製作的試算表或口頭溝通進行分析。讓機器收集關於庫存和使用統計的數據。你收集的數據越精確，結果就越好。在大多數情況下，AWS遷移評估服務將幫助你做到這一點。
• 組合管理。創建一個待遷移工作負載的組合，分析它們，為每個選擇一個遷移策略，選擇一些進行試點/第一波遷移，估計時間線並準備計劃。之後執行遷移。重複此過程，直到遷移組合為空。分享數據，讓主題專家進行審查。
• 創建雲中心卓越中心（CCoE）。這是前述雲端採用框架（CAF）的一部分。在執行遷移之前，創建一個負責制定策略並定義雲端良好生活標準的團隊：雲中心卓越中心。它應該包括具有各種主題專業知識的人員，包括管理、運營、平台、人員、財務以及在雲中消費或提供服務的每個其他部門。這些人將為遷移準備著陸區，為著陸區準備硬性政策和較軟的政策；為公司在雲中的生活做準備。不要害怕重新審視任何政策。隨著新因素的出現做出變更。
• 良好架構框架審查（WAFR）。在遷移波次期間及其之後進行良好架構框架審查（WAFR）。這將使你能夠避免愚蠢的錯誤，並從技術角度獲得你所做的高層次概覽。
• 現代化計劃。與遷移計劃一起準備現代化計劃。遷移並不是故事的結束。為了在雲中有效運作，你將需要進行良好架構審查和現代化。首次現代化很可能是巨大的；這就是為什麼提前規劃並安排預算和資源很重要。未能這樣做將導致運營成本增加，而不是減少。

摘要

如果我們想降低與遷移相關的風險，並使其壓力較小，我們就不會急於求成。你可能認為匆忙可以節省時間，其他問題稍後再解決，但經驗告訴我們這是錯誤的。最有可能的結果是，當你切換到新的基於雲的生產環境時，你將在最有壓力的情況下解決遇到的所有問題。選擇將在壓力下做出，而不是事先以深思熟慮的方式解決問題。這裡必須應用適當的工程原則。把一座橋從一條河上拿起來，然後放到另一條河上，這永遠行不通。遷移成功的關鍵是衡量、分析、設計和規劃。將工作負載遷移到雲端是困難的，但我希望這些做法和不做法能讓它變得更容易。