以雲端原生方式重新建立架構
開發運作研究與評估公司 (DevOps Research and Assessment，DORA) 的一項研究指出，頂尖的開發運作團隊每天會進行多項部署作業，且可在不到一天的時間內將變更發布至實際工作環境，變更失敗率更只有 0% - 15%。
本白皮書說明如何將應用程式架構重新建構為雲端原生模式，讓您在拓展團隊規模時加速推送新功能，同時提升軟體品質並實現更高的穩定性和可用性。
為何要遷移至雲端原生架構？
許多公司會使用單體架構來建構自己特別打造的軟體服務，這種做法的好處是，單體系統相當易於設計及部署，至少一開始是如此。不過，隨著應用程式趨於複雜，開發人員工作效率和部署速度將難以維持一貫的水準，導致系統變更不僅耗時且所費不貲，還有部署風險。
隨著服務 (以及負責團隊) 的成長，企業往往會變得越來越複雜，也更難以改良及運作。測試和部署變得更加困難，加入新功能也變得更加棘手，維護穩定性和可用性也會是一大挑戰。
Google 的 DORA 團隊研究結果顯示，針對不同規模和網域的機構，您可以實現高層級的軟體交付總處理量、服務穩定性和可用性。高成效團隊每天可以完成多次部署作業、不到一天即可將異動內容推送至實際工作環境、在一小時內恢復服務，並將變更失敗率維持在 0 至 15%。1
此外，從每位開發人員的每日部署項目進行評估 (即使團隊規模增加也沒問題)，可發現高效能開發人員也能達到更高的開發人員生產力。這點顯示於圖 1。
這份白皮書接下來的部分會說明如何將應用程式遷移至現代雲端原生模式，協助您達到這些成果。如實行這份白皮書所述的技術做法，您可達成下列目標：
- 即使增加團隊規模，也能提高開發人員生產力
- 上市時間更快：更快新增功能並修正瑕疵
- 提高可用性：增加軟體的運作時間、降低部署失敗率，並在事件發生時縮短還原的時間
- 強化安全性：減少應用程式的受攻擊面，並輕鬆快速偵測及回應攻擊和新發現的安全漏洞
- 提高擴充性：雲端原生平台與應用程式可輕鬆視需求水平調度資源，並縮減資源配置
- 降低成本：簡化軟體推送程序可降低推送新功能的成本，有效利用雲端平台可大幅降低服務的營運成本
1 根據以下 4 項重要指標，瞭解您的團隊的成效：https://cloud.google.com/devops/
什麼是雲端原生架構？
單體式應用程式必須以單一單元的形式建構、測試及部署。一般來說，每個應用程式的作業系統、中介軟體和語言堆疊，都是專為該應用程式量身打造或特別設定，通常也會有專屬的建構、測試、部署指令碼和程序。就綠地應用程式而言，團隊能以簡單有效的方式執行這些程序。然而，隨著應用程式成長，變更、測試、部署及運作此類系統的難度也會隨之提高。
此外，隨著系統不斷成長，建構、測試、部署及運作服務的團隊規模和複雜度也會跟著增加。常見但稍嫌不足的做法是依功能分離團隊，但這會帶來團隊間的交接作業，並增加前置時間和批次規模，導致大量的重工。DORA 的研究顯示，高效能團隊在單一的跨部門團隊中進行開發和推送軟體的可能性是兩倍。
這個問題的現象有：
- 建構程序冗長且經常失敗
- 整合及測試週期頻率低
- 建構及測試程序的支援作業增加
- 開發人員工作效率下滑
- 必須花上數小時的困難部署程序，而且必須排定停機時間
- 在測試和實際執行環境的設定方面帶來大量管理作業
相較之下，以雲端原生模式來說：³
- 複雜的系統會拆解為可單獨測試及部署在容器化執行階段 (微服務或服務導向架構) 的服務
- 應用程式使用標準平台提供的服務，例如資料庫管理系統 (DBMS)、blob 儲存空間、訊息傳遞、CDN 和 SSL 終止
- 標準化雲端平台可妥善解決許多作業問題，例如部署、自動調度資源、設定、密鑰管理、監控和快訊。應用程式開發團隊可視需求存取這些服務
- 為應用程式開發人員提供標準化的作業系統、中介軟體和語言專屬堆疊，且這些堆疊的維護和修補作業均由平台供應商或另一個團隊頻外執行
- 單一跨功能團隊可負責每項服務的整個軟體推送生命週期
3 本文並不能詳細說明「雲端原生」是什麼意思：如需雲端原生架構的一些原則討論，請參閱 https://cloud.google.com/blog/products/ application-development/5-principles-for-cloud-native-architecture-what-it-is-and-how-to-master-it。
這個模式可帶來許多優勢：
| 更快交付 | 發布程序穩定 | 降低費用 |
| 由於現在的服務規模小且採用鬆耦合設計，因此與這些服務相關的團隊可以自主作業，進而提升開發人員工作效率和部署速度。 | 開發人員可以在接近實際執行環境的測試環境中快速建構、測試及部署全新和現有服務，部署至實際執行環境的程序也相當簡單且完整，能大幅加快軟體推送程序速度，並降低部署風險。 | 由於標準化的共用服務是由平台提供，而應用程式是在共用的實體基礎架構上執行，因此測試及實際執行環境的成本和複雜程度將大幅降低。 |
| 更佳的安全性 | 提高可用性 | 更簡單實惠的法規遵循 |
|
供應商現在必須負責維持共用服務，例如 DBMS 與訊息基礎架構，確保其為最新、進行修補及符合規範。此外，由於應用程式可透過標準方式部署及管理，因此讓應用程式進行修補及更新就是更加容易。 |
由於作業環境的複雜度降低、設定變更的簡易性，以及處理平台層級的自動調度資源和自動修復功能，應用程式可用性和可靠性均會提高。 | 大部分的資訊安全控管都能在平台層實作，因此能以更便宜、更簡便的方式實作及提出法規遵循證明。許多雲端服務供應商持續遵守風險管理架構 (例如 SOC2 和 FedRAMP)，因此部署於這些服務供應商的應用程式僅須針對未於平台層上實作的剩餘控制項提出法規遵循證明。 |
不過，雲端原生模型有一些優缺點：
- 現在所有應用程式都屬於分散式系統，會在作業過程中產生大量遠端呼叫。因此，務必仔細思考如何處理網路故障和效能問題，以及如何對實際執行環境中的問題進行偵錯。
- 開發人員必須使用平台提供的標準化作業系統、中介軟體和應用程式堆疊，導致本機開發作業更困難。
- 架構師必須採用事件導向的系統設計，包括採用最終一致性。
遷移至雲端原生架構
許多機構採用「隨即轉移」的方式將服務遷移至雲端。這種做法只需對系統進行小程度的異動，雲端基本上做為傳統資料中心使用，但比傳統資料中心提供更佳的 API、服務和管理工具。不過，隨即轉移本身並不會帶來前述任何雲端原生模式具備的優勢。
許多機構都因為將應用程式遷移至雲端原生架構的成本和複雜性，而猶豫是否採用隨即轉移方式，因此必須重新思考應用程式架構和實際工作環境作業等所有層面，以及整個軟體推送生命週期。這個結果十分令人害怕：許多大型機構都因多年失敗、「大爆炸」式徹底改變平台的作業而疲乏。
解決方法是採用漸進式、反覆式且不斷進化的方法，將系統重新建構為雲端原生架構，讓團隊瞭解如何在這個新模式中提升工作效率，同時持續交付新功能。我們將這種方式稱之為「遷移與改善」。
演進架構中的關鍵模式稱為 strangler fig 應用程式。4 與其從頭徹底重新編寫系統，改為以現代化的雲端原生樣式編寫新功能，但讓應用程式與原有的單體式應用程式相互使用，以維持現有的功能。隨時間將現有的功能視情況逐步移轉到新服務的概念完整性，如圖 2 所示。
4 已在 https://martinfowler.com/bliki/StranglerFigApplication.html 中說明。
以下是成功重新建構架構的三個重要準則：
第一，從快速推送新功能著手，而不是重現既有功能。重點是您能夠多快開始使用新服務推送新功能。實際在這種模式下工作，才能迅速瞭解並交流從中獲得的良好做法。請大幅縮減作業範圍，將目標設為在數週內推送項目給使用者，而不是數月內。
第二，以雲端原生方式設計。也就是說，請使用雲端平台的原生服務，例如 DBMS、訊息傳遞、CDN、網路、blob 儲存空間等，同時盡可能使用平台提供的標準化應用程式堆疊。您應將服務容器化、盡可能使用無伺服器模式，並使建構、測試和部署程序全面自動化。此外，所有應用程式都應使用平台提供的共用服務來進行記錄、監控及傳送快訊。(值得注意的是，這種平台架構可有效部署至任何多用戶群應用程式平台，包括裸機地端部署環境。)雲端原生平台的整體架構圖如下方圖 3 所示。
最後，設計自主工作、鬆耦合團隊，以測試及部署自己的服務。我們的研究顯示，最重要的架構結果是軟體推送團隊是否能正面回答這六個問題：
- 我們可以在未經其他非團隊成員許可的情況下，對系統的設計進行大規模變更
- 我們可以自行大規模調整系統設計，而不必依賴其他團隊變更其系統，或為其他團隊帶來重大工作。
- 我們可以完成工作，不必與團隊外部人員溝通協調。
- 無論依附的相關服務為何，我們都能視需求部署及發布產品或服務
- 我們可以視需求執行大部分的測試作業，而且不需要整合測試環境
- 可在正常的營業時間內執行部署作業，而且幾乎不會經歷到停機時間
請定期確認團隊是否朝這些目標努力，並以達成目標為首要之務。這通常包括重新思考機構和企業架構。
具體來說，重點就是組織團隊，讓建構、測試及部署軟體所需的各種職務 (包含產品經理) 都能一起合作，並使用現代化的產品管理做法來建構及改進他們處理的服務。這不需更動組織架構，只要讓這些人員以團隊形式每天一起合作 (可能的話也讓他們共用一個實體空間)，就能對工作效率帶來明顯影響，不必讓開發人員、測試人員和發布團隊獨立運作。
我們的研究顯示，團隊對於這些方式的同意程度，可相當準確預示高軟體效能：每天提供數項穩定且可用性高的服務。因此，即使團隊數量增加，高效能團隊也能提高開發人員的生產力 (以每日每位開發人員的部署作業數量評估)。
原則與做法
微服務架構原則和做法
採用微服務或服務導向的架構時，請務必遵循相關重要原則和做法。最好一開始就嚴格遵循這些原則和做法，否則日後必須耗費更多心力和成本來改造架構。
- 每項服務都應該有自己的資料庫結構定義。無論您使用的是關聯資料庫還是 NoSQL 解決方案，每項服務都必須有自己的結構定義，而且其他服務無法存取。當多項服務對相同的結構定義通訊時，服務之間就會隨著時間在資料庫層彼此緊耦合。這些依附關係會阻礙服務單獨測試及部署，因此較難變更，且有更多部署風險。
- 服務只能透過其公用 API 在網路進行通訊。所有服務都應透過公用 API 公開行為，且服務只能透過這些 API 相互通訊。不應有「後門」存取權，或是直接與其他服務資料庫通訊的服務。這樣可以避免服務緊耦合，並確保服務間通訊使用妥善記錄且受支援的 API。
- 服務應為其用戶端提供回溯相容性。建構並營運服務的團隊，必須確保服務更新不會中斷客戶的體驗。也就是說，您必須規劃 API 版本管理並測試回溯相容性，這樣才不會在發布新版本時中斷現有客戶的體驗。團隊可使用初期測試版本驗證回溯相容性。 此外，這也表示您必須使用藍綠部署或階段推出等方式，確保部署作業不會造成停機。
- 在開發工作站上建立執行服務的標準做法。開發人員必須能按需求，使用單一指令在開發工作站上建立實際執行環境中任何一部分的服務。服務的虛設常式版本也應該能夠按需求執行。為了協助您，許多雲端服務供應商都提供雲端服務的模擬版本，請務必使用。這麼做的目標是讓開發人員能在本機上輕鬆測試服務並偵錯。
- 投入資源來監控及觀察實際執行環境。實際執行環境的許多問題屬於突發問題，且原因出自多個服務之間的互動，這類問題包括效能問題。我們的研究顯示，擁有一項能回報系統整體健康狀態 (例如系統是否正在運作？系統是否有足夠資源可用？) 的解決方案相當重要，而且團隊須能存取可協助他們進行以下事務的工具和資料：追蹤、瞭解並診斷實際執行環境中的基礎架構問題，包括服務之間的互動。
- 為您的服務設定服務等級目標 (SLO)，並定期執行災難復原測試。為您的服務設定服務等級目標將會設立效能的預期目標，並協助您規劃系統在服務停止運作時的行為機制 (建構可恢復運作的分散式系統時的關鍵考量)。使用受控管的失敗干擾等技術，作為災難復原測試計畫的一部分，來測試實際工作環境系統在現實生活中的行為。DORA 的研究顯示，採用這類方法進行災難復原測試的機構，更有可能提供更高的服務可用性。您越早開始改善這項功能越好，以便將這類重要活動正規化。
有很多事項需要考量，因此與擁有能力測試這些實作構想的團隊合作進行這類前測，相當重要。不論成功或失敗，關鍵在於您必須從這些團隊汲取經驗，並在將新的架構模式延伸至整個機構時善加運用。
我們的研究指出，成功的公司會採取概念驗證，並透過建立實務做法社群等方式，為團隊提供學習機會。您可以提供時間、空間和資源，讓來自不同團隊的人員定期會面及交流想法。每個人也需要學習新的技能和技術。因此請編列預算投資您的員工，讓他們透過購買書籍、參加訓練課程及出席會議來成長。您還可以提供基本設施/平台並安排時間，讓員工透過公司郵寄清單、知識庫和現場聚會互相分享機構知識和各種不錯的做法。
參考架構
在這節中，我們將根據下列準則說明參考架構：
- 使用容器處理實際執行環境服務，並使用 Cloud Run 或 Kubernetes 等容器排程器進行自動化調度管理
- 建立有效的持續整合/持續推送軟體更新管道
- 著重安全性
將實際工作環境服務容器化
容器管理和自動化調度管理服務是容器化雲端應用程式的基礎。過去以來有各式各樣的這類服務問世，不過現今的主流服務為 Kubernetes。Kubernetes 現在為產業的容器自動化調度管理制定了標準、託管活躍的社群，並獲得許多頂尖商業廠商的支持。圖 4 統整了 Kubernetes 叢集的邏輯結構。
Kubernetes 會定義一項稱為 Pod 的抽象化機制。每個 Pod 通常只包含一個容器，如圖 4 的 Pod A 和 Pod B，但也可能包含多個容器，如 Pod C。每項 Kubernetes Service 會執行一個包含數個節點的叢集，每個叢集通常代表一個虛擬機器 (VM)。圖 4 僅顯示四個 VM，不過實際上一個叢集就可能包含超過一百個 VM。將 Pod 部署於某個 Kubernetes 叢集上時，Service 會判斷 Pod 的容器應在哪些 VM 中執行。由於容器會指定需要的資源，因此 Kubernetes 可以準確選擇要將哪些 Pod 指派到每個 VM。
Pod 的部署資訊部分是表示 Pod 應執行的執行個體數量 (備用資源數量)。接著，Kubernetes 服務會建立許多 Pod 容器的執行個體，並指派給 VM。以圖 4 為例，Pod A 的部署要求提供三個備用資源，Pod C 的部署也是如此。不過，Pod B 的部署要求了四個備用資源，因此此範例叢集含有容器 2 的四個執行中執行個體。如圖所示，如果 Pod 有多個容器 (例如 Pod C)，其容器一律會指派給同一個節點。
Kubernetes 同時也提供其他服務，包括：
- 監控執行中的 Pod：如果容器失敗，服務就會啟動新的執行個體。這可確保在 Pod 部署中要求的所有備用資源仍可使用。
- 負載平衡流量：將每個 Pod 的智慧型要求，分散到容器的備用資源中。
- 自動推出新容器，完全不需要停機，新執行個體會逐漸取代現有執行個體，直到新版本完成部署為止。
- 自動調度資源：叢集會視需求自行新增或刪除 VM。
建立有效的持續整合/持續推送軟體更新管道
重構單體式應用程式有一些優點，例如成本較低、直接擷取在 Kubernetes 上執行的流量。不過，最重要的優點之一是能夠提高更新應用程式的頻率，這點只有變更軟體的建構及發布方式才可能做到。要獲得這項優勢，您必須在機構中打造有效率的持續整合/持續推送軟體更新 (CI/CD) 管道。
持續整合需要自動化建構和測試工作流程，才能為開發人員提供快速的意見回饋。該團隊要求所有使用相同程式碼的小組成員 (例如單一服務的程式碼) 都必須定期將他們的工作整合到共用的主線或主幹中。這項整合至少每天會對開發人員進行一次，而且每次整合都是由包含自動測試的建構程序進行驗證。持續推送軟體更新主要是透過自動化建構、測試和部署程序，讓這類整合程式碼部署作業變得快速且低風險，進而能夠持續執行效能、安全性和探索測試等活動。簡而言之，持續整合可協助開發人員快速偵測整合問題，而持續推送軟體更新則讓部署作業更例行可靠。
為了清楚瞭解原因，建議您查看具體範例。圖 5 說明持續整合/持續推送軟體更新管道如何針對在 Google Kubernetes Engine 中運作的容器，使用 Google 工具。
將這個流程分成兩個區塊來看很清楚，如圖 6 所示：
| 本機開發 | 遠端開發 |
| 我們的目標是加快內部開發迴圈，並讓開發人員能夠取得工具，快速取得有關本機程式碼變更的影響的意見回饋。包括支援程式碼檢查、自動執行 YAML，以及加快本機建構作業。 | 提交提取要求 (PR) 時，遠端開發迴圈會隨即啟動。我們的目標是大幅減少透過持續整合驗證及測試 PR 與執行其他活動 (例如安全漏洞掃描和二進位簽署) 的時間，同時以自動化的方式推動版本核准。 |
Google Cloud 工具可在此程序中協助您進行以下作業：
本機開發：如果想讓開發人員提高工作效率，使用本機應用程式開發作業至關重要。這種本機開發作業需要建構可部署至本機和遠端叢集的應用程式。將變更修訂至 GitHub 等原始碼控制管理系統前，如果您的本機開發迴圈相當快速，即可確保開發人員能夠測試變更，並將變更部署至本機叢集。
為此，Google Cloud 提供 Cloud Code。Cloud Code 提供 IDE 的擴充功能，例如 Visual Studio Code 和 Intellij，可讓開發人員快速在 Kubernetes 上疊代、偵錯及執行程式碼。Cloud Code 會在後端使用 Skaffold、Jib 和 Kubectl 等熱門工具，持續為開發人員針對程式碼提供即時意見回饋。
持續整合：透過全新的 Cloud Build GitHub 應用程式，團隊可以直接從 GitHub 針對不同的存放區事件 (包括提取要求、分支版本或標記) 觸發建構作業。Cloud Build 是一個完全無伺服器的平台，可根據負載量增減資源配置，完全不需要預先佈建伺服器，或提前購買額外容量。透過 GitHub 應用程式觸發的自動建構觸發作業可將狀態自動張貼回 GitHub。這些意見回饋可直接整合至 GitHub 開發人員工作流程，減少結構定義切換。
構件管理：Container Registry 可讓您的團隊透過單一位置集中管理 Docker 映像檔、執行安全漏洞掃描，以及透過精細的存取權控管機制決定誰能夠存取哪些內容。Cloud Build 已與安全漏洞掃描功能整合，當開發人員透過 Cloud Build 建立映像檔並儲存至 Container Registry 時，就能立即識別安全性威脅。
持續推送軟體更新：Cloud Build 可使用建構步驟，定義要在建構、測試和部署期間執行的特定步驟。例如，在建立新容器並推送至 Container Registry 之後，後續的建構步驟可以將這個容器以及相關設定和政策部署至 Google Kubernetes Engine (GKE) 或 Cloud Run。如果您採用多雲端策略，也可以部署至其他雲端服務供應商。最後，如果您是想追求 GitOps 樣式的持續推送軟體更新功能，則可透過 Cloud Build 以儲存在 Git 存放區的檔案 (例如 Kubernetes 資訊清單) 宣告部署作業。
然而，部署程式碼並不是整個程序的終點。 機構也必須在執行程式碼時加以管理。為了做到這點，Google Cloud 為營運團隊提供多種工具，例如 Cloud Monitoring 和 Cloud Logging。
不過，GKE 並不需要使用 Google 的持續整合/持續推送軟體更新工具，如有需要，您也可以免費使用替代工具鏈。相關範例包括使用 Jenkins 進行持續整合/持續推送軟體更新，以及透過 Artifactory 管理構件。
如果您與大多數使用 VM 型雲端應用程式的機構一樣，那麼您現在可能缺少一個順暢運作的 CI/CD 系統。要從重新建立應用程式架構中獲得好處，設置 CI/CD 系統是一大關鍵，但這需要投入大量心力。基於 Kubernetes 已發展成熟以及其他原因，如今您可以運用所需的各種技術來建立管道。不過，人員方面的變化可能相當重大。 您的推送團隊必須具備開發、測試和營運技能，成為跨部門的團隊。改變文化需要時間，因此請做好準備，投入心力來改變員工的認知和行為，讓他們逐漸適應 CI/CD 的世界。
著重安全性
將單體式應用程式重新建立為雲端原生模式，可說是一項大改造。在轉換過程中，自然也會有需要處理的新安全性難題。最重要的兩大難題為：
- 保護容器之間的存取作業
- 確保軟體供應鏈的安全
其中第一項難題源自一個明顯的事實：將應用程式拆分成數個容器化服務 (也許還有微服務) 時，就需要為這些服務設定通訊方式。即使這些服務可能全都在同一 Kubernetes 叢集上執行，還是必須顧慮服務之間的存取權控管機制。畢竟，其他應用程式可能會共用該 Kubernetes 叢集，您不能讓其他應用程式任意使用您的容器。
控管容器存取權時，您需要驗證其呼叫端，然後決定其他容器有權提出哪 17 項要求。如今，解決這個問題 (及其他數個問題) 的常見方式為使用服務網格。Istio 就屬於這類服務網格的代表範例，Istio 是由 Google、IBM 等廠商建立的開放原始碼專案。圖 7 顯示 Istio 在 Kubernetes 叢集中的位置。
如圖片所示，Istio Proxy 會攔截應用程式中所有容器之間的流量。服務網格可藉此提供多項實用服務，而且不會對應用程式的程式碼進行任何變更。這些服務包括：
- 安全性：同時提供使用傳輸層安全標準 (TLS) 服務對服務驗證和使用者驗證
- 流量管理：可讓您控制要求在應用程式中的容器之間轉送的方式
- 觀測能力，擷取容器之間的通訊記錄檔和指標
Google Cloud 可讓您將 Istio 新增至 GKE 叢集。即使您的雲端應用程式不需使用服務網格，對此相當瞭解的客戶還是會詢問您的安全性水準是否與 Istio 相當，這很正常。客戶相當在乎安全性，而且對於以容器為基礎的環境而言，Istio 是提供安全性的重要元素。
除了支援開放原始碼 Istio 之外，Google Cloud 也提供 Traffic Director，這是 Google Cloud 全代管的服務網格控制層，可跨多個區域的叢集和 VM 執行個體提供全域負載平衡，並提供來自 Service Proxy 的卸載健康狀態檢查、精細的流量管理和上述其他功能。
Traffic Director 有一項獨特功能是自動為網格中的微服務進行跨區域容錯移轉和溢位 (如圖 8 所示)。
您在服務網格中，可以透過這項功能將服務的全域彈性與安全性相結合。
Traffic Director 提供多項流量管理功能，可協助提升服務網格的安全狀態。舉例來說，您可以將流量鏡像功能輕鬆設為政策，來允許影子應用程式接收應用程式主版本處理的實際流量副本，如圖 9 所示。影子服務收到的副本回應經過處理後，系統會捨棄這些回應。流量鏡像是一項功能強大的工具，可在不影響或觸及實際執行環境流量的情況下，測試是否有安全性異常狀況，並對流量偵錯。
不過，重構應用程式所帶來的新安全性難題不只有保護容器之間的互動，另一個顧慮是確保您執行的容器映像檔值得信任。如要做到這點，您必須確認軟體供應鏈內建安性與法規遵循機制。
要確認軟體供應鏈內建安性與法規遵循機制，您需要實施兩大機制 (如圖 10 所示)：
安全漏洞掃描：當容器由 Cloud Build 建構並儲存在 Container Registry 中，您可以透過 Container Registry 安全漏洞掃描功能，快速瞭解潛在威脅並找出問題。這項功能可直接在應用程式開發過程中找出 Ubuntu、Debian 和 Alpine 的套件安全漏洞，並同時支援 CentOS 和 RHEL，不僅可避免因效率不彰而需支付高額成本的情形，還能縮短已知安全漏洞的修復時間。
二進位授權：您可以整合二進位授權與 Container Registry 安全漏洞掃描功能，根據安全漏洞掃描結果為部署作業把關，做為整體部署政策的一環。二進位授權是用於部署期間的安全性控管機制，不需要任何人為介入，即可確保只有受信任的容器映像檔會部署在 GKE 上。
使用服務網格來保護容器之間的存取權，並確保安全的軟體供應鏈是建立安全容器型應用程式的重要環節。還有很多功能，包括驗證您用來進行建構的雲端平台基礎架構的安全性。但最重要的是，瞭解從單體式應用程式遷移到現代化的雲端原生模式，將帶來新的安全性挑戰。如要成功完成轉換作業，您需要先瞭解相關知識，然後針對每項轉換建立具體的方案。
開始使用
請勿將遷移至雲端原生架構當做多年的大型專案使用。
首先，請改為尋找具備進行概念驗證所需之能力和專業知識的團隊，或者尋找已進行過概念驗證的團隊。然後，汲取團隊經驗並應用到整個機構。讓團隊採用 strangler fig 模式，以漸進、疊代的方式將服務遷移至雲端原生架構，同時持續推送新功能。
想要成功邁向成功，關鍵在於團隊擁有能力、資源和權力，才能讓改善系統架構成為日常工作的一部分。根據先前提供的六項架構結果，為新工作設定明確的架構目標，並讓團隊自由決定如何達成計畫。
最重要的就是，立即開始行動！ 提高團隊工作效率和靈活度，以及加強服務安全性和穩定性，這些事項對於機構邁向成功的重要性，將更甚以往。能自律地將實驗和改善作業融入日常工作的團隊，往往成效最佳。
Google 發明的 Kubernetes 是以我們過去幾年使用的內部軟體為基礎所開發，這也是我們在雲端原生技術上擁有最深厚經驗的理由。
Google Cloud 非常重視容器化應用程式，這點從我們的 CI/CD 和安全性產品即可看出。事實上，Google Cloud 是現今容器化應用程式支援的領導者。
請參閱 cloud.google.com/devops，使用我們的「快速檢驗」工具，瞭解自己的執行狀況並取得如何進行的相關建議，包括實作本白皮書所討論的模式，例如鬆耦合的架構。
許多 Google Cloud 合作夥伴已協助像貴公司一樣的機構成功完成這類轉換。我們能為您介紹經驗豐富的嚮導，讓您不必自己探索如何重新建構架構。
如要開始使用，請與我們聯絡，以便安排與 Google 解決方案架構師的會談。我們會協助您瞭解相關變更以及進行作業。
延伸閱讀
https://cloud.google.com/devops - 開發運作狀態六年報告，提供一系列文章，深入探討預測軟體推送效能的功能，以及可協助您瞭解自己的執行狀況與如何改善的快速檢驗功能。
Zhamak Dehghani 撰寫的「How to break a Monolith into Microservices: What to decouple and when」(如何將單體拆分為微服務：如何以及何時分離)
Martin Fowler 撰寫的「Microservices: a definition of this new architectural term」(微服務：這項新架構詞彙的定義)
Martin Fowler 撰寫的「Strangler Fig Application」(Strangler Fig 應用程式)