搬遷至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 的準備有多少,還有哪些地方需要補強、拓展新的競爭優勢。如以下圖表所示:

採用GCP前,可透過此架構圖了解公司現況,可分成四個面向:學習(Learn)、領導(Lead)、規模(Scale)與安全(Secure);以及三個階段:專門性(Tactical)、策略性(Strategic)與轉型中(Transformational)。 圖片來源:Google Cloud
icon/enlarge

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

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

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

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

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

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

即刻下載

《搬遷至Google Cloud Platform(GCP):準備工作》完整中譯版白皮書

訂閱 CloudMile 電子報

所有 CloudMile 最新消息、產品動態、活動資訊和特別優惠,立即掌握。