雲端遷移成功關鍵因素
搬遷雲端是當今企業數位轉型的重要一步。隨著雲端技術的不斷發展和普及,越來越多的企業正在考慮將其 IT 基礎設施和應用程式遷移到雲端環境。然而,搬遷雲端並不是一個簡單的任務,需要仔細的計劃和執行。在本文中,我們將討論一些關於搬遷雲端的準則和最佳實踐,幫助企業順利地完成遷移的旅程。
1. 評估現有環境
在開始搬遷雲端之前,企業應該對其現有的 IT 環境進行評估。這包括評估 (Assess) 現有的基礎設施、應用程式和資料。企業需要了解其目前的技術堆疊 (Tech Stack) 和架構,以確定哪些工作負載適合搬移到雲端,並評估其相關好處、風險和挑戰。以下提供資源盤點範例:
服務名稱 (Name) |
技術 (Technologies) |
其他須求 (Other requirements) |
相依性 (Dependencies) |
系統資源需求 (System resources requirement) |
營運重要性 (Importance to the business) |
最大停機時間 (Maximum allowable downtime) |
遷移困難度 (Difficulty) |
Marketing website | Angular frontend | Legal department must validate content | Caching service |
5 CPU cores 8 GB of RAM |
Non-mission critical | 24 hours | Easy |
Back office |
Java backend, Angular frontend |
N/A | SQL database |
4 CPU cores 4 GB of RAM |
No downtime | Can't move | |
Ecommerce app |
Vendor X Model Y Version 1.2.0 |
Customer data must reside inside the European Union | SQL database |
10 CPU cores 32 GB of RAM |
2 minutes | Hard | |
Enterprise resource planning (ERP) |
Vendor Z, Model C, Version 7.0 |
N/A | SQL database |
10 CPU cores 32 GB of RAM |
Mission critical | ||
Stateless microservices | Java | N/A | Caching service |
4 CPU cores 8 GB of RAM |
|||
SQL database | PostgreSQL | Customer data must reside inside the European Union | Backup and archive system |
30 CPU cores 512 GB of RAM |
|||
Source code repositories | Git | N/A | Backup and archive system | ||||
Firewall |
Vendor H Model V |
N/A | N/A | N/A | |||
NAS Appliance |
NFS iSCSI |
N/A | N/A | N/A |
當然,也可以透過一些工具加速完成收集資源清單,以 AWS 為例, AWS Application Discovery Service 可收集地端 (on-premises) 佈建的資訊,其會收集供來自伺服器的組態、用量和行為資料,還可透過安裝 Discovery Agent 以將網路視覺化,協助企業更快速了解工作負載;以 Azure 為例,Azure Migrate 除可探索 VMware 環境、實體伺服器、SAP 系統及 Spring Boot 應用程式之外,還可支援收集 AWS / GCP 環境中的執行個體;以 GCP 為例,Asset Discovery 提供手動導入、自動一次性及自動持續性收集三種方式,可依需求收集伺服器組態、硬體設備、網路 IP 範圍等相關數據。
2. 制定遷移策略
搬遷雲端的成功關鍵之一是制定適合的遷移策略。根據企業的需求和目標,以確定遷移到雲端的動機和目的,進而採取不同的遷移策略,例如 「重新託管」、「重新架構」 或 「重新優化平台」。企業需要明確了解遷移的目標,例如成本節省、效能改善或可擴展性等,以制定適合的策略。常見遷移動機與目的如下:
重大商業事件 |
資料中心的退場 合併、收購或分割 減少資本支出 終止對任務關鍵性技術的支援 對法規遵循變更的回應 新的資料主權需求 減少中斷情形和 IT 穩定性的改進 管理企業對環境的影響 |
當回應"重要商務事件"是最高優先順序時,請務必提早開始準備移轉規劃,通常策略與規劃作業會同時進行。採用這種方法需要成長思維和有願意反復學習來改善流程。 |
遷移 |
節省成本 降低廠商或技術上的複雜性 追求內部營運的最佳化 提升業務靈活性 為了準備新技術能力 根據市場需求進行調整 根據地理需求進行調整 複雜的 IT 整合 |
當"遷移"是最高優先順序時,策略和規劃在初期扮演著重要的角色。建議您在規劃第一個工作負載時,須同時協助團隊瞭解並預測採用雲端相關的學習曲線。 |
創新 |
為了準備新技術能力 打造新技術能力 根據市場需求進行調整 根據地理需求進行調整 改善客戶體驗和參與 產品或服務的轉型 新產品或服務的市場擾亂 民主化和/或自助環境 |
當"創新"成為最高優先順序時,策略和規劃在初期需要更多的投入。這可確保投入組合的平衡及採用雲端過程中調整。 |
同時,在遷移策略中,還須考量應用程式 (或服務) 的使用者其成本與效益,須清晰地展示遷移到雲端的價值和好處,並向決策者進行推銷和溝通。七種常見遷移策略如下:
(1) 重新託管,無痛轉移 (Rehost ; lift and shift):將應用程式 (或服務) 直接遷移至雲端 IaaS 服務中。例如:將地端 Oracle 資料庫直接佈建於 VM 執行個體 (Instances) 上。這也是我們常聽到的自建服務在雲端虛擬機上,這種遷移方式需要的時間最短,所須修改調整的幅度最小或 不進行修改。然,並非所有情境都適用,對於當軟體生命周期即將結束 (EOL / EOS) 或 某些雲平台不支援特定的基礎設施需求,例如:Solaris 或 大型主機的工作負載。
(2) 重新佈建 (虛擬層級),無痛轉移 (Relocate ; Hypervisor-level lift and shift):無須購買新硬體、重新撰寫應用程式 (或服務) 或修改現有操作,直接將基礎設施遷移至雲端。例如:VMWare 環境遷移至雲端。企業可將基礎設施遷移至 VMware Cloud on AWS 時,使用地端部署資料中心的 VMware Cloud Foundation 技術,將 Oracle 資料庫佈建於 VMware Cloud on AWS。
(3) 重新架構,遷移並替換 (Refactor / Re-architect ;Rip and replace):充分運用雲端原生功能來遷移應用程式 (或服務) 並修改其架構,以提高敏捷性、效能和可擴展性。通常涉及移植作業系統和資料庫。例如:將Oracle 資料庫佈建於雲端 PostgreSQL 相容版本。這種遷移方式,須投入較多的工作和資源,可能須對應用程式 (或服務) 完全地改寫或重新設計。如果企業想重新改寫成雲端原生 (Cloud-native) 的形式,那這種「遷移並替換」的方法也是種選擇。
(4) 重新優化平台 (Replatform ; lift and reshape):將應用程式遷移到雲端,並運用雲端功能引入一定程度的優化。例如:將企業的地端 SQL 資料庫遷移到雲端中的 Relational Database Service (RDS)。這種遷移方式,除了須將工作負載遷移到雲端平台上,還須運用雲端原生功能進行優化,可提升效能、功能、管理成本和用戶體驗。然,須留意,應用程式 (或服務) 可能需要進行微小修改,須克服雲端原生服務的限制,例如雲端平台具有不同的底層程式碼 (codebase),這將需要多次的測試以確保正常運行。
(5) 重新購買,捨棄再購買 (Repurchase ; drop and shop):切換至不同的產品以解決需求。通常係指從傳統授權切換至雲端 SaaS 模式。例如:將企業協作軟體遷移至 Google Workspace;將客戶資料平台 (CDP) 遷移到阿里雲神測 (Sensors);將電子郵件行銷系統遷移到 Twilio Sendgrid。現,各雲端平台的市集 (Marketplace) 含有數以千計的軟體清單,包含特定產業 (例如醫療保健、金融服務和電信等安全性、商業應用程式、機器學習和資料產品) 的熱門服務。從資源的角度來看,重新購買遷移可能比上述的方式容易得多,能夠加速企業啟用應用程式 (或服務) 且相較地端環境更加簡化採購流程。然,重新購買遷移的費用可能較高,並且企業可能無法獲得特定功能的控制權。
(6) 保留,待重新審視 (Retain ; Revisit):將應用程式 (或服務) 保留在原始環境中。這可能是暫時先保留在原始環境中,未來再重新架構的重要應用程式/服務,也可能是企業評估後認為並無業務必要性,想要保留舊版應用程式而選擇保留在原始環境。
(7) 淘汰 Retire:移除原始環境中不再需要的應用程式 (或服務)。
3. 選擇單一或混合雲端平台
在制定遷移策略之後,企業需要選擇適合的雲端平台。市場上有許多雲端提供商,例如 AWS、Azure、Google Cloud、Alibaba Cloud等,每個平台都有其獨特的功能和優勢。企業應該根據其需求和目標,將應用程式 (或服務) 選擇佈署於適合的雲端提供商,並評估其功能、效能、價格和安全性等因素。以成本考量,還須評估包括遷移期間新舊環境過渡期的費用、建置費用、執行費用以及技術運維人員學習成本;以價值考量,須評估包括管理成本節省、效率提高、創新能力以及可擴展性等方面的好處。
4. 架構規劃並準備基礎設施
在選擇雲端平台之後,企業應該妥善規劃環境架構並準備好雲端基礎設施。這包括設置雲端帳戶、應用服務 (或服務) 架構規劃、網絡和安全設置等。企業需要確保雲端基礎設施能夠滿足其需求和目標,並且能夠支持其工作負載的遷移和運行。
5. 遷移工作負載
一旦基礎設施準備就緒,企業就可以開始遷移其工作負載到雲端環境。這可能涉及使用不同的工具和服務,例如伺服器遷移服務、資料庫遷移服務等。企業應該確保遷移過程的順利進行,並密切關注效能和可用性等方面的問題。以 AWS 為例,可透過 AWS Server Migration Service、AWS Database Migration Service;以 Azure 為例,可透過 Azure Migration and modernization tool;以 GCP 為例,可透過 Google Cloud Migrate、Data Transfer Service 加速遷移。
6. 測試和驗證
完成遷移後,企業應該進行測試和驗證,以確保其工作負載在雲端環境中運行正常。這包括功能測試、效能測試、安全性測試等。企業應該確保其工作負載能夠滿足其需求和目標,並且能夠在雲端環境中穩定運行。
7. 優化和管理
最後,企業應該持續優化和管理其雲端環境。這包括監控和管理資源、效能優化、成本控制等。企業應該利用雲端平台提供的管理工具和服務,以確保其雲端環境能夠達到最佳性能和成本效益。以 AWS 為例,可透過 Trusted Advisor;以 Azure 為例,可透過 Azure Advisor;以 GCP 為例,可透過 Active Assist;以阿里雲為例,可透過 智能顧問 Advisor 為雲端資源、應用程式架構,以及業務表現和安全性提供全面網上檢查,並提供最佳化建議。
結論
以上提到的搬遷準則,雖然都能在網路上找到相關介紹文件,但當中都有一些須特別留意的技術細節。企業若沒有釐清技術、業務需求和預算控管的情況下,便盲目建置雲端環境,將可能產生資安問題或相容性不佳導致資源運用效率降低。為了打造安全、可靠且不燒錢的雲端環境,企業前期須有完善的評估環境與遷移策略規劃,先對標雲端基礎設施與搬遷目標,進而設計雲端框架。雖然遷移專案初始成本可能很高,但在整體投入工作之前就先找到問題並解決,會節省很多迭代修復安全漏洞和被迫停機的時間。
果核擁有豐富的經驗,協助企業客戶上雲,提供諮詢、評估、執行、優化等完整的服務,將搬遷過程中的風險降到最低,提高整體營運靈活度、減少技術負債,並最大化搬遷上雲的優點。
別再猶疑了,現在就找果核專業團隊協助您開啟雲端搬移的第一步吧!請填寫表單聯繫我們。
本文初稿為使用chatgpt 編撰綱要,並參考下列來源進而彙整編寫:
https://aws.amazon.com/tw/cloud-migration/how-to-migrate
https://cloud.google.com/architecture/migration-to-gcp-getting-started
https://learn.microsoft.com/en-us/azure/migrate/how-to-build-a-business-case