我已经当了几年的平台工程师。我喜欢这份工作，对此充满了激情。

在本文中，我将讨论我的专业知识所带来的好处。由于平台工程师的角色还比较新，所以对于这个角色的需求和所提供的价值还没有形成广泛的共识。假如你找三个人询问他们对这个问题的意见，你会得到四个答案——至少在细节方面，我不会感到奇怪。另外，由于平台工程与基础设施非常接近，不存在直接和明显的价值可见性，想想前端工程，它就可以显示所提供的价值。

不管怎么说，我真正的动机是要清楚自己对这个问题的看法，而在这个过程中，写作帮助了我。

因为我现在只研究云基础设施，因此我所有的论点，以及对基础设施资源的提及，都应该放在这个背景下来看；不过我猜测，很多论断在更传统的数据中心，甚至更宽泛的范围应该都可以成立。

在我提出有价值的论点之前，我认为明智的做法是先简单回顾一下互联网历史。我所许诺的价值将会得到体现，这不仅是为了好玩，而且是为了描绘一幅图景。我当然是基于自己的个人经历，所以你的情况可能会不一样。

云计算简史

云计算是指计算机系统资源的按需可用性，尤其是数据存储（云存储）和计算能力，而用户无需直接主动管理。

 

——维基百科：云计算词条

随着现代云计算的出现，计算环境发生了一个重大变化：硬件现在有了一个按需的 API。实际上，并不是硬件，而是资源之前只能通过硬件来表达。这种情况不是一朝一夕就能发生的，没有第一家厂商使用“云”这个词，并且为所有人都指定了新的标准（即使有人可能会这样说）。这曾经是，现在依然是，一个由必要性和需求驱动的过程。这也不是一个进程，而是多个进程同时运行，并且以某种程度向同一方向发展。

对于平台工程，我认为两个因果概念或技术尤其重要，它们是：

虚拟化。尽管这一概念本身已经存在了几十年，而且很久以前就被用来处理边缘案例和大型企业解决方案，但是在我看来，第一个对更大的市场产生重大影响的实施是虚拟服务器。虚拟服务器允许数据中心的所有者将其昂贵的硬件分割为更小的块，以供自己使用，并使之更容易销售给他人。对现有资源的有效利用更为有效。但更重要的是，如果能够在一个物理服务器中创建多个虚拟服务器，那么下一个逻辑步骤当然是自动执行这个过程，然后再进一步：自动化的工具。基础设施 API 应运而生。不只是简单地管理虚拟服务器，还包括网络防火墙、CDN、数据库等等，这些都是虚拟的，可以通过 API 来实现。

容器化（与编排）：从严格意义上说，容器化是虚拟化的一个具体实现。但我仍然认为它应该有介绍自己的一段内容，因为没有技术能像容器化一样，在基础设施提供商和基础设施用户之间架起桥梁。封装在容器内的应用使双方在共同点上达成一致。只有适合于容器，我们才能运行它。而且，从容器化基础设施的角度来看，也需要编排：在隔离的环境下，大规模地运行标准化容器。

新范式

以上所提到的技术的广泛应用（我相信还有其他因素）引起了许多思考，并导致了一系列新的观点和后续业务的出现。在此，我要再次强调一些我认为特别具有影响力并与背景相关的因素：

微服务：微服务是对应用设计和实现的一种完全不同的观点。这使你可以将最复杂的应用视为一组不同的、潜在的、相互连接的功能。这一思路不仅适用于实现（构建“简化”的微服务），还适用于组织（拥有整体中定义良好的部分），当然，对部署和执行也有直接的影响：单体设计通常具有对操作系统和硬件（资源）的大量高度特定需求，而封装在容器中的微服务可以在更相同的基础设施中工作，不是作为一个整体，而是按照服务（部分）来扩展，以更小的爆炸半径单独失败，等等。这并不意味着每个应用都是（或者应该是）从一开始就被设计成微服务，但它仍然创造了思维方式，推动了组织，并促进了标准化。

宠物与牛：以前的服务器都是有名字的，并且都是单独配置的。我曾经在裸机上工作过，在将它们放进机架之前，我亲手贴上一张带有名字的贴纸，我很清楚我可以创造的“宠物”。由于能够访问提供虚拟服务器或任何其他资源的 API，因此没有办法，也没有必要跟上。现在，基础设施用户可以购买完全脱离物理的资源，根据需要自动扩展。结果，资源的可得性就不那么重要了（它们只是可得的）；我们考虑的是堆栈（资源），而非单个机器。资源就是数字。牛，不是宠物。请参阅 Randy Bias 写的内容，他将这一类比总结得很完美。

基础设施即代码：应用很复杂。操作系统也很复杂。如果两者都是相关的，那就会变得更复杂。过去，大多数人，包括我在内，都是手动配置系统的。这样就得到了系统的深刻理解，并且常常是独特的理解。这里所谓的独特，如在：低巴士因子（bus factor）；又如在：除了一个人外，没有人知道这个系统的情况。这个问题的解决方案是配置管理，它允许维护人员以可复制、可测试、版本控制和标准化的文档方式来描述整个设置。通过这个系统，配置可以很容易地重建（相对而言），人为错误因素大大减少，任何设置都可以在较短时间内被他人理解（相对而言）。基础设施即代码（Infrastructure as Code，IaC）在基础设施资源方面也是如此。不再需要手动提供 / 配置 / 订购特定服务或应用所需的资源，而是使用标准化、文档化、签入版本控制、代码可查看、可测试和可复制的代码来描述。

平台即服务：随着基础设施资源自动化日益普及，在上述基础设施上运行的东西也可以轻松地获得超级能力：可扩展性。也就是说，你只需为所需资源付费。或者从商业角度来看，你只需为你实际卖出的东西付费（粗略地说）。牢记这一点，我们就不难理解为什么如今几乎所有的功能都可以作为服务来购买。我们可以把它想象成一种由基础设施即服务（Infrastructure as a Service，IaaS）提供基础的供应链。这样，平台即服务（Platform as a Service，PaaS）就可以构建自己的服务，这些服务包括计算运行时、数据库、CDN 等等。通过这种方式，软件即服务（Software as a Service，SaaS）的构建者可以将注意力集中在他们自己的领域：软件构建，而不是深入到基础设施层。而且人们还可以根据需要增加或减少需求。请注意，在撰写本文时，维基百科上列出的“即服务”类型有 75 种，因此我略去了一些。但重点是，市场已经改变。诸如硬件、操作系统、服务操作之类的问题现在可以外包，按需购买。

所有这些范式深深地纠缠在一起。你可以认为“平台即服务”是“微服务”的结果，反之亦然。另外，如果没有“基础设施即代码”，宠物与牛是几乎不可能的，而后者是前者所需要的。

什么是平台工程？

在讨论平台工程带来的价值之前，我需要先说明我所说的是什么意思（或者不是什么意思）。也要记得，我的观点是，角色就像一顶帽子：你可以根据需要戴帽子。有些帽子是你经常戴的，有些帽子是你比别人更喜欢的，而有些帽子你会藏起来，希望以后不要把它拿出来。角色没有明确的界限，也不与职位挂钩。

平台化

我认为可以肯定地说，平台工程师参与平台的建设。由于平台这一术语相当模糊，所以我将试着在本文的范围内解释我的意思。让我们从以下几个方面开始：平台是一个定义良好的接口，它简化了对资源的处理和访问。

当然，在平台工程领域中，这些资源都是某种基础设施资源。从软件开发人员的角度来说，门面设计模式是我所能想到的最接近平台关键属性的。在我看来，平台是由一个或多个“服务门面（facade）”机器接口规范和文档组成的。这一切都是必要的，因为平台的目的就是自动化通用用例。

对于用户来说，平台基本上是透明的（比如，你不知道里面发生了什么），但我不确定这是否一个要求——尽管在大多数情况下这肯定是个好主意。

根据这一定义，GitHub 就是一个平台。AWS 也是一个平台，更确切地说，它是一个平台中的平台。但任何单独的、内部创建的解决方案都是一个平台，它为管理你的用例使用所需的基础设施资源提供了简化的接口。

平台化就是要确定常见的用例（或模式），为描述这些用例的接口进行建模，提供实现这些用例的自动化解决方案，并将其文档化，这样过程就可以以最小的人工交互进行使用。

平台工程就是与平台化相关的学科。

与其他角色相比

尽管平台工程是一个新的角色，但它并非凭空而来，而是对现有的其他角色和职责进行了专门划分——与所有角色一样。在我看来，以下几点对平台工程有重大影响：

我认为DevOps 工程师最接近平台工程的角色，他们专注于为特定应用（基于云基础设施）提供解决方案。或者说我这样认为：毕竟 DevOps 是一种生活方式。这是一个非常接近于平台工程的东西。在我看来，主要的区别应该是视角和所得到的的规模。DevOps 工程师提倡“他们”的应用，而平台工程则关注大量或全部应用。DevOps 工程师处理特殊用例（构建一组特定应用运行的基础设施），而平台工程处理普通用例（构建所有 / 大多数应用运行的平台）。DevOps 工程师对细节更感兴趣，而平台工程则更关注共性。根据我的经验，这两者通常都有需要，边界非常模糊，而且经常是同一个人“戴着两顶帽子”。

平台工程师角色的起源可能涉及到基础设施工程师的角色，其重点是构建、部署和维护基础设施。这个角色接近于系统管理员、网络工程师以及可能还有 DevOps。这超出了云的范畴，因为它还涉及到数据中心。本文只涉及云相关的范围。在这个术语中，我认为是“云（基础设施）工程师”，所以我就是这个意思。自然的，平台工程师从这里开始，使用（云) 基础设施，并对基础设施进行全面的思考。最大的不同在于，基础设施工程师非常注重可操作性和可靠性，而平台工程则是注重可访问性。

另外，后端工程师也发挥了作用，他们专注于应用的数据访问层。它的范围很广，有许多子专业，而且肯定接近 DevOps。其中一个核心问题是 API 的设计和实现，包括处理数据源、队列等等。平台工程也做这些，不过目的不同。后端工程师是由平台工程创建的平台的“客户”（公司内部），并在平台上构建自己的应用。

我曾说过，边界很难画出来，可能会有更多的角色（比如网站可靠性工程），我想和他们比较一下，但是有时候我不得不停下来，希望这个描绘的更清晰一些。

价值主张

最后，我要谈一下我的论点：平台工程的价值。

鉴于技术领域的变化，以及由此产生的新范式，我们可以清楚地看到：应用生态圈的复杂性正在增加。但这并非因为使用基础设施或应用开发方面的复杂性增加所致。事实上，基础设施的事情已经变得非常简单了，有了基础设施即代码等，从我的角度来看，应用开发也在易用性方面取得了长足的进步。

那是什么呢？嗯，这是巨大成功的错误所在：我所强调的变化（以及其他变化）带来了更多的可能性和机会。现在人人都能很容易获得可扩展性吗？好吧，这也意味着现在每个人都在关注这个问题。正因为如此，平台工程才起到关键作用：它通过降低用户和应用开发者的复杂性，帮助使这些机会更容易获得。

具体而言：

标准 PaaS 推销方式

PaaS（Platform as a Service，平台即服务）的优势主要在于它可以进行更高级别的编程，而复杂性则大大降低。

 

——维基百科：平台即服务词条

首先：我认为这应该是一般的作为服务的推销，而不是专门针对 PaaS 的。比如。“平台即服务”的优势主要在于，它可以在更高的级别上进行使用，而复杂性则大大降低：你知道，发送电子邮件、流媒体电影。如果有其他选择，所有更好的接口都会大幅降低复杂性。

这就是平台工程可以完成的工作：为基础设施资源创建更高级别的接口，这些接口的设计是为了使它们适合用例，然后实现它们。只不过不是为任何终端用户，就像上面一般的服务推销所暗示的那样，而是为应用开发者服务。标准化是免费的回报。

当然，平台工程师并非专为 PaaS 提供商工作的（周围没有那么多），他们在各地搭建平台。大多数 PaaS 提供商面向的是大众市场。有很多公司因为规模、安全、法律、遗留系统或者其他的原因不适合这个产品。他们仍需要使用由开发人员创建的基础设施来运行服务。

DevOps 工程和平台工程在专注于应用层的开发人员和提供用于运行应用的资源的基础设施提供商之间架起了一座桥梁。DevOps 工程提供了一个解决方案，可以在云基础设施中运行一组小型、专业化的服务。平台工程以平台的形式提供解决方案，在云基础设施中运行更通用的服务。二者之间的边界非常模糊，主要是规模和增长的问题。

无论哪种方式：这使开发人员能够集中精力开发应用，他们在这方面非常出色。依我看，你当然应该尽早开始平台化，除非你不期待基础设施的发展或变化。

价值：持久、高节奏的开发进度。

抵消技术债务

随着事情的改变或发展，技术债务也随之增加。一直如此，除非你停滞不前。问题不在于如何完全阻止它，而在于如何减缓它，让它变得可控，在你被迫停止之前不会增加。

许多因素导致了技术债务的增加。当然，也有业务方面的原因，因为它们占据了优先地位，使人们几乎没有或根本没有时间去调整基础设施或软件设计来抵消累积的技术债务。此外，还存在结构或架构方面的原因。类似微服务这样的模式也是为了从架构方面解决这个问题而产生的。

造成技术债务快速增长的一个主要因素是，同一问题有太多的解决方案。就像其他的应用一样，它们也有自己独特的部署管道、服务运行时、数据库设置或者是所有你能想到的东西。一座正在发展中的解决方案和模式的“动物园”，在此刻听起来也许是不错的主意，因为它们解决了眼前的问题，但在未来却会变成一片难以处理的混乱，非常脆弱，在这里危险，不可触碰，否则风险很大。

平台工程至少通过提供一个标准化的框架（服务的共同标准），在不同程度上抵消了这最后一个因素，以及其他因素。它还强制执行明确的边界和接口，使你可以更容易地理解、发展和改变应用的前景，无论是现在还是将来。

与此密切相关的是，久而久之，遗留问题也在不断积累。它还会转化成要求在某个时间偿还的技术债务。尽管平台工程并不直接解决遗留问题，但它将这些问题限定于组成服务或应用的商定边界之内。

最后，平台工程孕育了像前面提到的微服务这样的现代范式，它本身可以抵消技术债务。平台在这方面起到了支持和推动的作用。

价值：变革的敏捷性 / 不间断的增长。

为变化做好准备

唯一不变的就是变化。早在 2500 年前，人们就已经知道了这一点，甚至对于现代的应用基础设施而言，它仍然适用。然而，当变化到来的时候，我们仍然会感到惊奇。我在这个生态圈工作了 20 年，从来没有遇到过一个系统不会随时间而改变的情况。变化有许多形式。你可以做一些小事情，比如增加应用价值的新功能，也可以做一些根本性的改变，比如从物理数据中心迁移到云基础设施，或者重新构建整个应用。不管怎么说：事情会发生变化，你需要做好准备，或者在变化来临时支付高额的账单。这是必然的。

你猜对了，这里有一个共同的主题：平台工程是为了拯救。怎么说呢？它为部署和运行你的应用提供了一个标准化的环境。重点在于“标准化”一词。可以这样想，移动一百个应用，每一个都有各自的部署和运行服务的方式，这是非常困难的，甚至是可怕的。而移动一百个具有共同部署和运行服务方式的应用就容易得多。毫无疑问，一个平台可以提供这些共享的共性。

这也意味着：平台的早期。也许不是在打造 MVP 的时候，即使是我也不会提倡这样做，但是要确保时间足够早，以使标准化工作不会太过痛苦，让你对其视而不见。找出合适的时机并非易事，所以，要尽早进入平台。

价值：灵活性（应用基础设施中的灵活性转化为业务中的灵活性）。

作者介绍：

Ulrich Kautz，居住德国柏林，高级平台工程师，供职于 Scout24 Group。

原文链接：

https://ulrichkautz.com/posts/2021-03-11_value-of-platforming-engineering/