這份架構指南提供實用指引，說明如何使用 Google Cloud規劃及設計混合雲和多雲端環境。本文件是這組文件中的第一份，並從業務和技術角度，探討這些架構帶來的機會和相關考量。此外，本文也會分析並討論許多經過驗證的混合式雲端和多雲端架構模式。
混合式雲端和多雲端架構模式的文件集包含下列部分：
- 建構混合式雲端和多雲端架構：討論如何規劃策略，以建構混合式雲端和多雲端設定(本文)。Google Cloud
- 混合式雲端和多雲端架構模式：討論可採用的常見架構模式，做為混合式雲端和多雲端策略的一部分。
- 混合式雲端和多雲端安全網路架構模式：從網路角度探討混合式雲端和多雲端網路架構模式。
您可以分別閱讀這些架構文章，但為了獲得最大效益，建議您依序閱讀這些文章，再做出架構決策。
市場需求快速變遷，企業對 IT 部門的要求和期望也越來越高，例如動態擴充、提升效能以提供最佳使用者體驗，以及安全性。許多企業級公司發現，僅靠傳統基礎架構和流程，很難滿足這些需求和期望。IT 部門也面臨提高成本效益的壓力，因此難以爭取到公司對於資料中心和設備的資本支出支持。
採用公有雲運算功能的混合雲策略，可提供務實的解決方案。只要使用公有雲，您不需要進行前期投資，就能輕鬆擴充運算平台容量及功能。
在現有基礎架構中加入一或多個以公有雲為基礎的解決方案 (例如 Google Cloud)，不僅能保住既有投資，還能避免受制於特定雲端供應商。此外，採用混合策略後，您可以在資源允許的情況下逐步將應用程式與流程現代化。
為協助您規劃架構決策和混合式或多雲端策略，請考量下列幾項潛在挑戰和設計考量。這份多部分架構指南會著重說明各種架構的潛在優勢和潛在挑戰。
混合雲和多雲端簡介
由於每個企業的工作負載、基礎架構及流程都不盡相同，因此混合雲策略必須按照企業的特定需求量身打造。因此「混合雲」和「多雲」這兩個詞的用法有時會不一致。
在本 Google Cloud 架構指南中，「混合雲」是指工作負載部署在多個運算環境的架構，其中一個環境採用公有雲，至少一個環境採用私有雲，例如地端部署資料中心或共置設施。
「多雲端」是指結合至少兩個公用雲端服務供應商的架構。如下圖所示，有時這種架構會包含私人運算環境 (可能包括使用私有雲元件)。這種配置稱為混合雲和多雲端架構。
貢獻者
作者：Marwan Al Shawi | 合作夥伴客戶工程師
其他貢獻者：
- Saud Albazei | 應用程式現代化客戶工程師
- Anna Berenberg | 工程研究員
- Marco Ferrari | 雲端解決方案架構師
- Victor Moreno | 雲端網路產品經理
- Johannes Passing | 雲端解決方案架構師
- Mark Schlagenhauf | 網路技術文件撰稿者
- Daniel Strebel | 歐洲、中東和非洲地區解決方案主管，應用程式現代化
- Ammett Williams | 開發人員關係工程師
驅動因素、考量事項、策略和做法
本文將定義並討論業務目標、驅動因素和需求，以及這些因素如何影響您建構混合雲和多雲端架構時的設計決策。
目標
機構可以採用混合式或多雲端架構，做為滿足特定業務目標的永久解決方案，或是做為暫時狀態，以利達成特定需求，例如遷移至雲端。
回答下列有關貴商家的問題，有助於定義業務需求，並針對如何達成部分或所有業務目標，建立具體期望。這些問題著重於貴商家的需求，而非如何以技術方式達成目標。
- 您想達成哪些業務目標，因此決定採用混合或多雲架構？
- 混合雲或多雲端架構有助於達成哪些業務和技術目標？
- 哪些業務因素影響了這些目標？
- 具體商家規定為何？
就混合雲和多雲架構而言，企業客戶的其中一項業務目標，可能是從單一區域擴展線上銷售業務或市場，成為市場區隔的全球領導者。其中一項業務目標可能是在六個月內，開始接受全球 (或特定區域) 使用者的採購單。
為支援上述業務需求和目標，其中一項潛在的主要技術目標是使用公有雲的全球功能和服務，將公司的 IT 基礎架構和應用程式架構從僅限於地端的模式擴展至混合式架構。這個目標應明確且可評估成效，清楚定義目標地區和時間表方面的擴展範圍。
一般來說，混合式或多雲端架構很少是目標本身，而是滿足特定業務需求所帶動技術目標的方法。因此，選擇合適的混合式或多雲端架構時，您必須先釐清需求。
請務必區分 IT 專案的業務目標和技術目標。業務目標應著重於貴機構的目標和使命。您的技術目標應著重於建構技術基礎，協助貴機構達成業務需求和目標。
業務驅動因素會影響業務目標的達成情況。因此，明確找出業務驅動因素有助於調整業務目標，使其更符合市場需求和趨勢。
下圖說明業務驅動因素、目標、目的和需求，以及技術目標和需求，並顯示所有這些因素之間的關聯：
業務和技術驅動因素
請考量業務驅動因素如何影響技術目標。選擇混合式架構時，常見的影響因素和業務驅動因子包括：
- 遵循資料自主性的相關法規。
- 在雲端財務管理和成本最佳化領域 (例如 FinOps) 的支援下，減少資本支出或一般 IT 支出。
- 採用雲端服務的動機可能是為了減少資本支出，例如在混合雲或多雲端架構中建構災難復原解決方案。
- 提升使用者體驗。
- 提高彈性和靈活度，以因應不斷變化的市場需求。
- 更清楚掌握成本和資源用量。
請一併考量採用混合式或多雲端架構的業務驅動因素清單。請勿單獨評估這些指標，最終決定應取決於業務優先要務的平衡。
貴機構瞭解雲端的好處後，如果沒有任何限制 (例如成本或特定法規遵循規定，要求將高度安全的資料託管在內部部署環境)，可能會決定全面遷移。
雖然採用單一雲端供應商可帶來多項優勢，例如降低複雜度、服務間的內建整合，以及預先承諾用量折扣等成本最佳化選項，但在某些情況下，多雲架構仍可為企業帶來助益。以下是採用多雲架構的常見業務驅動因素，以及每個驅動因素的相關考量：
- 遵循資料自主性的相關法規：最常見的情況是機構將業務擴展到新的區域或國家/地區，因此必須遵守新的資料代管法規。
- 如果現有雲端服務供應商 (CSP) 在該國家/地區沒有本機雲端區域，為符合法規要求，常見的解決方案是改用在該國家/地區有本機雲端區域的 CSP。
- 降低成本：降低成本通常是採用技術或架構最常見的業務動機。不過，決定是否採用多雲架構時，除了服務費用和潛在價格折扣，還有其他重要考量。考量在多個雲端中建構及運作解決方案的成本，以及現有系統可能造成的任何架構限制。
有時，多雲策略的潛在挑戰可能大於優點。多雲端策略日後可能會產生額外費用。
- 管理複雜度提高。
- 維持一致的安全性。
- 整合軟體環境。
- 確保跨雲端效能和可靠性一致。
- 建立具備多雲端技能的技術團隊可能很昂貴，而且除非由第三方公司管理，否則可能需要擴編團隊。
- 透過各個 CSP 管理產品定價和管理工具。
- 如果沒有解決方案提供統一的成本資訊和資訊主頁，就難以有效管理多個環境的成本。在這種情況下，您或許可以視需要使用 Looker 雲端費用管理解決方案。詳情請參閱「有效最佳化 Cloud Billing 成本管理的策略」。
- 運用各 CSP 的獨特功能：多雲端架構可讓機構使用其他新技術，改善自家業務能力產品，而不必受限於單一雲端服務供應商提供的選擇。
- 為避免任何無法預測的風險或複雜情況，請透過可行性和有效性評估，評估潛在挑戰，包括先前提及的常見挑戰。
- 避免受制於單一廠商：有時企業會想避免受制於單一雲端服務供應商。多雲端做法可讓他們選擇最符合業務需求的解決方案。不過，這項決策的可行性取決於多項因素，例如：
- 技術依附元件
- 應用程式之間的互通性注意事項
- 重建或重構應用程式的成本
- 技術技能組合
- 一致的安全性和可管理性
- 提高業務關鍵應用程式的可靠性和可用性：在某些情況下，多雲架構可提供停機復原能力。舉例來說，如果某個 CSP 的地區發生故障，流量可以轉送至同一個地區中的另一個 CSP。這個情境假設兩個雲端服務供應商都支援該區域的必要功能或服務。
如果特定國家/地區的資料落地法規規定，機密資料 (例如個人識別資訊 (PII)) 必須儲存在該地區，多雲策略就能提供符合規定的解決方案。在單一區域使用兩個 CSP，可避免服務中斷，有助於遵守法規限制，同時滿足可用性需求。
採用多雲架構前，請先評估下列復原能力注意事項：
- 資料移動：資料在多雲環境中移動的頻率？
- 資料移動是否會產生高額的資料傳輸費用？
- 安全性和可管理性：是否有任何潛在的安全或可管理性複雜問題？
- 功能一致性：所選區域的兩個 CSP 是否都提供必要功能和服務？
- 技術技能組合：技術團隊是否具備管理多雲架構所需的技能？
評估使用多雲架構提升復原能力的可行性時，請考量上述所有因素。
評估多雲架構的可行性時，請務必考量長期效益。舉例來說，為了進行災難復原或提高可靠性，而將應用程式部署至多個雲端環境，短期內可能會導致成本增加，但這麼做可防止服務中斷或故障問題發生。這類失敗可能造成長期的財務和聲譽損害。因此，請務必衡量應投入的短期成本，以及採用多雲端策略能帶來的長期潛在價值。此外，長期潛在價值會因機構規模、技術規模、技術解決方案的重要性，以及產業而異。
機構如要順利建立混合式或多雲端環境，應考慮建立卓越雲端中心 (COE)。在您轉移至雲端的過程中，卓越中心團隊可以成為管道，協助機構內部團隊改變服務業務的方式。COE 是機構加速採用雲端、推動標準化，以及在業務策略與雲端投資之間維持更緊密一致性的方法之一。
如果混合雲或多雲端架構的目標是建立暫時狀態，常見的業務驅動因素包括：
- 需要減少短期專案的資本支出或一般 IT 支出。
- 能夠快速佈建這類基礎架構，以支援業務應用情境。例如：
- 這種架構可能適用於限時專案。可用於支援需要高規模分散式基礎架構的專案，且時間有限，同時仍使用內部部署資料。
- 需要多年期數位轉型專案，大型企業必須建立這類專案，並使用混合式架構一段時間，協助他們根據業務優先事項調整基礎架構和應用程式現代化。
- 企業合併後，需要建立暫時的混合、多雲端或混合架構。這樣一來，新機構就能為新雲端架構的最終狀態定義策略。合併的兩間公司通常會使用不同的雲端服務供應商，或是一間公司使用地端部署的私人資料中心，另一間公司使用雲端服務。無論如何，併購的第一步幾乎都是整合 IT 系統。
技術驅動因素
前一節討論了業務驅動因素。如要獲得核准，重大架構決策幾乎都需要這些領導者的支持。不過，技術驅動因素 (可能基於技術收益或限制) 也會影響業務驅動因素。在某些情況下，您必須將技術驅動因素轉換為業務驅動因素，並說明這些因素可能對業務造成正面或負面影響。
以下列舉一些採用混合或多雲端架構的常見技術因素：
- 建構可能難以在現有環境中實作的技術功能，例如進階分析服務和 AI。
- 提升服務品質和效能。
- 自動化及加速應用程式發布作業，縮短上市時間和相關週期時間。
- 利用高階 API 和服務加快開發速度。
- 加速運算和儲存資源的佈建作業。
- 使用無伺服器服務，以更快的速度大規模建構彈性服務和功能。
- 運用全球基礎架構功能，建構全球或多區域架構，以滿足特定技術需求。
無論是暫時性混合式架構或暫時性多雲架構，最常見的技術驅動因素都是為了協助從內部部署環境遷移至雲端或額外雲端。一般來說，雲端遷移作業幾乎都會自然而然地導向混合雲設定。企業通常必須根據優先順序，有系統地轉移應用程式和資料。同樣地，短期設定可能旨在利用雲端提供的進階技術，在特定期間內進行概念驗證。
技術設計決策
找出技術目標及其驅動因素，是做出業務導向架構決策，以及選取本指南討論的其中一種架構模式的關鍵。舉例來說，為支援特定業務目標，公司可能會設定業務目標，在三到六個月內建立研發實務。支援這項目標的主要業務需求，可能是以盡可能低的資本支出，建構研究和設計所需的技術環境。
在本案例中，技術目標是建立暫時的混合雲設定。這項技術目標的推動因素，是為了利用雲端的隨選定價模式，滿足先前提及的業務需求。另一個驅動因素是特定技術需求，需要具備高運算容量和快速設定的雲端解決方案。
適用於混合雲和多雲端架構 Google Cloud
使用開放原始碼解決方案可簡化混合雲和多雲端方法的採用程序，並盡量避免受限於特定廠商。不過，規劃架構時，請考量下列潛在複雜性：
- 互通性
- 易管理性
- 費用
- 安全性
在有助於支援開放原始碼的雲端平台上建構，可能有助於簡化採用混合雲和多雲端架構的過程。開放式雲端提供多種選擇，並簡化複雜性，讓您如虎添翼。此外， Google Cloud 還提供靈活彈性，讓您在混合雲和多雲端環境中遷移、建構及最佳化應用程式，同時將受制於單一廠商的風險降至最低、使用同級最佳的解決方案，並符合法規要求。
Google 也是開放原始碼生態系統最大的貢獻者之一，並與開放原始碼社群合作，攜手開發 Kubernetes 等知名的開放原始碼技術。以代管服務形式推出的 Kubernetes，有助於簡化混合雲和多雲端的可管理性和安全性。
規劃混合雲和多雲端策略
本文著重於說明如何套用預先定義的業務考量，規劃混合式和多雲端策略。這份指南以驅動因素、考量事項、策略和方法為基礎，這篇文章定義並分析了企業在規劃這類策略時應考量的業務因素。
釐清並同意願景和目標
歸根究底，混合式或多雲端策略的主要目的，是達成已識別的業務需求，以及與特定業務目標一致的各個業務用途相關技術目標。為達成這個目標，請建立結構完善的計畫，並納入下列考量：
請注意，要制定能兼顧各種工作負載與需求的方案實屬不易，尤其是在複雜的 IT 環境中。此外，制定方案需要時間，而且可能造成相關人員的願景衝突。
為避免發生這種情況，請先擬定願景聲明，至少要解決下列問題：
- 為達成特定業務目標，您鎖定的業務用途為何？
- 為何現行的方法及運算環境不敷使用，無法達成業務目標？
- 使用公用雲端時，您想要最佳化哪些主要技術層面？
- 新做法為何及如何最佳化廣告活動，以達成您的業務目標？
- 您計畫要使用混合式或多雲端設置多久的時間？
對主要業務和技術目標及驅動因素達成共識，然後取得相關人員的背書，可為制定方案的後續步驟奠定基礎。為確保提案解決方案與貴機構的整體架構願景一致，請與團隊及負責主導和贊助這項計畫的利害關係人合作。
找出並釐清其他考量因素
規劃混合式或多雲架構時，請務必找出並同意專案的架構和作業限制。
在作業方面，以下列舉一些可能造成限制的非詳盡需求，供您規劃架構時參考：
- 分別管理及設定多個雲端，與建構整體模型來管理及保護不同雲端環境的差異。
- 確保驗證、授權、稽核和政策在不同環境中的一致性。
- 在各個環境中使用一致的工具和程序，全面掌握安全性、成本和最佳化機會。
- 使用一致的法規遵循和安全標準，套用統一的管理機制。
在架構規劃方面，最大的限制通常源自於現有系統，包括：
- 應用程式之間的相依性
- 系統間通訊的效能和延遲需求
- 依賴的硬體或作業系統在公有雲中可能無法使用
- 授權限制
- 取決於多雲架構所選區域中必要功能的可用性
如要進一步瞭解與工作負載可攜性、資料移動和安全性相關的其他考量事項，請參閱「其他考量事項」。
設計混合式和多雲端架構策略
釐清業務和技術目標的具體細節，以及相關的業務需求 (最好也釐清並同意願景聲明) 後，您就可以建構策略，建立混合式或多雲架構。
下方的流程圖概略說明建立這類策略的邏輯步驟。
為協助您判斷混合雲或多雲端架構的技術目標和需求，上述流程圖中的步驟會從業務需求和目標開始。策略的實作方式可能因目標、驅動因素和每個業務用途的技術遷移路徑而異。
請務必記住，遷移是一段持續的歷程。下圖說明遷移至 Google Cloud一文所述的遷移階段。
本節將針對上圖中的「評估」、「規劃」、「部署」和「最佳化」階段提供指引。並在混合雲或多雲端移轉的背景下呈現這項資訊。您應根據「遷移至 Google Cloud 」指南遷移路徑部分所述的指引和最佳做法，調整任何遷移作業。這些階段可能適用於個別工作負載，而非所有工作負載。在任何時間點，多個工作負載可能處於不同階段：
評估階段
在「評估」階段，您會進行初步工作負載評估。在這個階段，請考量願景和策略規劃文件中列出的目標。首先，請列出可能因部署或遷移至公用雲端而受益的工作負載候選清單，然後決定遷移計畫。
首先，請選擇一個工作負載，該工作負載不得為關鍵業務或遷移難度太高 (對其他環境中的任何工作負載依附元件極少或沒有)，但應可做為即將進行的部署或遷移作業的參考藍圖。
理想情況下，您選取的工作負載或應用程式應屬於目標業務用途或功能，完成後可對業務產生可衡量的影響。
如要評估及降低任何潛在的遷移風險，請進行遷移風險評估。請務必評估候選工作負載，判斷是否適合遷移至多雲環境。這項評估作業會評估應用程式和基礎架構的各個層面，包括：
- 應用程式與所選雲端服務供應商的相容性規定
- 計費模式
- 所選雲端供應商提供的安全功能
- 應用程式互通性規定
執行評估也有助於您在多個雲端環境中，找出資料隱私權規定、法規遵循規定、一致性規定和解決方案。您發現的風險可能會影響選擇遷移或執行的工作負載。
您可以使用多種工具 (例如 Google Cloud 遷移中心) 評估現有工作負載。詳情請參閱「遷移至 Google Cloud：選擇評估工具」。
從工作負載現代化角度來看，適配評估工具可評估 VM 工作負載，判斷工作負載是否適合遷移至容器以進行現代化，或是適合遷移至 Compute Engine。
規劃階段
在「規劃」階段，請從已識別的應用程式和必要雲端工作負載著手，並執行下列工作：
- 制定優先遷移策略，定義應用程式遷移波和路徑。
- 找出適用的高階混合式或多雲端應用程式架構模式。
- 選取支援所選應用程式架構模式的網路架構模式。
理想情況下，您應將雲端網路模式納入登陸區設計。登陸區設計是整體混合雲和多雲端架構的基礎要素。設計必須與這些模式無縫整合。請勿獨立設計登陸區。請將這些網路模式視為登陸區設計的子集。
登陸區可能包含不同的應用程式，每個應用程式都有不同的網路架構模式。此外，在這個階段中，請務必決定Google Cloud 機構、專案和資源階層結構的設計，為混合式或多雲端整合與部署作業準備好雲端環境登陸區。
在這個階段中，請考慮下列事項：
- 定義遷移和翻新方法。本指南稍後會進一步說明遷移方法。「遷移至 Google Cloud」遷移類型一節也詳細說明瞭這項功能。
- 運用評估和探索階段的發現。與您預計要遷移的候選工作負載對齊。然後制定應用程式遷移分批計畫。該計畫應納入您在評估階段確定的預估資源大小需求。
- 定義分散式應用程式之間，以及應用程式元件之間所需的通訊模型，以符合預期的混合雲或多雲架構。
- 決定適合的部署原型，例如區域、多區域或全球，以部署所選架構模式的工作負載。您選取的原型會成為建構應用程式專屬部署架構的基礎，以滿足您的業務和技術需求。
- 決定可評估的遷移成功標準，並為每個遷移階段或波次設定明確的里程碑。即使技術目標是將混合式架構做為短期設定，選取條件仍不可或缺。
- 當應用程式在混合式設定中運作時，請定義應用程式 SLA 和 KPI，尤其是可能在多個環境中分散元件的應用程式。
詳情請參閱「關於遷移規劃」，瞭解如何規劃順利遷移，並將相關風險降至最低。
部署階段
在「部署」階段，您已準備好開始執行遷移策略。由於需求數量可能很多，因此建議您逐一執行工作負載。
根據您在規劃階段制定的遷移和應用程式波次，排定工作負載的優先順序。採用混合式和多雲端架構時，請先在 Google Cloud 和其他運算環境之間建立必要連線，再開始部署。為方便混合雲或多雲端架構採用必要的通訊模型，請根據所選設計和網路連線類型，以及適用的網路模式部署服務。建議您採用這種方法，決定整體登陸區設計。
此外，您必須根據定義的應用程式成功標準，測試及驗證應用程式或服務。理想情況下，這些準則應包括功能和負載測試 (非功能) 需求，然後再移至正式環境。
最佳化階段
在「最佳化」階段，請測試部署作業：完成測試後，如果應用程式或服務符合功能和效能容量的預期，即可移至正式環境。雲端監控和可視性工具 (例如 Cloud Monitoring) 可提供應用程式和基礎架構的效能、可用性和健康狀態深入分析資料，協助您視需要進行最佳化。
詳情請參閱「遷移至 Google Cloud：最佳化環境」。如要進一步瞭解如何為混合式或多雲端架構設計這類工具，請參閱混合式雲端和多雲端監控與記錄模式。
評估候選工作負載
為不同工作負載選擇運算環境，會對混合式和多雲端策略的成效造成重大影響。工作負載放置位置的決策應與特定業務目標一致。因此，這些決策應以目標業務用途為依據，以利評估業務成效。不過，不一定需要從業務最關鍵的工作負載/應用程式開始，我們也不建議這麼做。詳情請參閱「遷移至」 Google Cloud 指南中的「選擇要先遷移的應用程式」。
如「業務和技術驅動因素」一節所述，混合式和多雲端架構有不同類型的驅動因素和考量事項。
以下列出的因素摘要可協助您評估遷移用例，瞭解混合雲或多雲端架構的商機，進而產生可衡量的業務影響：
- 雲端服務能夠帶來的市場差異化或創新潛力，例如使用現有內部部署資料訓練機器學習模型，藉此啟用人工智慧功能等特定商務功能或服務。
- 應用程式可節省的總擁有成本。
- 可用性、彈性、安全性或效能的改善空間，例如在雲端新增災難復原 (DR) 網站。
- 加快開發及發布流程的可能性，例如在雲端建構開發及測試環境。
以下因素可協助您評估遷移風險：
- 遷移作業可能導致服務中斷。
- 團隊使用公有雲端部署或新/第二個雲端服務供應商部署的經驗。
- 遵守現有法令或法規限制的需求。
以下因素可協助您評估遷移的技術難度：
- 應用程式的大小、複雜度和新舊程度。
- 不同運算環境中，與其他應用程式和服務的相依性數量。
- 第三方授權設下的任何限制。
- 對特定版本作業系統、資料庫或其他環境設定的依賴程度。
初步評估工作負載後，您就可以開始確立工作負載的優先順序，以及定義遷移批次和方法。接著，您可以找出適用的架構模式和支援的網路模式。這項步驟可能需要反覆思量，因為評估結果可能會隨時間改變。因此，您不妨在完成首次雲端部署之後，重新評估工作負載。
採用混合雲或多雲端架構的架構方法
本文提供常見且經過驗證的方法和考量因素，協助您將工作負載遷移至雲端。本文將擴充「制定混合式和多雲端架構策略」一文中的指引，討論採用混合式或多雲端架構時，可採取的幾個建議步驟。
雲端優先
開始使用公有雲的常見方法是採取「雲端優先」做法。 根據這個方法，您必須將新的工作負載部署到公用雲端，現有工作負載則維持不變。除非技術或機構原因導致公有雲部署不可行時，才建議您考慮在私人運算環境中進行傳統部署作業。
雲端優先策略有優點也有缺點。從好的一面來看，雲端優先策略是具有前瞻性的策略，您可以採用現代化方式部署新的工作負載，減少或免除遷移現有工作負載的麻煩。
雲端優先方法雖然有某些優點，但可能會導致您錯失改善或使用現有工作負載的機會。新工作負載可能只佔整體 IT 環境的一小部分，對 IT 支出和效能的影響可能有限。相較於將新工作負載置入雲端環境，您針對遷移現有工作負載所投注的時間和資源，可能帶來更大的優勢或節省更多成本。
採用嚴謹的雲端優先策略還可能使您的整體 IT 環境變得更為複雜，因為這種策略可能會造成冗餘、效能不彰 (跨環境通訊過多所致)，或是運算環境不適用於個別工作負載。此外，企業也可能因為要遵守產業法規和資料隱私權法律，而無法遷移含有敏感資料的特定應用程式。
考慮到這些風險，建議您只針對特定工作負載採用雲端優先方法，採用雲端優先方法，可讓您專注於可從雲端部署或遷移中獲益最多的工作負載。此方法還考慮了現有工作負載的現代化。
舉例來說，如果保存重要資料的舊版應用程式和服務必須與新資料或應用程式整合，就是採用雲端優先混合架構的常見情況。如要完成整合，您可以採用混合式架構，透過 API 介面翻新舊版服務，讓新雲端服務和應用程式能使用這些服務。有了雲端 API 管理平台 (例如 Apigee)，您就能以最少的應用程式變更，實作這類用途，並為舊版服務增加安全性、數據分析和擴充性。
遷移和現代化
混合式多雲端和 IT 現代化是不同的概念，但兩者彼此相關，並可形成良性循環。使用公有雲可以促進及簡化 IT 工作負載的現代化。IT 工作負載現代化可讓您獲得更多雲端部署帶來的好處。
將工作負載現代化的主要目標是：
- 實現更高的敏捷性，以因應不斷變化的需求。
- 降低基礎架構和營運成本。
- 提高可靠度和彈性，以盡量降低風險。
不過，在遷移過程中，可能無法同時翻新所有應用程式。如「遷移至 Google Cloud」一文所述，您可以實作下列其中一種遷移類型，甚至視需要合併多種類型：
- 重新託管 (隨即轉移)
- 更換平台 (轉移並最佳化)
- 重構 (遷移與改善)
- 重新建立架構 (持續翻新)
- 重建 (移除並更換，有時也稱為「淘汰並更換」)
- 重新購買
針對混合雲和多雲架構做出策略決策時，請務必從成本和時間的角度，考量策略的可行性。建議您考慮分階段遷移，先進行隨即轉移或重新平台化，然後再重構或重新架構。通常，隨即轉移有助於從基礎架構的角度最佳化應用程式。應用程式在雲端執行後，就能更輕鬆地使用及整合雲端服務，進一步運用雲端優先架構和功能進行最佳化。此外，這些應用程式仍可透過混合式網路連線與其他環境通訊。
舉例來說，您可以根據雲端微服務架構，重構或重新設計大型單體式 VM 型應用程式，將其轉換成數個獨立的微服務。在本範例中，微服務架構使用 Google Cloud 代管容器服務，例如 Google Kubernetes Engine (GKE) 或 Cloud Run。不過，如果目標雲端環境不支援應用程式目前的架構或基礎架構，您不妨考慮先從重新平台化、重構或重新架構遷移策略著手，盡可能克服這些限制。
使用上述任一遷移方法時，請考慮翻新應用程式 (如適用且可行)。現代化可能需要採用及實作網站可靠性工程 (SRE) 或開發運作原則，因此您可能也需要在混合式設定中，將應用程式現代化擴展至私人環境。雖然實作 SRE 原則的核心是工程，但這比較像是轉型程序，而非技術挑戰。因此，您可能需要進行程序和文化變革。如要進一步瞭解在機構中導入 SRE 的第一步，就是取得領導階層的支持，請參閱「With SRE, failing to plan is planning to fail」。
混用及採行適合的遷移方法
本文討論的每種遷移方法各有優缺點。混合式雲端和多雲端策略的最大優勢就是不用拘泥於一種方法，您可以為每個工作負載或應用程式堆疊決定最適合的做法，如下圖所示。
這張概念圖說明可同時套用至不同工作負載的各種遷移和現代化路徑或方法，這些路徑或方法會因各工作負載或應用程式的獨特業務、技術需求和目標而異。
此外，相同的應用程式堆疊元件不一定要採用相同的遷移方法或策略。例如：
- 應用程式的後端內部部署資料庫可以從自行代管的 MySQL 重新平台化，並使用 Cloud SQL 在 Google Cloud中改為代管資料庫。
- 應用程式前端虛擬機器可以重構，以便使用 GKE Autopilot 在容器上執行，Google 會管理叢集設定，包括節點、資源調度、安全性及其他預設設定。
- 您可以改用 Cloud Load Balancing 和 Google Cloud Armor，取代內部部署硬體負載平衡解決方案和網路應用程式防火牆 (WAF) 功能。
如果工作負載符合以下任一條件，請選用重新託管 (隨即轉移) 法：
- 對本身所處環境的依賴程度相對較低。
- 不值得進行重構，或在遷移前重構不可行。
- 架構在第三方軟體之上。
如為以下類型的工作負載，請考慮使用重構 (遷移與改善) 法：
- 有必須解除的依賴關係。
- 依賴雲端無法提供的作業系統、硬體或資料庫系統。
- 無法有效利用運算或儲存空間資源。
- 需要費一番功夫才能以自動化方式部署。
如為以下類型的工作負載，請考慮使用重建 (移除並更換) 法：
- 已無法滿足目前的需求。
- 這些 API 可與提供類似功能的其他應用程式整合，同時滿足業務需求。
- 以終止服務的第三方技術為基礎。
- 需支付已不符合成本效益的第三方授權費。
快速遷移計畫說明如何 Google Cloud 協助客戶採用最佳做法、降低風險、控管成本，以及簡化雲端遷移流程。
其他注意事項
這份文件著重說明核心設計考量，這些考量在形塑整體混合式雲端和多雲端架構時，扮演舉足輕重的角色。全面分析及評估整個解決方案架構的這些考量因素，涵蓋所有工作負載，而不僅限於特定工作負載。
重構
在重構遷移中，您可以修改工作負載以利用雲端功能，而不僅僅是讓工作負載得以在新環境中運作。您可以針對效能、功能、費用和使用者體驗這些方面來改進各項工作負載。如「重構：遷移並改善」一文所述，部分重構情境可讓您在將工作負載遷移至雲端前進行修改。這種重構方法具有下列優點，特別是如果您的目標是建構混合式架構，做為長期目標架構：
- 您可以改善部署程序。
- 投資持續整合/持續部署 (CI/CD) 基礎架構和工具，有助於加快發布速度並縮短意見回饋週期。
- 您可以將重構做為基礎，建構及管理混合式架構，並確保應用程式可攜性。
為使這種做法充分發揮效用，您通常需要針對一些內部部署基礎架構和工具進行投資。例如設定本機 Container Registry，以及佈建 Kubernetes 叢集，以將應用程式容器化。Google Kubernetes Engine (GKE) Enterprise 版在這類混合式環境中非常實用。如要進一步瞭解 GKE Enterprise，請參閱下一個章節。如需更多詳細資料，請參閱 GKE Enterprise 混合環境參考架構。
工作負載可攜性
在混合式和多雲架構中，您可能希望能夠在代管資料的運算環境之間轉移工作負載。為協助在環境之間順暢移動工作負載，請考慮下列因素：
- 您可以在不大幅修改應用程式及其作業模式的情況下，將應用程式從一個運算環境移轉到另一個環境：
- 應用程式的部署及管理方法在不同運算環境中都是一致的。
- 不同運算環境的顯示設定、設定和安全性一致。
- 工作負載的可攜性不應與雲端優先的工作負載發生衝突。
基礎架構自動化
基礎架構自動化是混合式雲端和多雲端架構可攜性的必要條件。自動建立基礎架構的常見方法之一，是透過基礎架構即程式碼 (IaC)。採用 IaC 時，您會透過檔案管理基礎架構，而非在使用者介面中手動設定資源，例如 VM、安全群組或負載平衡器。Terraform 是熱門的 IaC 工具，可定義檔案中的基礎架構資源。您也可以使用 Terraform，在異質環境中自動建立這些資源。
如要進一步瞭解 Terraform 核心功能，如何協助您自動佈建及管理 Google Cloud 資源，請參閱「Terraform blueprints and modules for Google Cloud」。
您可以使用 Ansible、Puppet 或 Chef 等設定管理工具，建立常見的部署和設定程序。您也可以使用 Packer 等映像檔製作工具，為不同平台建立 VM 映像檔。您可以使用單一共用的設定檔，透過 Packer 和 Cloud Build 建立 VM 映像檔，以便在 Compute Engine 上使用。最後，您可以使用 Prometheus、Grafana 等解決方案來確保跨環境監控的一致性。
以這些工具做為基礎，您可以組成一個常見的工具鍊，如下列邏輯圖所示。這個通用工具鍊可抽離運算環境之間的差異，還能整合佈建、部署、管理及監控作業。
雖然通用工具鍊可協助您實現工作負載的可攜性，但它有幾個缺點：
- 以 VM 做為共同基礎，將使您很難實作真正的雲端優先應用程式。此外，如果只使用 VM，您就無法使用雲端代管服務。您可能會錯失減少管理負擔的機會。
- 建立及維護通用工具鍊會產生營運費用和成本。
- 隨著工具鍊擴大，可能會出現專為貴公司特定需求量身打造的獨特複雜性。複雜度增加可能會導致訓練成本上漲。
決定開發工具和自動化功能前，請先瞭解雲端供應商提供的代管服務。如果供應商提供的代管服務支援相同的使用案例，您就能簡化部分複雜程序。這樣一來，您就能專注於工作負載和應用程式架構，不必費心處理基礎架構。
舉例來說，您可以使用 Kubernetes 資源模型，以宣告式設定方法自動建立 Kubernetes 叢集。您可以使用 Deployment Manager convert，將 Deployment Manager 設定和範本轉換為 Google Cloud 支援的其他宣告式設定格式 (例如 Terraform 和 Kubernetes 資源模型)，以便在發布時攜帶這些設定和範本。
您也可以考慮自動化建立專案，以及在這些專案中建立資源。這項自動化功能可協助您以基礎架構即程式碼的方式佈建專案。
容器和 Kubernetes
使用雲端管理功能，有助於簡化自訂工具鍊的建構和維護作業，進而實現工作負載自動化和可攜性。不過，以 VM 做為共同基礎，將使您很難實作真正雲端優先的應用程式。改用容器和 Kubernetes 是一個解決辦法。
當您將軟體從一個環境遷移到另一個環境時，容器能讓軟體可靠地執行。容器可將應用程式與底層主機基礎架構分離，因此有助於在混合雲和多雲端等運算環境中部署應用程式。
Kubernetes 會負責處理容器化應用程式的調度、部署、擴展及管理作業。這項技術屬於開放原始碼，由 Cloud Native Computing Foundation (雲端原生運算基金會) 管理。Kubernetes 提供構成雲端優先應用程式基礎的服務。您可以在多種運算環境中安裝及執行 Kubernetes，因此也可以利用 Kubernetes 來建立跨運算環境的共用執行階段層：
- Kubernetes 在雲端或私人運算環境中可提供相同的服務和 API。此外，Kubernetes 的抽象層又比使用 VM 時高出很多，這通常可減少所需的基礎工作，並提高開發人員的生產力。
- 與自訂工具鏈不同，Kubernetes 已廣泛應用於開發和應用程式管理作業，因此您可以利用現有的專業知識、說明文件，以及第三方支援。
- Kubernetes 支援所有符合下列條件的容器實作項目：
- 支援 Kubernetes 容器執行階段介面 (CRI)
- 已在產業中廣泛採用
- 不綁定任何特定供應商
工作負載在 Google Cloud上執行時，您可以使用 Google Kubernetes Engine (GKE) 等代管 Kubernetes 平台，免除安裝及運作 Kubernetes 的工作。這樣一來，營運人員就能將重心從建構及維護基礎架構，轉移到建構及維護應用程式。
您也可以使用 Autopilot，這是 GKE 的作業模式，可管理叢集設定，包括節點、資源調度、安全性和其他預先設定。使用 GKE Autopilot 時，請考量您的擴縮需求和擴縮限制。
從技術上來說，您可以在許多運算環境中安裝及執行 Kubernetes，建立共用的執行階段層。不過，從實務角度來看，建構及運作這類架構可能會造成複雜性。如果您需要容器層級的安全控管 (服務網格)，架構會變得更加複雜。
如要簡化多叢集部署作業的管理方式，可以使用 GKE Enterprise 大規模執行現代化應用程式，GKE 內含強大的受管理開放原始碼元件，可保護工作負載、強制執行法規遵循政策，並提供深入的網路可觀測性和疑難排解功能。
如下圖所示，使用 GKE Enterprise 代表您可以將多叢集應用程式做為車隊運作。
GKE Enterprise 提供下列設計選項，支援混合雲和多雲端架構：
在內部部署系統中設計及建構類似雲端的體驗，或採用統一的解決方案，將應用程式遷移至 GKE Enterprise 混合式環境。詳情請參閱 GKE Enterprise 混合式環境參考架構。
設計及建構解決方案，透過 GKE Multi-Cloud 採用一致的管理、作業和安全防護機制，解決多雲環境的複雜問題。詳情請參閱 GKE Multi-Cloud 說明文件。
GKE Enterprise 也提供類似環境的邏輯分組，並確保安全防護、設定和服務管理的一致性。舉例來說，GKE Enterprise 可支援零信任分散式架構。在零信任分散式架構中，部署於地端或其他雲端環境的服務，可以透過端對端 mTLS 安全服務間通訊，跨環境進行通訊。
工作負載可攜性考量事項
Kubernetes 和 GKE Enterprise 為工作負載提供抽象層，可隱藏運算環境的許多細節和差異。以下列出部分抽象概念：
- 應用程式可在進行最小幅度變更的情況下攜帶至不同的環境，但這並不表示應用程式在兩種環境中的效能一樣好。
- 運算、基礎架構安全性功能或網路基礎架構的差異，以及與相依服務的距離遠近，可能會導致兩者的效能出現很大的落差。
- 當您把工作負載遷移到另一個運算環境時，可能也需要遷移資料。
- 不同環境可能會有不同的資料儲存和管理服務與設施。
- 以 Kubernetes 或 GKE Enterprise 佈建的負載平衡器，在不同環境中的行為和效能可能有所差異。
資料遷移
在運算環境之間大規模移動、共用及存取資料可能很複雜，因此企業級公司可能會猶豫是否要建構混合式或多雲端架構。如果他們已將大部分資料儲存在地端或單一雲端，這種猶豫感可能會更加強烈。
不過， Google Cloud提供的各種資料移動選項，可為企業提供全方位的解決方案，協助移動、整合及轉換資料。這些選項可協助企業在不同環境中儲存、共用及存取資料，以滿足特定用途。這項功能最終可讓企業和技術決策者更輕鬆地採用混合式和多雲端架構。
資料移動是混合雲和多雲端策略與架構規劃的重要考量。您的團隊需要找出不同的業務用途，以及支援這些用途的資料。您也應考慮儲存空間類型、容量、存取權和移動選項。
如果企業為受監管產業設定資料分類，這項分類有助於找出特定資料類別的儲存位置，以及跨區域資料移動限制。詳情請參閱「Sensitive Data Protection」。Sensitive Data Protection 是一項全代管服務，可協助您探索、分類及保護資料資產。
如要瞭解相關程序，包括規劃資料移轉和實施計畫的最佳做法等，請參閱「遷移至 Google Cloud：轉移大型資料集」。
安全性
隨著機構採用混合雲和多雲端架構，系統和資料在不同環境中分散的方式可能會增加攻擊面。加上威脅環境不斷演變，攻擊面增加可能會導致未經授權的存取、資料遺失和其他安全事件的風險增加。規劃及實作混合式或多雲端策略時，請仔細考量安全性。
詳情請參閱「Attack Surface Management for Google Cloud」。
設計混合架構時，將地端安全防護方法擴展到雲端，在技術上不一定可行或可行。不過，硬體裝置的許多網路安全功能都是雲端優先功能，且以分散式方式運作。如要進一步瞭解 Google Cloud的雲端優先網路安全功能，請參閱「雲端網路安全性」。
混合雲和多雲端架構可能會帶來額外的安全性挑戰，例如一致性和可觀測性。每家公有雲供應商都有自己的安全防護方法，包括不同的模型、最佳做法、基礎架構和應用程式安全防護功能、法規遵循義務，甚至是安全防護服務的名稱。這些不一致可能會增加安全風險。此外，各雲端供應商的共同責任模式可能有所不同。在多雲架構中，務必找出並瞭解確切的責任分界。
觀測能力是從不同環境取得洞察資料和指標的關鍵。在多雲架構中，每個雲端通常都會提供工具，用於監控安全防護措施和設定錯誤。不過，使用這些工具會導致資訊孤立，無法在整個環境中建立進階威脅情報。因此，安全團隊必須在工具和資訊主頁之間切換，才能確保雲端安全。如果無法全面掌握混合式和多雲端環境的端對端安全防護情況，就難以優先處理及減輕安全漏洞的影響。
如要全面掌握所有環境的能見度和狀態，請優先處理安全漏洞，並減少您發現的安全漏洞。建議採用集中式曝光度模型。集中式曝光度模型可避免手動關聯不同平台的不同工具和資訊主頁。詳情請參閱混合雲和多雲端的監控及記錄模式。
為減輕安全風險並在Google Cloud上部署工作負載，以及協助您規劃及設計雲端解決方案，以達成安全性和法規遵循目標，請參閱 Google Cloud 安全性最佳做法中心和企業基礎藍圖。
法規遵循目標可能因產業特定法規，以及不同地區和國家/地區的法規要求而異。詳情請參閱 Google Cloud 法規遵循資源中心。 以下是幾種主要建議方法，可協助您設計安全的混合雲和多雲端架構：
制定統一的專屬雲端安全策略和架構。混合雲和多雲安全策略應根據貴機構的特定需求和目標量身打造。
實作安全控管機制前，請務必先瞭解目標架構和環境，因為每個環境可能使用不同的功能、設定和服務。
考慮在混合雲和多雲端環境中採用統一的安全性架構。
標準化雲端設計和部署作業，尤其是安全設計和功能。這樣做可以提高效率，並啟用統一控管和工具。
使用多項安全控管措施。
一般來說，單一安全控制項無法充分滿足所有安全防護需求。因此，機構應採用縱深防禦方法，結合多種安全控管措施。
監控並持續改善安全防護機制：貴機構應監控不同環境中的安全威脅和安全漏洞。並持續提升安全防護機制。
建議使用雲端安全防護機制管理 (CSPM) 服務，找出並修正安全性設定錯誤和網路安全威脅。CSPM 也提供混合式雲端和多雲端環境的安全漏洞評估。
Security Command Center 是 Google Cloud 適用的內建安全性與風險管理解決方案，可協助找出設定錯誤和安全漏洞等問題。 Google CloudSecurity Health Analytics 是一種受管理的安全性弱點評估掃描工具。這項 Security Command Center 功能可找出Google Cloud 環境中的安全風險和安全漏洞，並提供修正建議。
Mandiant Attack Surface Management for Google Cloud 可協助貴機構更清楚掌握多雲端或混合雲環境資產。這項服務會自動探索多個雲端供應商、DNS 和擴展外部攻擊面的資產，協助企業深入瞭解生態系統。根據這項資訊，優先修復風險最高的安全漏洞和暴露面。
- 雲端安全資訊與事件管理 (SIEM) 解決方案：有助於收集及分析混合式和多雲環境中的安全記錄，以偵測及因應威脅。Google Security Operations SIEM Google Cloud 可集中收集、分析、偵測及調查所有安全性資料，提供安全資訊與事件管理服務。
使用 Google Cloud建構混合雲和多雲端架構：後續步驟
- 進一步瞭解如何開始遷移至 Google Cloud。
- 瞭解混合式雲端和多雲端的常用架構模式，以及這兩種雲端最合適的用途與使用方法。
- 進一步瞭解混合式雲端和多雲端架構的網路模式，以及如何設計這些模式。
- 探索、分析及比較不同部署原型的 Google Cloud。
- 瞭解登陸區設計。 Google Cloud
- 進一步瞭解 Google Cloud Well-Architected Framework
- 閱讀我們的將 VM 遷移至 Compute Engine 的最佳做法。