在這個數位化加速的時代，越來越多企業選擇將地端虛擬機器搬遷至 GCP。這不僅能提升效率，還能優化成本。本文將深入探討搬遷的類型、方法和步驟，協助各位了解主機搬遷的相關事項。
一、前言：為何要將主機搬遷上 GCP？
其實將主機搬遷上雲的理由和好處很多，這裡提供三個最重要的理由如下：
(一) 降低成本
GCP 是每月依使用量計費，每月付款，企業可以從一次性大額採購的「資本支出」，轉變成每月的「費用支出」，減低現金流的壓力。
此外，實體機要考慮機房、水電相關設備的建置和維護成本，在管理上也是耗費不少心力。而公司採用雲端，等於就是把基礎建設外包給專業的 Google，你可以省下許多寶貴的時間，然後專注在開發公司產品或提供服務，為公司創造更大的價值。
(二) 彈性擴充
在地端，你的機器數量是固定的，如果碰到活動期間，需要緊急擴充機器，往往要走採購流程包含詢價、議價、選商，以及後續的安裝建置，等到機器準備好了，活動都結束了。
而在雲端上有所謂的自動擴充 (Autoscale)，你可以在 GCP 主控台上設定擴充的功能，指定要擴充的數量，接著 GCP 會依照當前主機的負載，如果主機太過於忙碌，GCP 會立即增加主機來對外服務。當活動結束，人潮退去時，機器也能自動縮減，不會讓它閒置導致額外的花費。
(三) 創新整合
和其他公有雲相比，Google 的強項就是大數據分析與人工智慧。如果你的系統在 GCP 上運作，可以輕易導出資料到 BigQuery 來分析，發現洞察。你也可以將資料用來訓練模型，開發 AI 應用程式。不需要尋找外部工具，從頭到尾都在 GCP 做完。
當你開發完成，也可以直接在 GCP 上部署 AI 應用，或是做為 API 讓外部來呼叫，這些都是 GCP 內建的功能，讓你從收集資料、開發模型、測試模型到部署 AI 應用，都可以透過 GCP 來達成。
從商業的角度來看，就是加速你回應市場的速度，當市場上有新的技術或是新的商機出現，你就可以快速的在 GCP 取得各種創新資源，讓你可以快速的開發出應用程式，提供給廣大的使用者。
以上只列出常見的上雲理由，如果你想知道更多，可以參考《企業上雲的10大理由、15個評估面向與6大好處》和《上雲比較貴？雲端和地端的成本詳細比較》這兩篇文章。
二、主機搬遷類型
將主機搬遷上雲有很多方法，我們可以依照系統的狀況 (例如好不好搬遷)，和公司的時間表 (有沒有急迫性或是足夠的人力) 來選擇適合的搬遷類型，這裡分別介紹如下：
(一) 更換主機 (Rehost)：照原來樣子搬遷 (Lift And Shift)
這種搬遷方式就像是單純的搬家，把所有東西從舊環境搬到新環境，期間只做最少必要的調整。就像是把傢俱從舊房子搬到新房子，只需要因應新房子的格局做一些微調而已。
當你的系統可以直接在新環境運作，或是當業務上沒有需要對系統做太多更改，又或者當你需要快速完成搬遷時，這種方式就特別適合。
這種方式的優勢在於執行起來最簡單，團隊可以繼續使用熟悉的工具和技能，而且支援現成的軟體，最重要的是搬遷速度最快。但這種方式也有其侷限性，系統無法充分發揮雲端環境的優勢，也無法善用 GCP 的特殊功能，包括自動擴充的能力、更靈活的計費方式。這就像是把老房子整棟搬到新地點，雖然可以快速入住，但無法享受新社區提供的現代化設施。
不過企業會因為各種因素，不得不採用這種方式，例如程式碼太老舊或複雜而不容易修改，或是重新編譯程式很困難，又或者必須持續維持系統運作而沒辦法停機重做。
(二) 更換平台 (Replatform)：重新優化 (Lift And Optimize)
想像一下，這不只是單純的搬家，而是搬家時順便整修。就像是搬到新房子時，不只是搬運傢俱，還會順便更換一些老舊的設備，或是重新規劃空間跟裝潢，讓新家更好用。
把主機內的系統搬到 GCP 上，讓它能用上更新、更有效率的工具和服務。這種搬遷方式最適合那些希望充分運用雲端核心功能的組織，包括彈性運算能力、系統備援、提升效能和加強安全性等優勢。舉例來說，你可以將應用程式轉移到 GCP，以便使用 Google Kubernetes Engine 提供的微服務架構或容器服務。這樣一來，系統在雲端運行時就能發揮更好的效能和效率。
不過呢，這種搬家方式當然會比單純搬家麻煩許多。因為新環境的設備和系統都不太一樣，所以需要多花時間測試、調整，確保所有東西都能完美運作。就像是要學習使用新家裡的各種 AI 電器，需要一段適應期一樣。
(三) 重構 (Refactor)：徹底改造升級 (Move And Improve)
重構這種搬遷方式就像是趁搬家時，不只是簡單改裝，而是徹底翻新改造，讓系統能充分運用雲端的各種優點，已經不是針對「主機」來搬遷了。你可以針對效能、功能、成本和使用體驗，把每個部分都改造得更好。
這個改造工程可以選擇在搬到雲端時一起進行，也可以提前先做好。就像是裝修房子，如果你是第一次做大規模裝修，可能會想等搬家時再一起處理。但如果你有經驗，就能提前規劃好需要改造的部分，讓系統更好地運用雲端的功能。
有時候你會被迫選擇重構，因為舊系統的架構可能無法直接在新環境中運作。又或者是趁這個機會，你想要對系統做一次大規模的更新和改進。重構的好處是你的系統可以充分運用雲端平台的特色，例如自動擴充 (Autoscale) 的功能，或是提高系統的穩定性。你還可以讓系統變得更容易在不同平台間轉移。
不過呢，重構需要花比較多時間，畢竟要把整個系統重新改造一番。而且你的團隊可能需要學習新的技術和工具，就像是要學習使用全新的裝修工具和材料一樣。
(四) 重新設計架構 (Re-architect)：全面改頭換面 (Continue To Modernize)
這種搬遷方式和前面說的重構有點像，但更加徹底。它不只是改變系統程式碼的運作方式，而是完全重新設計整個系統的運作模式。這就像是不只是翻修房子，而是把整棟房子拆掉重建，讓它能充分運用新環境的優點，像是更好的擴充性、安全性和靈活度。
最經典的例子就是從單體式架構（Monolithic）轉換成微服務（Microservices）架構。單體式架構就像是一間大型百貨公司，所有部門（功能）都在同一棟大樓裡，所有服務都綁在一起，任何一個小改動都要動到整個系統。並且擴充時必須整個系統一起擴充，如果有一個地方出問題可能影響整個系統。
而當我們改成微服務架構後，就像是把大百貨拆分成許多專賣店，每個服務都是獨立的小系統，可以個別更新和維護，當需要擴充時，可以只擴充需要的服務。某個服務出問題時不會影響其他服務，不同的服務可以使用最適合的技術，不一定都要使用虛擬機器，有的可以用 Cloud Run，有的可以用 GKE。
不過要注意的是，這種全面改造比一般的重構更複雜，需要投入更多時間和心力。而且在重建的過程中，可能會不小心引入一些程式錯誤或安全漏洞。因此，需要進行多次測試，確保新系統的每個部分都能完美運作，就像是新蓋好的房子需要仔細檢查每個管線和設備是否安全可靠。
(五) 重建 (Rebuild)：完全推倒重來 (Remove and Replace or Rip and Replace)
重建就是重寫，就是先把現有的系統停用，然後重新設計並開發一個完全針對雲端優化的全新系統。
什麼時候會選擇重建呢？通常是在這些情況：
- 當你覺得舊系統已經不值得繼續維護
- 當其他改造方式的成本太高
- 當舊系統根本無法在 GCP 上運作
重建的好處是，新系統可以完全發揮 GCP 的優點，像是自動擴充、完整的雲端服務支援，以及超高的系統穩定性。而且因為是從頭開始，你不用被舊系統的技術包袱拖累。就像蓋新房子可以使用最新的建材和設計，不用被舊房子的格局限制。
但是呢，重建需要最多的時間，比其他方式都久。而且因為要重寫整個系統，所以不適合用在現成的軟體上。你需要把重新設計和重寫的時間都算進整個專案的生命週期裡。
另外，你的團隊可能需要學習全新的技術和工具，因為要用新的工具來設定環境並部署系統。這就像是要學習使用全新的建築工法和工具來蓋房子一樣。
(六) 重新購買 (Repurchase)
這種方式最簡單，就像是不想修理舊電器，直接去買新的雲端服務來用，其實就是不搬遷了，直接買新的來用。
舉例來說，與其維護公司自己的郵件系統和檔案系統，不如直接改用 Google Workspace (就是 Google 的企業版 Gmail、雲端硬碟等服務)。從資源投入的角度來看，這種方式比重構、重建或重新設計架構簡單多了。就像是比起修理老舊的冰箱，直接去買一台新的智慧冰箱來用比較不費心。
不過要注意的是：
- 這種方式的花費可能比較高，因為要持續付費使用服務
- 你可能無法完全掌控系統，因為是用人家現成的服務，就像是租用別人的設備，雖然方便，但無法像自己的設備那樣隨意改造和調整，自由度比較低。而且有可能會被綁住，沒有辦法輕易更換系統，或是匯出資料。
綜上所述，我們可以把各種搬遷類型整理如下：
資料來源：東東老師自行整理
如果想完整了解搬遷類型，可以參考這份文件。
三、主機搬遷步驟
根據 GCP 官方部落格提到，搬遷的步驟如下圖：
資料來源：GCP 官方部落格
(一) 盤點 (Assess)
在進行搬遷之前，請評估您的應用程式以及它們對 GCP 的適合程度。需要考慮的事項包括 (但不限於) 硬體和效能需求、使用者、授權、合規性需求和應用程式相依性。
一般來說，應用程式大概分種三種：很好搬、很難搬和不能搬。通常建議先選最好搬的，或是測試中的系統，或是較不重要的應用程式，因為搬遷中碰到問題，畢竟不是核心系統，對公司影響較小。
(二) 測試 (Pilot)
這步驟主要是讓你在搬遷過程中熟悉整個操作流程和 GCP 的搬遷介面，對於複雜的系統也可以測試，尤其是有授權議題的主機，如果搬遷有問題也可以試著回溯 (Roll Back)，確保到時候正式搬遷會有一個 (Plan B) 備用計畫。
(三) 搬遷資料
根據Google官方的說法，建議先搬遷資料到 GCP，再搬遷應用程式，因為你的應用程式要能正常運作，必須要先存取到資料，否則應用程式即使搬上去，因為它撈不到後端的資料，還是會出問題。
在下一段會先分享搬遷主機的方法，你可以先試著搬遷不需要連接外部資料庫的主機，確認都沒問題的話，再搬遷資料庫，最後再搬遷應用程式。
(四) 搬遷應用程式
正式搬遷的時候，盡量保持用最簡單的流程和方法，並且執行最少的操作。
(五) 優化
在搬遷完成之後，你可以考慮讓你的系統運作的更好。例如增加可用性 (HA)，或是使用自動擴充 (Autoscale) 以及使用監控程式 (OPs Agent)，或是把靜態資料放在 Cloud Storage。
而在實務上，我們通常不會等到搬遷完成才開始優化，而是在搬遷之前，就會依照應用程式的特性，來判斷他適合在什麼樣的 GCP 服務上面運作。前面規劃的越多，後面花在調整的時間越少。
如果想完整了解搬遷步驟，可以參考這份文件。
文章轉載自《東東GCP 教學》網站
