舊版翻新的定義
舊版翻新是一種策略性程序，透過更新或替換過時的軟體系統、架構和基礎架構，確保這些工具都能更有效配合目前和未來的業務目標。
這不只是採用新技術，而是透過徹底改造，提升基礎系統的靈活性、擴充性、安全性和成本效益。
為什麼要翻新舊版系統？
更換舊版系統或選擇翻新舊版應用程式，能為企業帶來實質的效益，遠超過單純採用新技術所能創造的價值。
提高靈活性和創新能力
翻新後的應用程式更容易更新，因此開發團隊能更快發布新功能，並迅速因應不斷變化的市場狀況。這種靈活性是重要的競爭優勢。
降低營運成本
舊版系統的維護成本通常很高，需要專業技能並搭配老舊硬體。遷移至現代化的雲端式平台，可將成本從投入成本 (CapEx) 轉為營運支出 (OpEx)，並減少管理負擔。
加強安全防護與法規遵循
舊版軟體或許有未修補的安全漏洞，且可能不符合目前的法規遵循標準。企業可以透過翻新舊版軟體，導入完善的現代化安全控管機制，並確保符合法規要求。
提升擴充性和效能
舊版應用程式常無法負荷現代流量負載。將舊版應用程式遷移至雲端後，即可運用彈性基礎架構，自動調整資源配置來滿足需求，確保使用者享有可靠的體驗。
掌握現代化技術
現代平台原生提供資料分析、機器學習和 AI 等進階服務，無需額外建構或附加，即可直接使用，能讓企業從資料中發掘舊系統無法提供的新洞察和功能。
常見問題
舊版翻新與數位轉型有何不同？
數位轉型是全面性的企業策略，著重於運用數位技術，改變組織的營運方式和為客戶創造價值的方式。舊版翻新則是數位轉型中的關鍵環節，因為這涉及更新必要的底層技術系統，以便有效支援新的業務模式和程序。
舊版應用程式的例子有哪些？
典型的舊版應用程式範例如下：1990 年代建構的大型單體客戶關係管理 (CRM) 系統，通常在地端部署大型主機上運行。這類系統可能以 COBOL 等舊語言編寫，難以更新，且缺乏連結現代銷售和行銷工具所需的網路式 API。
如何著手進行舊版翻新？
要確保舊版翻新專案順利達成目標，必須先全面評估現有應用程式的商業價值和技術健康狀態。您可以根據這項評估結果，為各個應用程式決定最合適的翻新策略，包括重新託管及替換等。
舊版翻新的主要方式
舊版系統翻新沒有一體適用的方法。合適的策略取決於特定應用程式、業務目標、預算和風險承受能力。最常見的做法通常稱為「R 翻新策略」。
重新託管 (lift-and-shift)
重新託管 (lift-and-shift)
這個程序會將應用程式從地端部署伺服器遷移至現代化基礎架構 (例如雲端虛擬機器)，並盡可能不變動應用程式架構。這是將舊版應用程式遷移至雲端最快速的方法，但通常無法充分發揮雲端原生的優勢。
更換平台
更換平台
這種策略有時稱為「lift and reshape」，是在重新託管的過程中，對應用程式進行一些小幅最佳化，以充分運用雲端功能。舉例來說，將應用程式遷移至雲端時，同時將後端資料庫移至代管資料庫服務。
重構/重新建立架構
重構/重新建立架構
這種做法需要大幅修改應用程式的程式碼和架構，才能更符合雲端原生模式，且通常需要將大型單體式應用程式拆解為多項較小的獨立微服務。
重新建構中
重新建構中
在某些情況下，現有的程式碼集不適合重構。重建是指從頭編寫應用程式，同時保留原始範圍和規格，因此能使用現代開發語言、框架和架構模式。
取代中
取代中
這項策略會完全停用舊版應用程式，並改用第三方解決方案，通常是軟體即服務 (SaaS) 應用程式。如果市面上現成的商用產品能滿足業務需求，通常會選擇這種做法。
透過容器化完成舊版翻新
容器化已成為加速舊版應用程式翻新的強大技術。將應用程式及其依附元件封裝至容器後，就能建立輕巧、可攜且一致的軟體單元。這項技術適用於多種翻新策略。對於「重新託管」或「更換平台」專案，將舊版應用程式容器化可簡化遷移程序，確保應用程式在新雲端環境穩定執行。在「重構」專案中，容器是理想的部署模型，可將原始單體應用程式拆分為新的微服務。
容器化技術可將舊版應用程式及其依附元件封裝成標準化的可攜式單元 (容器)，在任何環境都能穩定執行。這種做法能有效將應用程式與基礎舊版硬體和作業系統分離，直接連結至現代化雲端平台。
將舊版應用程式容器化後，您就能建立一致的構件，輕鬆部署至 Google Kubernetes Engine (GKE) 或 Cloud Run 等代管 Google Cloud 服務。這個初步步驟不必立即大幅變更應用程式的原始碼，因此如要將舊版應用程式遷移至雲端，這個做法的風險較低。在現代化環境執行後，應用程式就能持續改良、連結至代管雲端服務，並隨著時間逐步重構。
指南：在 Google Cloud 透過容器化完成舊版翻新
這個程序會將翻新歷程分成一系列可管理的步驟，並以容器化技術為核心。
第 1 步：評估並選擇適合翻新的項目。
首先分析舊版應用程式組合。無狀態應用程式或外部依附元件極少且容易理解的服務，通常是容器化的理想選擇。這樣可降低初始複雜度，讓團隊在過程中累積經驗並建立信心。
第 2 步：建立容器映像檔。
下一步是定義如何將應用程式封裝為容器。您可以建立簡單的文字檔案 (例如 Dockerfile)，其中包含一組操作說明。這個檔案會指定基本作業系統、將應用程式的原始碼複製到映像檔，並列出安裝所有必要執行階段、程式庫和其他依附元件所需的指令。
第 3 步：建構映像檔並儲存至 Artifact Registry。
使用該檔案建構容器映像檔。您可以在開發人員的本機電腦上完成這項作業，也可以使用 Cloud Build 等 CI/CD 服務自動執行，打造更穩健的工作流程。接著，應將產生的映像檔 (靜態可攜式檔案) 推送至安全私密的容器登錄檔，例如 Google Cloud 的 Artifact Registry，做為儲存及管理應用程式映像檔的集中平台。
第 4 步：將容器部署至代管平台。
將容器化舊版應用程式儲存在 Artifact Registry 後，即可部署至 Google Cloud 的現代化代管平台。
- 如要更精細地控管設定，或應用程式屬於較大型的系統，Google Kubernetes Engine (GKE) 是理想的部署目標
- 如要建構較簡單的無狀態網頁應用程式或 API，Cloud Run 提供全無伺服器體驗，可代您處理所有基礎架構管理作業
第 5 步：連結代管雲端服務。
應用程式在 Google Cloud 的容器執行後，即可開始逐步翻新其依附元件。您可以將應用程式設定為連至 Cloud SQL 等代管服務，而非至舊版地端部署資料庫。這項服務可減輕資料庫管理負擔，並提升可靠性。
第 6 步：監控、最佳化及反覆調整。
應用程式在雲端執行後，您可以使用 Google Cloud 作業套件 (Cloud Monitoring、Cloud Logging) 深入瞭解應用程式的效能。這項資料可協助您找出瓶頸，並規劃下一階段的翻新作業，例如將應用程式的特定部分重構為獨立的微服務，進一步提升效能和靈活性。
