高層策略
一旦組織確定已準備好遷移到雲端，就需要做出許多針對具體情況的決策。 擁有一個一般的指導策略至關重要。
列出您的目標和希望透過雲端遷移策略解決的問題有助於確保您的業務和技術策略保持一致。 你希望實現什麼？
- 您是否嘗試降低成本或改善上市時間？
- 您是否在努力吸引和留住熟練的員工？
- 您是否試圖提高產品或服務的質量？
- 這些目標是緊急還是長期？
- 遷移到雲端時您是否有需要滿足的合規性要求？
這些因素對於確定您的雲端遷移策略至關重要。
供應商選擇
對於具有一組同質工作負載要求的相對較小的組織，單一供應商雲端策略可能是最合適的，因為幾乎不需要投資於多個雲端供應商來實現技術冗餘或避免供應商鎖定。
規模大得多的組織，例如具有不同工作負載和不同級別技術要求的全球銀行，更有可能追求多雲端策略，因為這將使每個專案團隊能夠靈活地選擇最適合其要求的供應商。 此外，較大的組織更有可能需要滿足內部和外部合規性要求，而這些要求可能需要能夠在相對較短的時間內在雲端供應商之間移動工作負載。
對於大中型企業來說，涉及傳統資料中心和雲端供應商的混合策略也可能有意義，特別是如果向雲端的過渡將持續數年。 如果您了解更多有關企業中雲端技術實施的信息，並且需要更動態地改進雲端遷移策略，則該策略也可能適用。
六個 R
在確定雲端遷移目標和供應商策略後，下一步就是決定如何將工作負載遷移到雲端。
首先，您需要對現有應用程式進行審核。 這可以讓您了解遷移到雲端所需的工作等級和性質。 在此審核期間，您可以根據您希望負責應用程式的團隊在雲端遷移中採用的方法對應用程式進行分類。 AWS 概述了六種「常見遷移策略」。 這些可以全面應用，也可以根據組織的規模和涉及的複雜性，每個團隊都可以選擇最適合當時的特定設置的策略。
1.重新主持
第一個也是最簡單的策略是重新託管您的應用程式（也稱為「直接遷移」）。 它涉及將它們從資料中心中運行的實體伺服器轉移到雲端中運行的虛擬伺服器。 通常，這不需要代碼更改，而且對流程和周圍技術（例如網絡）的變更相對較少。 它還可以幫助您的組織培養其他雲端原生實踐所需的雲端技能和經驗。
二.重新平台
這種方法也稱為“提升、修補和轉移”，類似於重新託管，但更進一步，在應用程式層級整合了許多基本雲端服務。 例如，AWS IAM（身分和存取管理）可能會整合到您的應用程式中，以取代或補充更傳統的以資料中心為導向的 IAM 系統。
三.回購
這種方法也稱為“直接購買”，涉及用許可的基於雲端的服務替換現有的本地應用程式。 這可能涉及更改您的企業使用的授權模式、降低維護成本，並可能提供更快、更輕鬆的升級路徑。
4.重建/重建設計
一種更雲端原生的方法是採用現有的程式碼庫並修改或擴展它們以在更現代的雲端服務中工作。 一個範例是將應用程式程式碼容器化、運行配置，並在基於雲端的 Kubernetes 服務（例如 Amazon 的EKS或 Azure 的AKS）中執行它們。 這可能涉及對現有程式碼庫進行大量重寫，以使其能夠正常運作並提高可擴展性；為了使用真正的雲端原生工具（例如，AWS Lambda 或 Azure Functions 等無伺服器工具），甚至可能需要完全重寫。
5.退休
使用最後兩種「被動」策略，工作負載根本不會遷移到雲端。 您的工作負載稽核可能會發現冗餘或不再值得維護的系統。 這些應用程式可以退役。
六.保留
最後的「被動」策略是保留，涉及保持應用程式運作並選擇在可預見的未來不將其遷移到雲端。 將應用程式保留在雲端之外的可能原因有很多，包括：
- 對應用程式運行位置的監管限製或對安全性的高內部合規性要求
- Mission-criticality of software that can make planning a move to cloud technologies earlier in the migration cycle too risky and uncertain
- 沒有因行動應用程式而造成中斷的業務案例
- 雲端環境不支援舊系統
從哪裡開始
除了確定整體策略並對每個工作負載的戰術方法進行分類之外，您還需要製定一個計劃，如何建立雲端基礎設施以支援工作負載的移動。 一種方法是讓每個團隊選擇如何在雲端中建立自己的系統。 然而，這種方法有幾個缺點，因為團隊可能會重複實施的反模式並重複彼此的錯誤或違反內部/外部合規性規則。
另一種方法是創建一種集中的「卓越中心」或雲端基礎設施團隊。 這個團隊可以選擇設定其他團隊可以在其中執行其工作負載的核心系統。
在建立這些護欄時，有一些設計元素應該優先於其他設計元素。
帳戶
雲端架構最基本的單元是雲端帳戶。 在整個組織中使用一個帳戶幾乎總是無法擴展，因為您最終會遇到帳戶限制。 因此，確定帳戶界限很重要。 該帳戶是否用來代表特定業務單位、個別團隊或軟體服務群組？ 這將如何與您的財務部門運作？ 誰應收到賬單？ 因為成本可能會迅速增加，因此請儘早找出這一點很重要。
現在
下一個最基本的架構單位是身分和訪問管理系統。 隨著雲端基礎架構的發展，您將需要考慮使用者存取各種雲端服務和資料的安全性影響，而且越早越好。 對已經執行中的系統再次施加這些規則可能很複雜。
網絡
遷移到雲端涉及現有網路的虛擬化或完全重新設計。 VPC (AWS) 或 VNet (Azure) 服務可讓您設定隔離網路以在您的帳戶中執行一組單獨的服務。 需要仔細考慮組織的服務和基本網路資源（例如 IP 位址）之間的互聯網通訊。
資料移轉
雖然將運算服務遷移到雲端很容易，但遷移資料可能更具挑戰性。 主要資料儲存區可能是大型複雜的基礎架構，需要仔細規劃才能移動。 這需要足夠深入地了解如何將資料移至雲端，同時符合組織的效能、合規性和可操作性標準。
結論
一旦您明確了高階雲端策略，制定成功的雲端遷移策略就需要對業務的各個方面進行細緻的規劃和考慮。 下一步是為您選擇正確的雲端供應商策略，無論是簡單的單一供應商遷移、多雲端供應商方法或混合策略。 最後，您需要在開始載入應用程式之前先考慮關鍵基礎架構元件來建立雲端遷移。
我希望這篇博客文章很有趣和有價值。
請留意即將發佈的有關容器/Kubernetes 和無伺服器服務的部落格文章。
如果您正在開始雲端之旅，也許您想閱讀我關於安全雲端遷移的五個最佳實踐的新白皮書。
您可以在此處閱讀有關 Check Point 雲端資安解決方案的更多信息，或在此處與 Check Point 雲端資安工程師一起安排演示。
若要了解如何設計和實施安全的雲端架構，請查看此白皮書。
反映意見