One post tagged with "CNCF"

前言​

最近唸了很多 DevOps 的服務，一直碰到 CNCF (Cloud Native Computing Foundation) 這個組織的產品服務與概念，這組織的目標是幫助企業更自由的使用雲端服務。正好讀到這個白皮書，因為之前工作經驗公司內部平台有很多問題，雖然每個人都使用的很痛苦，但是卻沒有任何改進的方向，許多的事情都是手動處理，公司內部的資料也散布各處。看完這個文章可以幫助你在創建平台時更有方向。

概念介紹​

受到 DevOps 概念中跨職能合作的啟發，平台工程已經開始在企業中出現。 建立這些平台的功能、框架和經驗，促進和加速企業內部用戶的工作（例如開發人員、資料科學家和資訊工作者）。

特別是在雲端運算領域，平台幫助企業實現了雲端的價值，例如快速產品發布、跨基礎設施的可移植性、更安全和更有彈性的產品以及更高的開發人員生產力。

本文目標是幫助企業領導者、企業管理人和平台團隊負責人倡議、了解和規劃雲端運算的內部平台。 我們認為平台對企業的實際價值有重大影響，但只是間接影響，因此領導層的共識和支持對於平台團隊的長期發展和成功至關重要。 本文將透過討論平台的價值是什麼、如何衡量價值以及如何實施和最大化平台團隊的價值。

目錄​

• 為什麼需要平台
• 平台的基本概念
• 成功平台的要素
• 成功平台團隊的特質
• 平台會面臨的挑戰
• 如何衡量平台的成功
• 平台要具備的能力

為什麼需要平台​

平台和平台工程是當今雲端運算世界的熱門話題。 在深入研究建立平台的定義、技術和衡量標準之前，重要的是先探索平台所提供的價值，推動這種當之無愧的關注。

過去 2-3 年的流程改善顯著提高了軟體應用程式和產品團隊的敏捷性，為他們提供了運算、網路和儲存等基礎設施以及建置、測試、交付和可觀察性等開發人員服務的靈活服務。 這種自主權和流程改善也逐漸將越來越多的支援服務的責任轉移給產品團隊，迫使他們在基礎設施問題上花費越來越多的時間和認知精力，並減少他們產生與組織相關的價值的時間。

使交付團隊重新聚焦於其核心焦點並減少整個組織內重複工作的願望促使企業實施雲端原生運算平台。 透過投資平台，企業可以：

• 減少產品團隊的認知負擔，進而加速產品開發與交付
• 透過專家來配置和管理產品，提高平台產品的可靠性和彈性
• 透過在企業中的多個團隊之間重複使用和共享平台工具和知識來加速產品開發和交付
• 透過管理平台功能及其周圍的使用者、工具和流程，降低產品和服務中的安全、監管和功能問題的風險
• 透過將實施委託給這些供應商，同時保持對使用者體驗的控制，實現對公有雲和其他託管產品的服務的經濟高效且高效的使用

這些好處的產生部分是因為只有少數平台團隊為許多產品團隊提供服務，因此倍增了他們的影響力； 部分原因是平台團隊整合了通用功能的管理，促進了治理； 部分原因是平台團隊首先強調使用者介面和體驗。

平台專家團隊不僅可以減少產品團隊所需的常見工作，還可以優化這些產品中使用的平台功能。 平台團隊也維護一套在整個企業廣泛使用的傳統模式、知識和工具； 使開發人員能夠快速為基於相同基礎的其他團隊和產品做出貢獻。 共享平台模式還允許在模板、模式和功能中嵌入治理和控制。 最後，由於平台團隊聚集了提供者並為其產品提供一致的體驗，因此它們可以有效地利用公有雲和服務提供者來實現基礎但無差異的功能，例如資料庫、身分存取、基礎設施操作和應用程序生命週期。

平台的基本概念​

雲端原生運算平台是根據平台使用者的需求定義和呈現的功能的整合集合。 它是一個橫切層，可確保為廣泛的應用程式和用例獲取和整合典型功能和服務提供一致的體驗。 一個好的平台可以為使用和管理其功能和服務（例如 Web 入口網站、專案範本和自助服務 API）提供一致的使用者體驗。

根據 Atlassian 的說法，「 平台團隊創建的功能可以許多與流程一致的團隊都在使用它，而且開銷很小... 平台團隊最大限度地減少了與流相關的[產品]團隊的資源和認知負擔……平台團隊可以創建跨越不同用戶體驗或產品的有凝聚力的體驗。」

Martin Fowler 和 Evan Bottcher 表示，「數位平台是自助 API、工具、服務、知識和支援的基礎，這些內容被安排為引人注目的內部產品。 自主交付團隊可以利用該平台以更快的速度交付產品功能，同時減少協調。

平台支援的具體功能和場景應根據利害關係人和使用者的需求來確定。 雖然平台提供了這些所需的功能，但值得注意的是，平台團隊不應總是自行實現這些功能。 託管服務提供者或專門的內部團隊可以維護支援實施，而平台是最薄的合理層，可以在所提供的實施之間提供一致性並滿足組織的要求。 例如，一個非常簡單的「平台」可以是一個 wiki 頁面，其中包含指向標準操作程序的鏈接，以提供提供者的功能。

因為這些平台的目標物件正是企業內部用戶，所以我們通常稱它們為內部平台。

平台與雲端原生架構特別相關，因為它們比以前的範例更將支援功能與特定於應用程式的邏輯分開。 在類似雲端的環境中，資源和功能通常是獨立管理的，並與自訂業務元件整合； 此類資源可能包括資料庫和物件儲存、訊息佇列和代理程式、可觀察性收集器和儀表板、使用者目錄和驗證系統、任務執行器和協調器等。 內部平台向企業團隊提供這些內容，使他們能夠輕鬆整合到他們的應用程式和系統中。

• 平台成熟度

最基本的是，內部平台為獲取和使用單一服務（例如管道運行器、資料庫系統或秘密儲存）提供一致的體驗。 隨著它們成熟的內部平台也提供此類服務的組合，例如適用於 Web 應用程式開發或資料分析（又稱 MLOps）等關鍵場景的自助服務範本。企業可能遇到的平台用例可能會透過以下方式進展：

產品開發人員可以按需提供功能並立即使用它們來運行系統，例如運算、儲存、資料庫或身分。

• 產品開發人員可以按需配置服務空間，並使用它們來運行管道和任務、儲存工件和配置和/或收集遙測資料。
• 第三方軟體的管理員可以按需配置資料庫等所需的依賴項，並輕鬆安裝和運行該軟體。 產品開發人員可以從範本提供完整的環境，結合特定場景（例如 Web 開發或 MLOps）所需的執行時間和開發時服務。
• 產品開發人員和經理可以透過自動儀表和標準儀表板觀察已部署服務的功能、效能和成本。 透過為單一功能或一組功能提供一致、合規的體驗，內部平台最終使用戶能夠更輕鬆、更有效率地交付有價值的產品。

成功平台的要素​

在定義了平台是什麼以及組織為何想要建立平台之後，讓我們確定一些影響平台成功的關鍵屬性。

• 平台作為產品

平台的存在是為了滿足用戶的需求，並且應該根據這些需求進行設計和發展，類似於任何其他軟體產品。 平台應提供必要的功能來支援產品團隊中最常見的用例，並將這些功能優先於僅由單一團隊使用的更具體的功能，以最大化交付的價值。

• 使用者體驗

平台應透過一致的介面提供其功能並關注用戶體驗。 平台應盡力滿足使用者的需求，這可能意味著 GUI、API、命令列工具、IDE 和入口網站的組合。 例如，平台通常提供部署應用程式的功能。 開發人員可能透過 IDE 使用此類功能，測試人員可能使用命令列工具，而產品擁有者可能使用基於 GUI 的 Web 入口網站。

• 文件和入職培訓

文件是成功軟體產品的關鍵方面。 為了能夠使用平台的產品，使用者需要文件和範例。 平台應提供適當的文件來滿足使用者的需求。 它還應該提供加速新專案啟動的工具 可以幫助使用者快速、簡單地使用必要的平台服務。 例如，該平台可以提供可重複使用的供應鏈工作流程，用於在 Kubernetes 上建置、掃描、測試、部署和觀察 Web 應用程式。 這樣的工作流程可以透過初始專案範本和文件來提供，這些捆綁包通常被描述為黃金路徑。

• 自助服務

平台應該是自助式的。 使用者必須能夠自主、自動地請求和接收功能。 此屬性對於允許平台團隊啟用多個產品團隊並根據需要進行擴展至關重要。 平台功能應按需提供，並且透過上述介面進行最少的手動幹預。 例如，使用者應該可以透過執行命令列工具或在入口網站上填寫表格來請求資料庫並接收其定位器和憑證。

• 減少使用者的認知負擔

平台的一個基本目標是減少產品團隊的認知負擔。 平台應該封裝實現細節並隱藏其架構可能產生的任何複雜性。 例如，平台可能會將某些服務委託給雲端供應商，但使用者不應該接觸到此類詳細資訊。 同時，平台應允許使用者根據需要配置和觀察某些服務。 用戶不得對平台提供的服務的運作負責。 例如，使用者可能經常需要資料庫，但他們不應該管理資料庫伺服器。

• 可選且可組合

平台旨在提高產品開發效率，因此它們不能成為障礙。 平台應該是可組合的，並且使產品團隊能夠僅使用其產品的一部分。 它還應該使產品團隊能夠在必要時提供和管理平台產品以外的自己的功能。 例如，如果一個平台不提供圖資料庫，而產品需要它，那麼產品團隊應該可以自行配置和操作圖資料庫。 預設情況下安全。 平台預設應該是安全的，並提供確保基於組織定義的規則和標準的合規性和驗證的功能。

成功平台團隊的特質​

平台團隊負責平台功能的介面和體驗 - 例如 Web 入口網站、自訂 API 和黃金路徑範本。 一方面，平台團隊與實施基礎設施和支援服務的團隊合作，定義一致的體驗； 另一方面，他們與產品和使用者團隊合作收集回饋並確保這些體驗符合要求。

以下是平台團隊應負責的工作：

• 研究平台使用者需求並規劃功能路線圖
• 行銷、宣傳和倡導平台建議的價值觀
• 管理和開發用於使用和觀察功能和服務的介面，包括入口網站、API、文件和範本以及 CLI 工具

最重要的是，平台團隊必須了解平台使用者的需求，以告知並不斷改進其平台提供的功能和介面。 了解使用者需求的方法包括使用者訪談、互動式黑客馬拉松、問題追蹤器和調查以及透過可觀察工具直接觀察使用情況。 例如，平台團隊可以發布一個表單供使用者提交功能請求、主持路線圖會議以分享即將推出的功能並審查使用者的使用模式以設定優先順序。

入站回饋和周到的設計是產品交付的一方面； 另一面是對外行銷和宣傳。 如果該平台真正是根據用戶需求構建的，那麼這些用戶將很高興使用所提供的功能。 平台團隊促進用戶採用的一些方法是透過內部行銷活動，包括廣泛的公告、引人入勝的演示以及定期回饋和溝通會議。 這裡的關鍵是滿足用戶所在的位置，讓他們踏上與平台互動並從中受益的旅程。

平台團隊不一定運行運算、網路、儲存或其他服務。 事實上，內部平台應該盡可能依賴外部提供的服務和能力； 只有當託管提供者或內部基礎設施團隊無法從其他地方獲得這些功能時，平台團隊才應建立和維護自己的功能。 相反，平台團隊對其平台提供的服務和功能的介面（即 GUI、CLI 和 API）和使用者體驗負有最大責任。

例如，平台中的網頁可能會描述甚至提供一個按鈕來為應用程式提供身分； 而該功能的實現可能是透過雲端託管的身份服務。 內部平台團隊可以管理網頁和API，但不能管理實際的服務實現化。 只有當所需功能在其他地方不可用時，平台團隊通常才應考慮創建和維護自己的功能。

平台會面臨的挑戰​

雖然平台承諾了許多價值，但它們也帶來了實施者應牢記的以下挑戰。

• 平台團隊必須像產品一樣對待平台，與使用者一起開發
• 平台團隊必須謹慎選擇優先順序和初始合作夥伴應用團隊
• 平台團隊必須尋求企業領導階層的支持並展現對價值流的影響

也許最重要的是將該平台視為面向客戶的產品，並認識到其成功直接取決於其用戶和產品的成功； 因此，平台團隊與應用程式團隊和其他使用者合作，確定平台功能和使用者體驗的優先順序、規劃、實施和迭代至關重要。 如果平台團隊在沒有回饋的情況下發布功能和體驗，或依靠自上而下的指令來實現採用，那麼幾乎肯定會遭到用戶的抵制和不滿，並錯過很多承諾的價值。 為了解決這個問題，平台團隊應該從一開始就納入產品經理來分享路線圖、收集回饋並普遍理解和代表平台使用者的需求。

採用平台時，首先選擇合適的功能和體驗至關重要。 經常需要且無差別的功能，例如管道、資料庫和可觀察性，可能是一個不錯的起點。 平台團隊也可能選擇先專注於數量有限、敬業且技術精湛的應用程式團隊。 這些團隊的詳細回饋改善了首次平台體驗； 這些團隊的人員幫助向後來的採用者宣傳和宣傳該平台。

最後，對於大型企業來說，快速獲得平台團隊的領導支援至關重要。 許多企業領導者將 IT 基礎設施視為一項支出，與其主要價值流完全脫節，並可能試圖限制分配給 IT 平台的成本和資源，從而導致實施不力、承諾未兌現和受挫。 為了緩解這種情況，平台團隊需要展示他們對產品和價值流團隊的直接影響以及與產品和價值流團隊的關係（請參閱前兩段），將平台團隊展示為產品團隊為客戶提供價值的策略合作夥伴。

平台要具備的能力​

從這些挑戰中可以清楚看出，平台團隊面臨著許多不同的責任，這導致了認知負擔。 正如他們的應用程式團隊同行一樣，這項挑戰隨著他們需要支援的用戶和團隊的數量和多樣性而增長。

將平台團隊的精力集中在其特定業務特有的經驗和能力上非常重要。 減輕平台團隊負擔的方法包括：

• 尋求在託管提供者的實施之上建立最薄的可行平台層
• 利用開源框架和工具包創建供應用程式團隊使用的文件、範本和組合
• 確保平台團隊配備適合其領域和客戶數量的人員

如何衡量平台的成功​

企業將希望衡量他們的平台計劃是否提供了上述價值和屬性。 此外，在本文中，我們一直強調將內部平台視為產品的重要性，良好的產品管理取決於對產品性能的定量和定性衡量。 為了滿足這些要求，內部平台團隊應持續收集使用者回饋並衡量使用者活動。

然而，與內部平台的其他方面一樣，平台團隊應該使用最小的可行努力來收集他們需要的回饋。 我們將在這裡建議指標，但對用戶行為的簡單調查和分析最初可能是最有價值的。有助於企業和平台團隊了解其平台影響的指標類別包括：

• 使用者滿意度和生產力
  • 許多平台追求的首要品質就是改善使用者體驗，以提高生產力。 反映使用者滿意度和生產力的指標包括以下內容：
  • 活躍用戶和保留：包括配置的功能數量和用戶成長/流失
  • 「淨推薦值」(NPS) 或其他衡量使用者對產品滿意度的調查
  • 開發人員生產力指標，例如 SPACE 框架中討論的指標 [4]
• 組織效率
  • 許多平台尋求的另一個好處是有效地為大量用戶群提供共同需求。 這通常是透過啟用用戶自助服務並減少手動步驟和所需的人為幹預來實現的，同時實施保證安全性和合規性的策略。 衡量平台的效率
  • 在減少共同工作時，可考慮採取以下措施：
    • 從請求到實現服務或功能（例如資料庫或測試環境）的延遲
    • 建立全新服務並將其部署到生產中的延遲
    • 新用戶提交其產品的第一個代碼更改的時間
    • 產品和功能交付
• 內部平台的最終目標是更快地向客戶交付業務價值，因此衡量對企業自身產品和功能發布的影響表明平台的目標正在實現。 Google 的 DevOps 研究與評估 (DORA) 研究所建議 [5] 追蹤以下指標：
  • 部署頻率
  • 變更準備時間
  • 故障後恢復服務的時間
  • 改變失敗率
• 一般來說，平台團隊的一個關鍵目標是將基礎架構和其他 IT 功能與企業的價值流（其產品）保持一致。 因此，最終組織產品和應用程式的成功才是衡量平台成功的真正標準。

平台要具備的能力​

正如我們所描述的，雲端原生運算平台提供並組合了來自許多支援供應商的功能和服務。 這些提供者可能是同一企業內的其他團隊或第三方（例如雲端服務提供者）。 簡而言之，平台是從底層能力提供者到平台使用者（如應用程式開發人員）的橋樑； 並在此過程中實施和執行所需的安全、性能、成本治理和一致體驗的實踐。 下圖說明了產品、平台和能力提供者之間的關係。

我們這篇文章主要討論如何建立一個好的平台和平台團隊； 現在，在最後一節中，我們將描述平台實際上可以提供的功能。 此列表旨在指導平台建立者，並包括雲端原生應用程式通常所需的功能。 正如我們在全文中所指出的，一個好的平台反映了使用者的需求，因此最終平台團隊應該選擇並優先考慮其平台與使用者一起提供的功能。

能力可能包含多個特徵，即父能力領域的面向或屬性。 例如，可觀察性可能包括收集和發布指標、追蹤和日誌以及觀察成本和能源消耗的功能。 考慮組織中每個功能或方面的需求和優先順序。 後續 CNCF 出版物可能會進一步擴展每個領域。

以下是建構雲端原生運算平台時需要考慮的功能域：

• 用於了解和配置產品與功能的入口網站
• 用於自動配置產品和功能的 API（和 CLI）
• Golden path 範本和文件可實現產品功能的最佳利用
• 建置和測試服務和產品的自動化
• 交付和驗證服務和產品的自動化
• 開發環境，例如託管 IDE 和遠端連接工具
• 使用監測服務和產品的可觀察性，包括功能、性能和成本的觀察
• 基礎設施服務，包括 commpute runtime、可程式化以及網路和儲存空間
• 數據與資料儲存，包括資料庫、快取和物件存儲
• 訊息傳遞和事件管理，包括 brokers, queues, and event fabrics
• 身份驗證與權限控管，服務和使用者身分和授權、憑證和金鑰頒發以及 static secret storage
• 安全服務，static analysis of code、artifacts、runtime analysis 與 policy enforcement
• 程式組件的儲存，包括和特定語言包、容器映像檔與程式套件與程式碼

需求	描述	CNCF/CDF 專案範例
用於了解和配置產品與功能的入口網站	發布文件、服務目錄和專案範本。 發布有關系統和功能的遙測數據。	Backstage, Skooner, Ortelius
用於自動配置功能的 API	用於自動建立、更新、刪除和觀察功能的結構化格式。	Kubernetes, Crossplane, Operator Framework, Helm, KubeVela
Golden path 模板和文檔	整合良好的程式碼和功能的模板組合，可實現快速專案開發。	ArtifactHub
建置和測試產品的自動化	自動建置和測試數位產品和服務。	Tekton, Jenkins, Buildpacks, ko, Carvel
交付和驗證服務的自動化	自動化並觀察服務的交付。	Argo, Flux, Keptn, Flagger, OpenFeature
開發環境	促進應用程式和系統的研究和開發。	Devfile, Nocalhost, Telepresence, DevSpace
應用程式可觀察性	監控應用程式與告警	OpenTelemetry, Jaeger, Prometheus, Thanos, Fluentd, Grafana, OpenCost
基礎設施服務	運行程式碼、連接應用程式組件並保留應用程式的資料	Kubernetes, Kubevirt, Knative, WasmEdge, KEDACNI, Istio, Cilium, Envoy, Linkerd, CoreDNSRook, Longhorn, Etcd
數據服務	保留應用程式的結構化資料	TiKV, Vitess, SchemaHero
訊息傳遞和事件管理	使應用程式能夠彼此非同步通訊	Strimzi, NATS, gRPC, Knative, Dapr
身份驗證與權限控管	確保工作負載具有使用資源和功能的定位器和秘密。 使服務能夠向其他服務識別自己的身份 Dex、外部秘密、SPIFFE/SPIRE、Teller、憑證經理	Dex, External Secrets, SPIFFE/SPIRE, Teller, cert-manager
安全服務	觀察運行時行為並報告/修復異常。 驗證建置和工件不包含漏洞。 根據企業要求限制平台上的活動； 通知和/或糾正異常情況	Falco, In-toto, KubeArmor, OPA, Kyverno, Cloud Custodian
Artifacts 管理	儲存、發布和保護建置的工件以在生產中使用。 快取並分析第三方工件。 儲存原始碼。	ArtifactHub, Harbor, Distribution, Porter