作者 | Hemanth Kavuluru

編譯 | 言征

出品 | 51CTO技術棧（微信號：blog51cto）

到底什么是平臺？它是內部開發者平臺、開發者自助服務門戶還是僅僅是開發者入門工具？  

平臺工程并不是一個新概念，在谷歌、亞馬遜、Facebook、Netflix 等許多大公司中已經存在很長時間了。對于任何大型產品工程團隊來說，平臺是一組標準服務、框架和模式，最初由一個或多個團隊開發供其使用，可供組織中的其他團隊利用。

工程組織的其余部分要么使用這些平臺服務來開發其他應用程序或服務，要么作為內部工具。

當開源、商業框架和平臺作為服務和工具不可用時，產品團隊過去常常在內部構建許多共享服務和工具。一個很好的例子是 Google 的內部容器管理平臺 Borg，它最終成為 Kubernetes。

另一個很好的例子是 Kafka，這是一個開源消息平臺，最初是 LinkedIn 為內部使用而構建的。同樣，亞馬遜網絡服務（AWS）的S3和EC2最初是為內部使用而開發的，后來成為AWS公共云的核心基礎。

由于這些平臺、框架和工具可以作為開源或商業產品提供，平臺團隊不再需要構建它們來進行應用程序開發或自助服務云基礎設施。

Rafay Systems 的 Kubernetes 操作平臺可幫助企業使用任何 K8s 發行版跨公共云、數據中心和邊緣操作現代應用程序基礎設施。借助 Rafay，企業可以實現 Kubernetes 基礎設施的自動化、安全性、可見性和治理。

1、云原生環境下的“平臺”

那么云原生應用程序開發、部署和管理背景下的平臺到底是什么？它是內部開發人員平臺、開發人員自助服務門戶、開發人員體驗工具還是僅僅是開發人員入門工具？除了開發者之外還有其他用戶使用該平臺嗎？

所有問題的答案似乎都是“是”。我們現在所說的平臺是以上所有內容以及更多內容的組合。由于大多數基礎服務都可以開源或商業產品或兩者的形式提供，因此平臺工程團隊的主要目標是使這些服務和工具易于發現，以自助方式隨時可用，并且使用標準接口（例如API、UI、自助門戶、Terraform 等。

例如，平臺團隊可以向最終用戶提供集群或容器即服務，這樣每個業務部門或應用程序團隊就不必配置或管理Kubernetes 基礎設施。另一個例子是應用程序部署即服務，其中平臺團隊通過提供 Argo CD 等工具即服務來自動化應用程序部署過程。

為了最終取得成功，平臺團隊不僅必須解決其開發人員的用例，還必須解決其他內部團隊的用例。

在幕后，平臺團隊可能會利用各種商業或開源框架以及一些自定義自動化。盡管開發人員是該平臺的主要內部用戶，但 SRE、安全、產品支持和 FinOps 等其他團隊也可以從該平臺中受益匪淺。

為了最終取得成功，平臺團隊不僅必須解決其開發人員用例，還必須解決其他內部團隊的用例。

這樣的平臺可能具有一個或多個用戶界面，開發人員和其他內部用戶可以使用這些界面以自助方式輕松使用這些服務，而平臺團隊的幫助最少。

對于不同的用戶角色，用戶界面可能不同。例如，開發人員可以使用 Backstage（一個用于構建內部開發人員門戶的開源框架）作為自助服務門戶來訪問所有開發資源，如目錄、模板、部署管道、開發/測試環境等。團隊可以使用 Terraform用于基礎設施管理和維護。

用戶界面的背后是平臺的后端，它匯集了組織的所有通用框架、基礎設施、服務和工具，并通過一個或多個用戶界面將它們作為標準服務提供給最終用戶。

組織的安全、治理和合規性要求也被納入后端以應用于所有平臺服務，以便在整個組織中一致地執行這些要求。

2、平臺架構

在最簡單的形式中，該平臺可以被視為兩個組件（如下所示）——一個由一個或多個最終用戶界面組成的前端和一個為前端提供必要的基礎設施、服務和工具自動化的后端，從而為最終用戶提供支持以自助方式使用這些功能來提高生產力、加速產品開發以及一致的安全和治理策略控制。

圖片

開發人員的前端可以是簡單的自制門戶、高級后臺部署或商業內部開發人員平臺 (IDP) 解決方案。同樣，對于 SRE 團隊來說，前端可能由平臺團隊開發的一組通用 Terraform 模塊組成，用于配置和管理基礎設施。

對于某些團隊來說，這可能意味著可以檢入 git 存儲庫的基礎設施資源的聲明性規范，并且基礎設施資源通過 GitOps 自動配置和管理。

后端本質上是基礎設施自動化、應用程序服務、開發人員體驗工具、SRE 工具和框架以及安全和治理策略管理工具的集合。平臺團隊通常通過在這些基礎設施、服務和工具之上添加額外的自動化層來構建此后端，以使它們可以通過各種前端使用。

例如，可能是開發自定義插件，以允許開發人員從 Backstage 門戶創建開發人員沙箱。同樣，它可能是一個 Terraform 模塊，用于創建具有所有必需的附加組件和策略的 Kubernetes 集群，SRE/運營團隊可以使用它來創建具有一致配置的集群。平臺后端的每個主要組件描述如下：

3、基礎設施

該組件提供配置和編排公共/私有云資源所需的自動化。自動化可能包括為 Kubernetes 集群、完整環境等復雜資源配置基本基礎設施資源（如虛擬私有云、身份和訪問管理角色以及負載均衡器）。平臺團隊通常使用基礎設施即代碼和 GitOps 實踐來實現自動化。

4、服務

每個應用程序團隊在其應用程序開發中都會使用各種不屬于核心應用程序的服務和工具。這些服務的范圍可能從容器注冊表、CI/CD 管道和 Vault 作為機密管理等基本服務，到消息傳遞、緩存、數據備份、災難恢復等高級服務。

平臺團隊自動化這些服務，并通過簡單的界面將它們提供給應用程序團隊進行加入/集成，從而減少應用程序團隊的辛苦和認知負擔，使他們能夠更多地專注于核心應用程序開發，以加速產品交付。

5、可觀測性

可觀察性涉及從正在運行的系統收集可用于故障排除和修復問題的數據、分析資源使用情況以優化性能、收集容量規劃指標或構建預警系統以在任何潛在問題發生之前檢測到這些數據等。

日志記錄、指標和跟蹤是可觀察性堆棧的重要組成部分。平臺團隊通常使用開源和/或商業解決方案，并且可以實現額外的自動化以與各種數據收集應用程序無縫集成；他們將其提供給開發人員和 SRE/Ops 團隊進行分析和故障排除。

6、SRE

除了可觀察性工具之外，SRE 和運營團隊還使用大量其他工具和技術來管理和運營大規模應用基礎設施。這些可能包括車隊基礎設施管理和運營的自動化、混沌工程、事件管理、警報管理、用于高級調試的自定義故障排除工具、自我修復等。

平臺團隊可以對其中一些工具的開源和商業產品進行標準化，并將其提供給 SRE 團隊。同樣，平臺團隊可以為車隊管理、高級調試和自我修復類型的用例開發自定義解決方案，因為這些用例可能非常特定于其基礎設施和應用程序。

7、開發者體驗 (DevEx)

每當開發人員開始開發新服務或應用程序時，他們常常被迫做重復的事情。這種情況在擁有許多內部應用程序團隊、產品團隊和業務部門的大型組織中尤其普遍，這些團隊之間通常很少共享代碼和工具。這些重復性任務可能包括為已存在的新服務創建樣板代碼模板、設置測試床、啟動開發/測試環境等。

除此之外，開發人員還需要了解他們擁有的服務的信息——它使用了哪些資源、服務的健康程度、最后一次更改的時間以及如何查看最新日志。平臺團隊可以通過利用 Backstage 或其他開發人員門戶的統一開發人員門戶提供這些功能，以及自動執行此類任務中涉及的可重復任務的功能。

8、安全與治理

信息安全和安全團隊為整個組織使用的所有組件、服務和基礎設施定義安全框架和基線安全態勢。這可能需要在所有系統中一致地執行所有安全策略和實踐，以滿足安全基線狀況，持續驗證基線以檢測任何偏差，并在發生違規時快速補救。

安全基線策略包括單點登錄和基于角色的訪問控制、網絡安全、用于在資源級別實施精細合規性和安全策略的開放策略代理 (OPA)、漏洞圖像掃描、運行時容器安全、CIS 基準測試、 ETC。

平臺團隊需要在應用程序開發、部署和管理的每個階段以及基礎設施級別自動應用這些成本控制策略。

對于治理而言，成本控制策略對于每個組織都至關重要。平臺團隊需要在應用程序開發、部署和管理的每個階段以及基礎設施級別自動應用這些成本控制策略。例如，這可能意味著為 Kubernetes 集群部署自動安裝一組經過批準的系統附加組件和 OPA 策略、網絡策略和成本控制策略。

9、結論

沒有一種萬能的平臺工程方法。它歸結為每個組織的具體要求、優先級以及他們希望通過平臺實現的目標。該平臺不僅僅是 IDP 或后臺部署或自助門戶。開發者不一定是該平臺的唯一用戶。平臺團隊必須徹底了解所有內部用戶角色及其需求，并為平臺開發正確類型的后端和用戶界面，為所有內部用戶提供最大價值。

原文鏈接：https://thenewstack.io/platform-engineering/architecture-and-design-considerations-for-platform-engineering-teams/