請停下您手上的工作，要求同事定義「雲端原生」一詞。 運氣好的話，您會收穫數個不同的答案。
讓我們從簡單的定義開始：
雲端原生架構和技術是設計、建構及操作工作負載的方法，這些工作負載建置在雲端，可充分利用雲端運算模型。
Cloud Native Computing Foundation 的官方定義：
雲端原生技術可讓組織在現代化的動態環境中，建置並執行可擴縮的應用程式，例如公用、私人和混合式雲端。 容器、服務網格、微服務、不可變的基礎結構，以及宣告式 API 皆為此方法範例。
這些技術可啟用富彈性、可管理且可觀察的鬆散結合系統。 與健全的自動化結合，可讓工程師以頻繁且可預測的方式，用最少的心力建立影響巨大的變更。
雲端原生關乎速度和靈活度。 商務系統不斷演進，從實現企業的能力到策略性轉型的武器，加快企業成長的速度。 立即掌握市場新思維至關重要。
同時，商務系統也會隨著使用者要求增多而變得更複雜。 他們期待快速回應、創新功能和零停機時間。 無法再接受效能問題、一再發生的錯誤，以及無法快速移轉。 您的使用者會倒戈支持您的競爭對手。 雲端原生系統的設計要點為快速變更、大規模和復原能力。
以下是已實作雲端原生技術的一些公司。 想想其已達到的速度、靈活度和可擴縮性。
| Company | 體驗 |
|---|---|
| Netflix | 實際執行環境中有 600 多項服務。 每天部署 100 次。 |
| Uber | 實際執行環境中有 1,000 多項服務。 每週部署數千次。 |
| 實際執行環境中有 3,000 多項服務。 每天部署 1,000 次。 |
如您所見，Netflix、Uber 和 WeChat 公開了由許多獨立服務組成的雲端原生系統。 此種架構形態讓他們得以快速回應市場狀況。 其可立即更新小區域的即時、複雜應用程式，而不需要全面重新部署。 可視需要擴縮個別服務。
雲端原生的要素
雲端原生的快速靈活有很多因素。 最重要的是雲端基礎結構。 但還有更多：圖 1-3 顯示的其他五項基礎要素，也是雲端原生系統的基石。
圖 1-3。 雲端原生基礎要素
讓我們花一些時間詳細了解每個要素的重要性。
雲端
雲端原生系統充分利用雲端服務模型。
這些系統旨在動態、虛擬化的雲端環境中成長，廣泛運用平台即服務 (PaaS) 計算基礎結構和受控服務。 其視基礎結構為可透過自動化處置的的項目 - 佈建即需幾分鐘，並可視需要調整、擴縮或終結。
想想我們對待寵物和商品之間的差異。 在傳統資料中心，伺服器被視為寵物：實體機器、指定有意義的名稱，並受到照料。 您可以藉由將更多資源新增至同一部機器來調整規模 (相應增加)。 如果伺服器出現故障，你需要將其維護回復健康。 如果伺服器無法使用，則每個人都會注意到。
商品服務模型則不同。 您會將每個執行個體佈建為虛擬機器或容器。 它們是完全相同的，並被指派了系統識別碼，如 Service-01、Service-02 等。 您可以藉由建立更多執行個體來調整 (向外延展)。 當執行個體無法使用時，沒有人會注意到。
商品模型採用不可變的基礎結構。 伺服器不會修復或修改。 如果一個伺服器故障或需要更新，它會終結並佈建新的伺服器，全部都透過自動化完成。
雲端原生系統採用商品服務模型。 它們會隨著基礎結構相應縮小或向外延展而繼續執行，不論其所執行的機器為何。
Azure 雲端平台支援這種類型的高度彈性基礎結構，具有自動調整、自我修復和監視功能。
新式設計
您要如何設計雲端原生應用程式？ 您希望架構看起來是什麼樣？ 您想要遵守哪些原則、模式和最佳做法？ 哪些基礎結構和作業考慮很重要？
十二要素應用方法
建構雲端應用程式最廣為大眾接受的方法是十二要素應用方法 (英文)。 這是開發人員為建構針對新式雲端環境最佳化的應用程式，所遵循的一套原則和做法。 特別注意跨環境和宣告式自動化的可攜性。
雖然這套方法適用於任何 Web 應用程式，但許多執行者咸認為十二要素是建置雲端原生應用程式的堅實基礎。 以這些原則為基礎所建置的系統可以快速部署和擴縮，並能新增功能以快速回應市場變遷。
下表醒目提示十二要素法：
| 係數 | 說明 |
|---|---|
| 1 - 程式碼基底 | 每項微服務的單一程式碼基底，儲存在自己的存放庫中。 利用版本控制追蹤，可以部署至多個環境 (QA、預備、實際執行)。 |
| 2 - 相依性 | 每項微服務都會隔離並封裝自己的相依性，採用變更時不會影響整個系統。 |
| 3 - 組態 | 組態資訊會移出微服務，並透過程式碼外部的組態管理工具外部化。 相同的部署可以在套用了正確組態的各環境中傳播。 |
| 4 - 支援服務 | 輔助資源 (資料存放區、快取、訊息代理程式) 應透過可定址 URL 公開。 如此可分開資源與應用程式，使其成為可交換的資源。 |
| 5 - 建置、發行、執行 | 每個版本都必須在建置、發行和執行階段之間強制進行嚴格的分隔。 每個階段都應該以唯一的識別碼標記，並支援復原功能。 新式 CI/CD 系統有助實現此原則。 |
| 6 - 處理序 | 每項微服務都應該在自己的處理序中執行，與其他執行中的服務隔離。 將支援服務所需的狀態外部化，例如分散式快取或資料存放區。 |
| 7 - 連接埠繫結 | 每項微服務都應該是獨立的，在自己的連接埠上公開自己的介面和功能。 如此可與其他微服務隔離。 |
| 8 - 並行 | 當容量需要增加時，服務會跨多個相同處理序 (複本) 水平擴增，而不是在最強大的可用電腦上擴大單一大型執行個體。 開發並行應用程式可在雲端環境中順利擴增。 |
| 9 - 可處置性 | 服務執行個體應該是可處置的。 可促成快速啟動增加可擴縮性機會，以及正常關機讓系統保持正確狀態。 Docker 容器以及協調器原本就符合這項需求。 |
| 10 - 開發/實際執行同位檢查 | 盡可能讓應用程式生命週期的所有環境保持類似，避免成本高昂的捷徑。 在此，採用容器可推動相同的執行環境，貢獻良多。 |
| 11 - 記錄 | 將微服務產生的記錄視為事件串流。 使用事件彙總工具處理它們。 將記錄資料傳播至資料採礦/記錄管理工具，例如 Azure 監視器或 Splunk，最後長期封存。 |
| 12 - 系統管理處理序 | 以一次性處理序執行系統管理/管理工作，例如資料清理或運算分析。 使用獨立工具，在實際執行環境中分別從應用程式叫用這些工作。 |
在 Beyond the Twelve-Factor App 一書中，作者 Kevin Hoffman 逐一詳細說明原始十二要素 (撰寫於 2011 年)。 此外，他還討論了三個額外因素，以反映現今的新式雲端應用程式設計。
| 新要素 | 說明 |
|---|---|
| 13 - API 優先 | 讓一切都成為服務。 假設前端用戶端、閘道或其他服務會取用您的程式碼。 |
| 14 - 遙測 | 在工作站中，您可以深入了解應用程式及其行為。 但在雲端卻不行。 請確定您的設計包含收集監視、網域特定和健康狀態/系統資料。 |
| 15 - 驗證/授權 | 從開始即實作身分識別。 請考慮在公用雲端使用 RBAC (角色型存取控制) 功能。 |
本章和本書有許多 12+ 要素相關內容。
Azure 架構完善的架構 \(部分機器翻譯\)
設計與部署雲端式工作負載十分困難，特別是在實作雲端原生架構時。 Microsoft 提供業界標準最佳做法，協助您和您的團隊交付健全的雲端解決方案。
Microsoft Well-Architected Framework 提供一組指導原則，可用以提高雲端原生工作負載的品質。 此架構包含五大架構卓越要素：
| 原則 | 描述 |
|---|---|
| 成本管理 | 專注盡早產生累加值。 套用建置-測量-學習的原則，加速上市時間並避免資本密集解決方案。 使用隨用隨付策略，在擴增時投資，而不是預先投入大量投資。 |
| 卓越營運 | 自動化環境和作業，以提高速度並減少人為錯誤。 快速回復或推進問題更新。 從一開始即實作監視和診斷。 |
| 效能效率 | 有效率地符合工作負載的需求。 促進水平擴縮 (擴增)，並將此概念設計到系統中。 持續執行效能和負載測試，以找出可能的瓶頸。 |
| 可靠性 | 建置可復原且可用的工作負載。 復原可讓工作負載從失敗中復原並繼續運作。 可用性可確保使用者隨時都能存取您的工作負載。 將應用程式設計為預期會失敗，但可從失敗中復原。 |
| 安全性 | 在應用程式從設計和實作到部署與作業整個生命週期中，都要實作安全性。 請密切注意身分識別管理、基礎結構存取、應用程式安全性以及資料主權和加密。 |
開始之前，Microsoft 提供一套線上評量，協助您根據五個架構完善的要素來評估您目前的雲端工作負載。
微服務
雲端原生系統採用微服務，這是建構新式應用程式的熱門架構形態。
微服務建置為一組分散的小型獨立服務，可透過共用網狀架構互動，有下列共同特性：
各個都在一較大的網域內容中實作特定的商務功能。
各個都是自發開發，且可獨立部署。
各個都是獨立封裝自己的資料儲存技術、相依性和程式設計平台。
各個都在自己的處理序中執行，使用 HTTP/HTTPS、gRPC、WebSockets 或 AMQP 等標準通訊協定與其他服務通訊。
所有組合在一起成為應用程式。
圖 1-4，整合型應用程式方法與微服務方法之對比。 請注意整合式方法如何由分層架構組成，此架構是在單一處理序中執行。 通常使用關聯式資料庫。 不過，微服務方法則是將功能分成多項獨立的服務，每項服務都有自己的邏輯、狀態和資料。 每項微服務都裝載自己的資料存放區。
圖 1-4。 整合式與微服務架構
請注意微服務如何推動十二要素應用方法 (英文) 的處理序原則，如本章前文所述。
要素 #6 指出「每項微服務都應該在自己的處理序中執行，與其他執行中的服務隔離。」
為何使用微服務？
微服務提供靈活度。
本章前文中，我們比較了以整合式方法與微服務方法建置的電子商務應用程式。 在此範例中，我們清楚看到了一些優點：
每項微服務都有自發的生命週期，可以獨立發展並經常部署。 您不需要等到每季版本才部署新功能或更新。 您可以小範圍更新即時應用程式，降低整個系統中斷的風險。 不需要完全重新部署應用程式，即可更新。
每項微服務都可以獨立擴縮。 您不需要將整個應用程式當成一個單位擴縮，只要擴增需要更多處理能力的服務，以符合所需的效能等級和服務等級協定。 細微擴縮可讓您提高對系統的掌控度，有利降低整體成本，因為您只擴縮部分系統，不是所有項目。
《.NET 微服務：容器化 .NET 應用程式的架構》電子書是了解微服務的絕佳參考指南。 本書深入探討微服務設計和架構。 這是完整堆疊微服務參考架構手冊，可從 Microsoft 免費下載。
開發微服務
任何新式開發平台上皆可建立微服務。
Microsoft .NET 平台是絕佳的選擇。 這是免費的開放原始碼，有許多內建功能可簡化微服務開發。 .NET 可跨平台。 您可以在 Windows、macOS 和 Linux 上建置與執行應用程式，大多數人偏好 Linux。
.NET 效能高，評分高於 Node.js 和其他競爭平台。 有趣的是，TechEmpower 主持了一場大範圍的 Web 應用程式平台和架構效能基準測試。 .NET 評分排名前 10，高於 Node.js 和其他競爭平台。
.NET 由 Microsoft 和 GitHub 的 .NET 社群維護。
微服務挑戰
雖然分散式雲端原生微服務可以提供優異的靈活度和速度，但它們帶來許多挑戰：
通訊
前端用戶端應用程式如何與後端核心微服務通訊？ 您是否允許直接通訊？ 或者，您可以提取具有彈性、控制和安全性功能之閘道外觀的後端微服務嗎？
後端核心微服務彼此如何通訊？ 您是否允許可增加結合並影響效能和靈活性的直接 HTTP 呼叫？ 或者，您會考慮使用佇列和主題技術的分離傳訊嗎？
通訊內容請參閱雲端原生通訊模式一章。
復原
微服務架構會將您的系統從內含式移至跨流程網路通訊。 在分散式架構中，當服務 B 未回應服務 A 的網路呼叫時，會發生什麼事？ 或者，當服務 C 暫時無法使用，而呼叫它的其他服務會被封鎖時，會發生什麼事？
復原功能請參閱雲端原生復原一章。
分散式資料
根據設計，每項微服務都會封裝自己的資料，並透過其公用介面公開作業。 如果是這樣，您要如何跨多項服務查詢資料或實作交易？
分散式資料內容請參閱雲端原生資料模式一章。
密碼
您的微服務如何安全地儲存及管理祕密和敏感性組態資料？
祕密內容請參閱雲端原生安全性。
使用 Dapr 管理複雜度
Dapr 是分散式的開放原始碼應用程式執行階段。 透過插入式元件架構，可大幅簡化分散式應用程式背後的管道。 其提供動態黏附，可繫結應用程式與 Dapr 執行階段預先建置的基礎結構功能和元件。 圖 1-5 顯示來自 20,000 英呎高空的 Dapr。
圖 1-5。 20,000 英呎高空上的 Dapr。
在圖的最上列中，請注意 Dapr 如何為熱門開發平台提供語言特定的 SDK。 Dapr v1 支援 .NET、Go、Node.js、Python、PHP、Java 和 JavaScript。
雖然語言特定的 SDK 可增強開發人員體驗，但 Dapr 與平台不相干。 在幕後，Dapr 的程式設計模型會透過標準 HTTP/gRPC 通訊協定公開功能。 任何程式設計平台都可以透過其原生 HTTP 和 gRPC API 呼叫 Dapr。
橫過圖中央的藍色方塊代表 Dapr 建置組塊。 每個都會公開應用程式可以使用之分散式應用程式功能的預先建置管道程式碼。
元件列代表一組大量的預先定義的基礎結構元件，可供您的應用程式取用。 您可將元件視為不需要撰寫的基礎結構程式碼。
最下一列醒目提示 Dapr 的可攜性及可任其執行的各種環境。
向前看，Dapr 可能會對雲端原生應用程式開發造成重大影響。
容器
在任何有關雲端原生的交談中都會聽到容器一詞。 在 Cloud Native Patterns 一書中，作者 Cornelia Davis 發現「容器是雲端原生軟體的絕佳推手。」Cloud Native Computing Foundation 將微服務容器化放在其雲端原生路線圖中的第一個步驟，這是企業開始其雲端原生旅程的指導。
微服務容器化簡單又直接。 程式碼、其相依性和執行階段會封裝成稱為容器映像的二進位檔。 映像會儲存在容器登錄中，作為映像的存放庫或程式庫。 登錄可以位在開發電腦、資料中心或公用雲端。 Docker 本身會透過 Docker Hub 維護公用登錄。 Azure 雲端具有私人容器登錄，可將容器映像儲存在將執行容器映像的雲端應用程式附近。
當應用程式啟動或擴縮時，您要將容器映像轉換成執行中的容器執行個體。 執行個體會在任何已安裝容器執行階段引擎的電腦上執行。 您的容器化服務的執行個體數目可視需要決定，沒有限制。
圖 1-6 顯示三項不同的微服務，每個都位在自己的容器中，全都在單一主機上執行。
圖 1-6。 在容器主機上執行的多個容器
請注意每個容器如何維護自己的相依性集合和執行階段，彼此可能不相同。 我們在這裡看到，不同版本的產品微服務在相同主機上執行。 每個容器共用基礎主機作業系統、記憶體和處理器的配量，但彼此隔離。
請注意容器模型將十二要素應用方法 (英文) 的相依性原則運用得有多好。
要素 #2 指出「每項微服務都會隔離並封裝自己的相依性，採用變更時不會影響整個系統。」
容器可同時支援 Linux 和 Windows 工作負載。 Azure 雲端開放二者皆可用。 有趣的是，Azure 中較熱門的作業系統不是 Windows Server，而是 Linux。
雖然市場上有數家容器廠商，但 Docker 穩占市佔率鰲頭。 該公司一直在推動軟體容器運動。 其已成為封裝、部署和執行雲端原生應用程式的事實標準。
為何要使用容器？
容器可在不同環境中提供可攜性並保證一致性。 將所有一切封裝成單一套件，您就可以隔離微服務及其相依性與基礎結構。
您可以在裝載 Docker 執行階段引擎的任何環境中部署容器。 容器化工作負載也可消弭使用架構、軟體程式庫和執行階段引擎預先設定每個環境的費用。
共用基礎作業系統和主機資源，容器的磁碟使用量會比完整虛擬機器小很多。 較小的大小會增加指定主機一次可執行的密度或微服務數量。
容器協調流程
雖然 Docker 之類的工具會建立映像並執行容器，但您也需要工具來管理它們。 容器管理使用稱為容器協調器的特殊軟體程式。 使用許多獨立執行的容器大規模運作時，協調流程極其重要。
圖 1-7 顯示容器協調器自動化的管理工作。
圖 1-7。 容器協調器的功能
下表說明常見的協調流程工作。
| 工作 | 說明 |
|---|---|
| 正在排程 | 自動佈建容器執行個體。 |
| 親和性/反親和性 | 將容器佈建在彼此附近或相隔遙遠，有助提高可用性和效能。 |
| 健康狀態監視 | 自動偵測並更正失敗。 |
| 容錯移轉 | 自動將故障的執行個體重新佈建到狀況良好的電腦。 |
| 調整大小 | 自動新增或移除容器執行個體以符合需求。 |
| 網路 | 管理容器通訊的網路重疊。 |
| 服務探索 | 讓容器尋找彼此。 |
| 輪流升級 | 以零停機時間部署協調累加升級。 自動回復有問題的變更。 |
請注意容器協調器如何採用十二要素應用方法 (英文) 的可處置性和並行原則。
要素 #9 指出「服務執行個體應可處置，促成快速啟動以增加可擴縮性機會，以及正常關機讓系統保持正確狀態。」Docker 容器以及協調器原本就符合這項需求。」
要素 #8 指出「服務會跨大量相同的小型處理序 (複本) 擴增，而不是在最強大的可用電腦上擴大單一大型執行個體。」
雖然有數個容器協調器，但 Kubernetes 已成為雲端原生世界的事實標準。 它是可攜、可擴充的開放原始碼平台，用於管理容器化的工作負載。
您可以裝載自己的 Kubernetes 執行個體，但接下來必須自行負責佈建及管理其資源，這可能相當複雜。 Azure 雲端以 Kubernetes 作為受控服務。 Azure Kubernetes Service (AKS) 和 Azure Red Hat OpenShift (ARO) 可讓您完全運用以 Kubernetes 為受控服務的功能，卻無須安裝及維護它。
容器協調流程的詳細說明請參閱擴縮雲端原生應用程式。
支援服務
雲端原生系統相依於許多不同的輔助資源，例如資料存放區、訊息代理程式、監視和身分識別服務。 這些服務稱為支援服務。
圖 1-8 顯示雲端原生系統取用的許多常見支援服務。
圖 1-8。 常見的支援服務
您可以裝載自己的支援服務，但接下來必須自行負責授權、佈建及管理這些資源。
雲端提供者提供豐富的受控支援服務種類。您只要取用服務，但不需要擁有服務。 雲端提供者會大規模操作資源，並全權負責效能、安全性和維護。 監視、備援和可用性已內建於服務中。 提供者保證服務等級效能並完全支援其受控服務 - 開立票證，他們就會修正您的問題。
雲端原生系統偏好來自雲端廠商的受控支援服務。 節省可觀的時間與人力。 自行裝載作業有風險，而且處理發生的問題所費不貲。
最佳做法是將支援服務視為附加資源，以儲存在外部組態中的組態資訊 (URL 和認證) 動態繫結至微服務。 十二要素應用方法 (英文) 已詳細說明本指導，如本章前文所述。
要素 #4 指出支援服務「應透過可定址 URL 公開。 如此可分開資源與應用程式，使其成為可交換的資源。」
要素 #3 指出「組態資訊會移出微服務，並透過程式碼外部的組態管理工具外部化。」
使用此模式時，可以附加和中斷連結支援服務，但不需變更程式碼。 您可以將微服務從 QA 推進至預備環境。 您可以更新微服務組態，以指向預備中的支援服務，並透過環境變數將設定插入容器。
雲端廠商提供 API 供您與其專屬支援服務通訊。 這些程式庫會封裝專屬的管道和複雜度。 不過，直接與這些 API 通訊會讓您的程式碼與該特定支援服務緊密結合。 一般都是使用這種做法來隔離廠商 API 的實作詳細資料。 引入仲介層 (或稱中繼 API)，將泛型作業公開至您的服務程式碼，並將廠商程式碼包裝在內。 這種鬆散結合可讓您交換其他支援服務，或將程式碼移至不同的雲端環境，但不需要變更主線服務程式碼。 稍早討論的 Dapr 會使用預先建置的建置組塊遵循此模型。
最後一點，支援服務也會推動十二要素應用方法 (英文) 的無狀態原則，如本章前文所述。
要素 #6 指出「每項微服務都應該在自己的處理序中執行，與其他執行中的服務隔離。 將支援服務所需的狀態外部化，例如分散式快取或資料存放區。」
自動化
如您所見，雲端原生系統採用微服務、容器和現代化系統設計，以達到速度和靈活度。 但這只說明了部分情況。 該如何佈建這些系統執行所在的雲端環境？ 如何快速部署應用程式功能和更新？ 該如何一窺全貌？
進入廣為大眾接受的基礎結構即程式碼 (或 IaC) 做法。
您可以使用 IaC 自動化平台佈建和應用程式部署。 您基本上會將測試和版本設定等軟體工程實務套用至 DevOps 做法。 您的基礎結構和部署是自動化、一致且可重複的。
自動化基礎結構
Azure Resource Manager、Azure Bicep、HashiCorp 的 Terraform 和 Azure CLI 等工具可讓您以宣告方式編寫所需之雲端基礎結構指令碼。 資源名稱、位置、容量和祕密已參數化且為動態。 指令碼會建立版本，並簽入原始檔控制作為專案成品。 您可以叫用指令碼，跨 QA、預備和實際執行等系統環境，佈建一致且可重複的基礎結構。
在幕後，IaC 是等冪的，這表示您可以重複執行相同的指令碼，卻不會產生副作用。 如果團隊需要進行變更，他們可以編輯並重新執行指令碼。 只有更新的資源受到影響。
在基礎結構即程式碼是什麼一文中，作者 Sam Guckenheimer 說明「實作 IaC 的團隊如何快速且大規模地交付穩定的環境。 他們可避免手動設定環境，並透過程式碼表示其環境的預期狀態以強制執行一致性。 使用 IaC 的基礎結構部署是可重複的，並能防止因組態漂移或遺失相依性所造成的執行階段問題。 DevOps 團隊可以使用一組整合的做法和工具，以快速、可靠且大規模的方式交付應用程式及其支援的基礎結構。」
自動化部署
前文所述的十二要素應用方法 (英文) 會在將完成的程式碼轉換成執行中的應用程式時，呼叫個別步驟。
要素 #5 指出「每個版本都必須在建置、發行和執行階段之間強制進行嚴格的分隔。 每個階段都應該以唯一的識別碼標記，並支援復原功能。」
新式 CI/CD 系統有助實現此原則。 它們提供不同的建置和傳遞步驟，協助確保使用者隨時可取用一致和有品質的程式碼。
圖 1-9 顯示跨部署處理序的區隔。
圖 1-9。 CI/CD 管線中的部署步驟
請特別注意上圖中的工作區隔：
- 開發人員在其開發環境中建構功能，逐一查看所謂的程式碼「內部迴圈」、執行及偵錯。
- 完成後，該程式碼會推送至程式碼存放庫，例如 GitHub、Azure DevOps 或 BitBucket。
- 此推送會觸發建置階段，將程式碼轉換為二進位成品。 此工作使用持續整合 (CI) (英文) 管線實作。 其會自動建置、測試及封裝應用程式。
- 發行階段會挑選該二進位成品、套用外部應用程式和環境組態資訊，並產生不可變的發行版本。 此發行會部署至指定的環境。 此工作使用持續傳遞 (CD) (英文) 管線實作。 每個版本都應該可識別。 您可以說：「此部署正在執行應用程式的 2.1.1 版。」
- 最後，發行的功能會在目標執行環境中執行。 版本的不可變表示只要有變更就必須建立新版本。
套用這些做法，組織已大幅演進了其寄送軟體的方式。 很多組織已從每季版本變成隨選更新。 目標是盡早在開發週期中掌握問題，在費用不高時即予修正。 整合之間的持續時間愈長，解決問題的成本就愈高。 透過整合流程的一致性，團隊可以更頻繁地認可程式碼變更，進而提升共同作業和軟體品質。
DevOps 會詳細討論基礎結構即程式碼和部署自動化，以及 GitHub 和 Azure DevOps。
