以雲端原生方式重新建立架構

許多公司會使用單體架構來建構自己特別打造的軟體服務， 這種做法的好處是單體系統相當易於設計及部署，至少一開始是如此。不過，隨著應用程式趨於複雜，開發人員工作效率和部署速度將難以維持一貫的水準，導致系統變更不僅耗時且所費不貲，還有部署風險。

隨著服務以及負責服務的團隊成長，服務往往會變得越來越複雜，也更難以改良及運作。 測試和部署變得更困難，加入新功能變得更棘手，維護穩定性和可用性也可能是一大挑戰。

Google 的 DORA 團隊研究結果顯示，不同規模和領域的機構，都可以達到相當高的軟體推送處理量、服務穩定性和可用性。高成效團隊每天可以完成多次部署作業、不到一天即可將異動內容推送至實際執行環境、在一小時內還原服務，並將變更失敗率維持在 0 至 15% 之間。¹

此外，從每位開發人員的每日部署項目進行評估，可發現高成效團隊也能讓開發人員達到更高的工作效率，即使團隊規模增加也沒問題。 這點顯示於圖 1。

這份白皮書接下來的部分會說明如何將應用程式遷移至現代雲端原生模式，協助您達到這些成果。如實行這份白皮書所述的技術做法，您可達成下列目標：

• 提高開發人員工作效率，即使團隊規模擴大也不成問題。
• 加快上市時間：更快新增功能並修正瑕疵。
• 提高可用性：增加軟體運作時間、降低部署失敗率，並在事件發生時縮短還原時間。
• 強化安全性：減少應用程式的受攻擊面，並更輕鬆地快速偵測及回應攻擊和新發現的安全漏洞。
• 提高擴充性：雲端原生平台與應用程式可輕鬆視需求橫向調度資源，並縮減資源配置。
• 降低成本：簡化軟體推送程序可降低推送新功能的成本，有效利用雲端平台可大幅降低服務的營運成本。

¹ 根據以下四項重要指標，瞭解團隊的表現：https://cloud.google.com/devops/

單體式應用程式必須以單一單元的形式建構、測試及部署。 一般來說，每個應用程式的作業系統、中介軟體和語言堆疊，都是專為該應用程式量身打造或特別設定， 通常也會有專屬的建構、測試、部署指令碼和程序。 就綠地應用程式而言，團隊能以簡單有效的方式執行這些程序。然而，隨著應用程式成長，變更、測試、部署及運作此類系統的難度也會隨之提高。

此外，隨著系統不斷成長，建構、測試、部署及營運該服務的團隊，其規模和複雜度也會跟著增加。 一種常見但有問題的做法是依機能切分團隊，但這會使團隊之間必須交接，並增加前置時間和批次規模，導致團隊必須進行大量的重工。DORA 的研究顯示，高成效團隊在單一跨部門團隊中開發及推送軟體的可能性是兩倍。

這個問題的現象有：

• 建構程序冗長且經常失敗
• 整合及測試週期頻率低
• 建構及測試程序的支援作業增加
• 開發人員工作效率下滑
• 必須排定停機時間來執行數小時的部署程序，整個過程相當耗時費力
• 需要耗費大量心力管理測試和實際執行環境的設定

相較之下，在雲端原生模式中³：

• 複雜的系統會拆解為可在容器化執行階段單獨測試及部署的服務 (微服務或服務導向架構)
• 應用程式使用標準平台提供的服務，例如資料庫管理系統 (DBMS)、blob 儲存空間、訊息傳遞、內容傳遞聯播網 (CDN) 和安全資料傳輸層 (SSL) 終止
• 標準化雲端平台可妥善解決許多作業問題，例如部署、自動調度資源、設定、密鑰管理、監控和快訊。 應用程式開發團隊可視需求存取這些服務
• 為應用程式開發人員提供標準化的作業系統、中介軟體和語言專屬堆疊，且這些堆疊的維護和修補作業均由平台供應商或另一個團隊以頻外方式執行
• 單一跨部門團隊可全程負責每項服務的軟體推送生命週期。

³ 這個部分並非「雲端原生」意義的完整說明。如要參閱詳細瞭解一些雲端原生架構的原則，請造訪以下網址：https://cloud.google.com/blog/products/application-development/5-principles-for-cloud-native-architecture-what-it-is-and-how-to-master-it。

這個模式可帶來許多優勢：

不過，使用雲端原生模式時需考量以下優缺點：

• 現在所有應用程式都屬於分散式系統，會在作業過程中產生大量遠端呼叫。 因此，務必仔細思考如何處理網路故障和效能問題，以及如何對實際執行環境中的問題進行偵錯。
• 開發人員必須使用平台提供的標準化作業系統、中介軟體和應用程式堆疊，導致本機開發作業更困難。
• 架構師必須採用事件導向的系統設計方法，包括使用最終一致性模式。

許多機構採用「lift-and-shift」的方式將服務遷移至雲端。這種做法只需對系統進行小程度的異動，雲端基本上做為傳統資料中心使用，但比傳統資料中心提供更佳的 API、服務和管理工具。不過，隨即轉移本身並不會帶來前述任何雲端原生模式具備的優勢。

許多機構都顧慮到將應用程式遷移至雲端原生架構的成本和複雜性，而猶豫是否採用隨即轉移方式，這需要重新思考應用程式架構和實際執行環境作業等所有層面，以及整個軟體推送生命週期。這種擔憂十分合理：許多大型機構都有進行為期多年的「同時全面執行」式平台更換作業，但最後失敗的慘痛經驗。

解決方法是採用漸進式、反覆式且不斷進化的方法，將系統重新建構為雲端原生架構，讓團隊瞭解如何在這個新模式中有效工作，同時持續交付新功能。我們將這種方式稱為「遷移與改善」。

演進架構中的關鍵模式稱為 strangler fig 應用程式⁴。與其從頭徹底重新編寫系統，不如改為以現代化的雲端原生樣式編寫新功能，但讓應用程式與原有的單體式應用程式相互使用，以維持現有的功能。視需要隨時間逐步移轉現有功能，以符合新服務的概念完整性，如圖 2 所示。

⁴相關說明請參閱 https://martinfowler.com/bliki/StranglerFigApplication.html

第一，從快速推送新功能著手，而不是重現既有功能。重點是您能夠多快開始使用新服務推送新功能。實際在這種模式下工作，才能迅速瞭解並交流從中獲得的良好做法。 請大幅縮減作業範圍，將目標設為在數週內推送項目給使用者，而不是數月內。

第二，以雲端原生方式設計。也就是說，請使用雲端平台的原生服務，例如 DBMS、訊息傳遞、CDN、網路、blob 儲存空間等，同時盡可能使用平台提供的標準化應用程式堆疊。 您應將服務容器化、盡可能使用無伺服器模式，並使建構、測試和部署程序全面自動化。 此外，所有應用程式都應使用平台提供的共用服務來進行記錄、監控及傳送快訊。 (值得注意的是，這種平台架構可有效部署至任何多用戶群應用程式平台，包括裸機地端部署環境。) 雲端原生平台的整體架構圖如下方圖 3 所示。

最後，請以「讓不同團隊能獨立自主運作」為設計目的，使各團隊可測試及部署自己的服務。我們的研究顯示，最重要的架構結果是軟體推送團隊對這六個問題的答案是否為「是」：

• 我們可以自行大幅變更系統設計，不需經過團隊外部人員許可
• 我們可以自行大幅變更系統設計，不必依賴其他團隊變更其系統，或帶給其他團隊大量作業
• 我們不必與團隊外部人員溝通協調，即可完成工作
• 無論依附的相關服務為何，我們都能視需求部署及發布產品或服務
• 我們不需要整合的測試環境，即可視需求執行大部分的測試作業
• 我們可在正常的營業時間內執行部署作業，而且幾乎不會停機

請定期確認團隊是否朝這些目標努力，並以達成目標為首要之務。 這通常包括重新思考機構和企業架構。

具體來說，重點就是組織團隊，讓建構、測試及部署軟體所需的各種職務 (包含產品經理) 都能一起合作，並使用現代化的產品管理做法來建構及改進他們處理的服務。 這不需更動組織架構， 只要讓這些人員以團隊形式每天一起合作 (可能的話也讓他們共用一個實體空間)，就能對工作效率帶來明顯影響，不必讓開發人員、測試人員和發布團隊獨立運作。

我們的研究顯示，團隊對於這些敘述的同意程度，可相當準確預示高軟體效能，亦即每天提供數項穩定且可用性高的服務。因此，即使團隊數量增加，高成效團隊也能提高開發人員的工作效率 (以每日每位開發人員的部署作業數量衡量)。

採用微服務或服務導向的架構時，請務必遵循相關重要原則和做法。 最好一開始就嚴格遵循這些原則和做法，否則日後必須耗費更多心力和成本來改造架構。

• 每項服務都應該有自己的資料庫結構定義。 無論您使用的是關聯式資料庫還是 NoSQL 解決方案，每項服務都必須有其他服務無法存取的專屬結構定義。當多項服務對相同的結構定義通訊時，這些服務一段時間後就會在資料庫層彼此緊耦合。 這些依附關係會讓服務無法單獨測試及部署，因此較難變更，且有更多部署風險。
• 服務只能透過其公用 API 在網路進行通訊。所有服務都應透過公用 API 公開行為，且服務只能透過這些 API 相互通訊， 不應有「後門」存取權，或是直接與其他服務資料庫通訊的服務。 這樣可以避免服務緊耦合，並確保服務間通訊使用妥善記錄且受支援的 API。
• 服務應為其用戶端提供回溯相容性。 建構並營運服務的團隊，必須確保服務更新不會中斷客戶的體驗。 也就是說，您必須規劃 API 版本管理並測試回溯相容性，這樣才不會在發布新版本時中斷現有客戶的體驗。 團隊可使用初期測試版本驗證回溯相容性。 此外，這也表示您必須使用藍綠部署或階段推出等方式，確保部署作業不會造成停機。
• 在開發工作站上建立執行服務的標準做法。開發人員必須能按需求，使用單一指令在開發工作站上建立實際執行環境中任何一部分的服務。服務的虛設常式版本也應該能夠按需求執行。為了協助您，許多雲端服務供應商都提供雲端服務的模擬版本，請務必使用。 這麼做的目標是讓開發人員能在本機上輕鬆測試服務並偵錯。
• 投入資源來監控及觀察實際執行環境。實際執行環境的許多問題屬於突發問題，且原因出自多個服務之間的互動，這類問題包括效能問題。我們的研究顯示，擁有一項能回報系統整體健康狀態 (例如系統是否正在運作？系統是否有足夠資源可用？) 的解決方案相當重要，而且團隊須能存取可協助他們進行以下事務的工具和資料：追蹤、瞭解並診斷實際執行環境中的基礎架構問題，包括服務之間的互動。
• 為您的服務設定服務等級目標 (SLO)，並定期執行災難復原測試。 為服務設定服務等級目標將會設立效能的預期目標，並協助您規劃系統在服務停止運作時的行為機制 (這是建構彈性分散式系統時的關鍵考量)。在災難復原測試計畫中使用受控管的錯誤植入等技術，以測試實際執行環境系統在現實世界中的行為。DORA 的研究顯示，採用這類方法進行災難復原測試的機構，更有可能提供更高的服務可用性。 越早開始測試越好，這樣您才可將這類重要活動正規化。

上面列出的考量事項相當多，因此請務必與有能力實驗及實作這些構想的團隊合作進行這類前測。 不論成功或失敗，關鍵在於您必須從這些團隊汲取經驗，並在將新的架構模式逐步擴大至整個機構時，善加運用這些團隊。

我們的研究指出，成功的公司會採取概念驗證，並透過建立實務做法社群等方式，為團隊提供學習機會。您可以提供時間、空間和資源，讓來自不同團隊的人員定期會面及交流想法。 每個人也需要學習新的技能和技術。 因此請編列預算投資您的員工，讓他們透過購買書籍、參加訓練課程及出席會議來成長。 您還可以提供基本設施/平台並安排時間，讓員工透過公司郵寄清單、知識庫和現場聚會互相分享機構知識和各種不錯的做法。

在這節中，我們將根據下列準則說明參考架構：

• 使用容器處理實際執行環境服務，並使用 Cloud Run 或 Kubernetes 等容器排程器進行自動化調度管理
• 建立有效的 CI/CD 管道
• 著重安全性

容器管理和自動化調度管理服務是容器化雲端應用程式的基礎。 過去以來有各式各樣的這類服務問世，不過現今的主流服務為 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 的 Deployment 資訊中會指出 Pod 應執行的執行個體數量 (備用資源數量)。 接著，Kubernetes Service 會建立許多 Pod 容器的執行個體，並指派給 VM。 以圖 4 為例，Pod A 的 Deployment 要求提供三個備用資源，Pod C 的 Deployment 也是如此。 不過，Pod B 的 Deployment 要求了四個備用資源，因此這個範例叢集含有容器 2 的四個執行中執行個體。 如圖所示，如果 Pod 有多個容器 (例如 Pod C)，其容器一律會指派給同一個節點。

Kubernetes 同時也提供其他服務，包括：

• 監控執行中的 Pod：如果容器故障，Service 就會啟動新的執行個體。這可確保 Pod Deployment 中要求的所有備用資源維持可用狀態。
• 流量負載平衡：將每個 Pod 的要求，以智慧方式分散到容器的備用資源中。
• 自動推出新容器，完全不需要停機：新執行個體會逐漸取代現有執行個體，直到新版本完成部署為止。
• 自動調度資源：叢集會視需求自行新增或刪除 VM。

重構單體式應用程式有一些優點，例如成本較低、直接擷取在 Kubernetes 上執行的流量。 不過，最重要的優點之一是能夠提高更新應用程式的頻率，這點只有變更軟體的建構及發布方式才可能做到。 要獲得這項優勢，您必須在機構中打造有效率的持續整合/持續推送軟體更新 (CI/CD) 管道。

想要持續整合 (CI)，則需要有可快速為開發人員提供意見回饋的自動化建構和測試工作流程。所有處理相同程式碼 (例如單一服務的程式碼) 的團隊成員都必須定期將自己的工作內容整合到共用的主線或主幹中。 每位開發人員應至少每天進行一次這樣的整合，而且每次整合都是由包含自動測試的建構程序進行驗證。 持續推送軟體更新 (CD) 主要是透過自動化建構、測試和部署程序，讓這類整合程式碼的部署作業速度加快且風險低，這樣才能持續執行效能、安全性和探索測試等活動。簡單來說，CI　可協助開發人員快速偵測整合問題，CD　則讓部署作業定期進行，且變得可靠。

為了清楚瞭解原因，建議您查看具體範例。 圖 5 顯示如果針對在 Google Kubernetes Engine 中執行的容器使用 Google 工具，CI/CD 管道可能會呈現的樣子。

將這個流程分成兩個區塊 (如圖 6 所示) 來考量相當有幫助：

本機開發：確保開發人員以高效率開發本機應用程式相當重要。這種本機開發作業需要建構可部署至本機和遠端叢集的應用程式。 將變更修訂至 GitHub 等原始碼控制管理系統前，如果您的本機開發迴圈相當快速，即可確保開發人員能夠測試變更，並將變更部署至本機叢集。

為此，Google Cloud 提供 Cloud Code。 Cloud Code 提供 Visual Studio Code 和 Intellij 等 IDE 的擴充功能，可讓開發人員快速在 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。

不過，Google 的 CI/CD 工具並非使用 GKE 的必要工具。如有需要，您也可以使用替代工具鏈。 相關範例包括透過 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 - 提供六年的《開發運作現狀報告》，這系列文章深入探討軟體推送效能的預測功能，並能快速檢驗您的現狀及建議改善方式。

《Site Reliability Engineering: How Google Runs Production Systems》(網站穩定性工程：Google 如何經營實際工作環境系統)，O'Reilly　出版，2016 年

《The Site Reliability Workbook: Practical Ways to Implement SRE》(網站穩定性手冊：導入 SRE 的實用方法)，O'Reilly　出版，2018 年

《Building Secure & Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems》(建構安全可靠的系統：設計、導入與維護系統的最佳做法)，O’Reilly　出版，2020 年

《How to break a Monolith into Microservices: What to decouple and when》(如何將單體拆分為微服務：分離項目與時機)，Zhamak Dehghani

《Microservices: a definition of this new architectural term》(微服務：這項新架構字詞的定義)，Martin Fowler

《Strangler Fig Application》(Strangler Fig 應用程式)，Martin Fowler