作者 | 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