搬遷至Google Cloud Platform（GCP）：準備工作

這份文件將協助您規劃、制定，與執行搬遷至Google Cloud Platform（GCP）的步驟。就算是經驗豐富的團隊，應用程式移轉至另一處作業環境也並非容易的事，因此您需要謹慎地規劃並執行搬遷程序。

無論您打算自本地部署、私人代管環境、還是由其他雲端供應商搬遷至GCP；或者您只是想評估搬遷的可能性、瞭解搬遷後情況，這份文件都會對您有所幫助。

【雲端小教室 Ep.17】上雲前的準備工作｜5分鐘了解如何定義工作負載與作業環境

揚帆啟程

規劃GCP搬遷的第一步就是定義需要搬遷的作業環境。您的起點可能是本地部署環境、私人代管環境、或是其他公有雲端環境。

本地部署或稱自建機房環境，意味著完整的所有權與責任。您保留環境中每個層面的掌控權，例如冷卻設施、實體安全與硬體維護。

在主機代管環境中，您將部分硬體設施、與其管理責任外包給廠商。通常會有不同顧客共同使用該廠商的電力、網路纜線等基礎設施。在私人代管環境中，您無需管理硬體設備或實體安全。

也有些代管環境會讓您管理部分硬體，例如伺服器、機架、或網路設備；而電源與網路纜線一般會包含在廠商服務範圍內，不需由您管理。而在該實體伺服器上的硬體資源、虛擬化出來的虛擬機器、以及在該機器上運行的程式或服務，這些全部由您掌控。

公用雲的優勢在於您不需要自己管理整套資源堆棧，僅需關注對您最有價值的部分。如同在私人代管環境，您不用管理硬體設施更不需管理虛擬化。您可以在這樣的環境上直接打造虛擬架構；也可以購買完整託管服務，只需要考量工作負載，把維護執行期的操作重擔全部交給別人操心。

這份文件由下列幾項層面評估不同環境，以及哪一方該提供、管理相關服務：

此文件中，您的搬遷起點可以是本地部署環境、主機託管設施、私人代管環境，或是公用雲，目標環境則為GCP。

當您定義完想要搬遷的起點與目標環境之後，接著要定義的是想要搬遷的工作負載類型，以及相關的運作程序。此文件將討論兩種工作負載：既有(Legacy)與雲原生(cloud-native)。

既有工作負載與維運，其開發並未考量任何雲端環境。這類工作負載因欠缺擴展性的支援，導致難以修改、維護成本也高。

雲原生的工作負載與維運原本就具有可擴展、可轉移、可用性高且具有一定程度的安全性，這類工作負載能夠幫助開發者提高生產力與開發速度，因為他們不需耗費心力去維運開發與執行環境，而能專心顧好正式環境的工作負載。

此外GCP在安全方面有共同責任模式，換言之GCP會與您共同擔起雲端安全的責任。

簡而言之，您的搬遷起點會是下列其中之一：

• 本地部署或私人代管環境，搭配既有的工作負載與維運。
• 本地部署或私人代管環境，搭配雲原生的工作負載與維運操作。
• 公用雲或私人代管服務，搭配既有的工作負載與維運。
• 公用雲或私人代管服務，搭配雲原生的工作負載與維運。

根據上述起點，搬遷過程會有所不同。

若要從既有的本地部署環境或私人代管環境，將工作負載搬遷至公有雲之類的雲原生環境，可能相當具有挑戰性，也有其風險在；所謂成功的搬遷，在過程中應盡可能不更動到想要搬遷的工作負載，應用程式由既有本地部署環境搬遷至雲端，通常需要多個搬遷步驟。

搬遷類型

搬遷主要分為三種類型：

1. 直接移轉 (Lift and Shift)
2. 優化並移轉 (Improve and Move)
3. 重整並取代 (Rip and replace)

下列段落中將會定義這三種搬遷類型，並舉例說明採用各種類型的時機。

一、直接移轉 (Lift and Shift)

在直接移轉的情況下，工作負載會由來源環境移動至目標環境，期間幾乎沒有經過修改或重構；若有修正也只是為了讓工作負載於目標環境中運行，所做之最小幅度的修改。

直接移轉的理想狀態是——工作負載在目標環境能與來源環境運作時相同。而為了達成此狀態，可能需進行少量更動或不需調整。此類型搬遷所需時間最少，因為重新構建、調整的幅度會盡可能達到最小。

有時是技術問題導致您必須進行直接移轉——若您無法將工作負載重構、或除役某個工作負載，就必須採用此類型的搬遷。舉例來說，工作負載的原始程式碼非常困難、幾乎不可能更改；或者程式編譯程序不夠直接，導致程式碼碼重構之後很難有新產出。

直接移轉在執行上最簡單，因為沒有新專業知識的需求，您的團隊可以沿用現有的工具和技能，而這種搬遷也支援架上軟體。由於現有的工作負載僅需最小程度的重構，比起其他兩種類型的搬遷，直接移轉往往最為快速。

不過直接移轉後，運行於目標環境中的搬遷結果不是雲原生的工作負載，這些工作負載無法完全善用雲端平台的功能，例如水平式的可擴展性、劃分精細的收費，以及管理完善的各種服務。

二、優化並移轉 (Improve and Move)

優化並移轉指的是在搬遷過程中使工作負載現代化，此種類型的搬遷會對工作負載進行調整，以取得雲原生完整的優勢，而不單只是讓工作負載換個新環境運行。您可以改善各工作負載的性能表現、功能、成本，或是使用者體驗。

倘若某應用程式現有的架構或基礎設施無法適用於目標環境，就必須進行一定程度的重構來克服這些限制。

另一個選擇優化後移轉的原因是，除了搬遷所需的更新之外，工作負載本身也要進行重大更新。

優化後移轉使您的應用程式能夠完整運用雲端平台的優勢，例如可擴展性與高可用性；您也可以事先規劃，以增加該應用的可攜性。

另一方面，由於應用程式得先進行重構才能搬遷，優化後移轉所花費的時間比起直接移轉來得長，在考量應用程式的生命週期時，您需要評估這些額外的時間與心力。

此外優化後移轉，會需要學習新的專業技能。

三、重整並取代 (Rip and replace)

在重整並取代的搬遷情況下，您除役某個現有的應用程式，接著重新設計、重新編寫為雲原生的應用程式。

倘若現有應用無法滿足您的目標，就可以採用重整並取代的搬遷。例如當您不想繼續保留該應用程式、採用上述類型的搬遷方法成本太高，或者GCP無法予以支援。

重整並取代的搬遷讓您的應用程式能夠完整運用GCP優勢，如水平可擴展性、管理完善的服務，以及高度可用性。因為是從頭開始編寫應用程式，您同時也免除了舊有版本的技術負債(Technical Debt )。

然而重整並取代的搬遷比起直接移轉、優化並移轉所花費的時間都更長。而且這類型的移轉不適用於架上應用，因為您必須重新改寫。考量應用程式的生命週期時，您必須評估重新設計、重新編寫的額外時間與心力。

重整並取代的搬遷同樣也需要新技能，您必須運用新的工具鏈來開發、配置欲部署應用程式的新環境。

Google Cloud 採用框架

著手搬遷之前，您應該先評估公司在採用雲端科技上的成熟度，Google Cloud 採用框架像是張地圖，能協助定位貴公司的商業資訊技術，也能引導您看見欲達成的目標。

您可以運用這份架構來評估貴公司對於採用 GCP 的準備有多少，還有哪些地方需要補強、拓展新的競爭優勢。如以下圖表所示：

此架構將四個面向納入考量：

1. 學習 (Learn) 學習計畫的品質與規模
2. 領導 (Lead) 領導階層有多支持您的IT部門、給予何種程度的授權來搬遷至GCP
3. 規模 (Scale) 您所使用的雲原生服務的規模大小，以及現有的自動化操作
4. 安全 (Secure) 保護現有環境免於未授權與不適當使用的能力

根據此架構，您在這些面向上應處於下列三種階段的其中之一：

• 專門性 (Tactical) 尚未有完整的計劃能夠涵蓋您目前所有的工作負載，您主要關注投資的快速回收，不想輕易打亂IT團隊的步調。
• 策略性 (Strategic) 考量到未來擴展需求，已經有一個發展個別工作負載的計畫。您感興趣的是中期目標，希望能精簡化操作流程，變得比現在更有效率。
• 轉型中 (Transformational) 雲端運作流暢，且您使用那些數據來改善您的IT事務。您在乎的是長期目標，欲使IT部門成為推動組織進行創新的引擎之一。

在評估四面向、三階段之後，您會得到雲端成熟度的指標。在各面向中，您會看到在需要的時候才用新技術，進化到更具策略性的運用會產生什麼改變——通常這意味著更深層、更全面、更有一致性的團隊訓練。

全文共有六大重點，將陸續與大家分享，若想立即獲得完整中譯版白皮書，進一步了解搬遷旅程的四個階段、每個階段需注意的規劃以及更多資源，請填寫文末表單。