构建平台即产品的5个教训

尽可能地组织和标准化平台的各个方面，以确保从第一天到第 2000 天乃至更永劫光的易用性和掩护性。

译自 5 Lessons For Building a Platform as a Product，作者 Colin Humphreys。

在 20 年的平台工程履历和 10 年的 平台即产品 培植履历中，以下五个关键履历教训可以帮助您打造成功的平台即产品。

作为一名在平台工程领域事情了二十年的专业人士，我专门从事平台即产品的构建，为环球一些最有名的品牌构建平台，并创办了一些终极被更大组织收购的公司。
在此过程中，我犯过很多缺点，也取得了一些成功。

我最近在 PlatformCon 演讲等分享了我最主要的学习成果，“20 年平台工程，10 年平台即产品，5 个履历教训。
” 我想在本文中进一步阐述几个主题。

让我们深入磋商我从平台即产品履历中得到的五个履历教训，这些教训是我 来之不易的（由于事情可能会出错，而且确实会出错！
）：

采取“产品思维”。
为您的组织找到得当的抽象。
使您的平台民主化。
无处不是棕地，统统都很繁芜。
第一天很随意马虎；第二千天很难。
采取产品思维构建平台

在构建平台时，“产品思维” 意味着什么？在 我与 Joe Fitzgerald 共同撰写的一篇关于平台即产品的白皮书 中，我们定义了关于平台“产品化”的思考办法，它可以重塑我们对平台构建的意见：

“您的平台不是现成的软件；它是一组不断发展的可重用做事，与您的现有系统集成，为您的业务创造有代价的结果。
平台的功能该当根据其用户的需求而改变——您的运用程序开拓职员——在他们中，它是一个可识别的内部品牌。
换句话说，您的平台该当被视为一种产品。
”

如果您没有从产品思维出发进行构建，平台将变得以项目为导向。
它很可能局限于特定的开始和结束日期，并具有发布和某些功能，其运作办法与大多数短期项目非常相似。
与大多数现成的软件发布一样，它进入天下，我们希望统统顺利。
然后，我们重复这个以项目为中央的流程。
这种增量式平台构建方法与上述定义不符，并且会错过一些主要的机会，由于合理的平台工程 不仅仅是工程。

用户是构建精良平台的核心。
用户想要什么，他们会利用什么？平台根据这种利用和我们积极从用户群中寻求的反馈而发展。
与大多数事物一样，它该当相应不断变革的开拓或业务需求以及利用模式，以供应代价。

从工程角度来看的可行性、从产品管理角度来看的可行性以及从设计和可用性角度来看的吸引力，共同构成了我们所说的“成功产品”。
这意味着，虽然平台工程是必要的，但它本身并不敷以，由于成功的平台产品须要产品管理和设计技能。

紧张要点

为平台即产品带来真正且持续的代价，首先须要理解其用户，并牢记以下几点：

平台工程只是个中的一部分——产品和设计也很主要。
与用户互助，并亲自体验他们如何利用平台；利用 X 作为做事来确保可扩展性。
捕获用户指标并相应反馈，以不断适应用户需求并注入持续创新。
为您的组织找到得当的抽象

与任何 CTO 交谈，他们都会见告你，他们的运用程序团队在非开拓任务上花费了太多韶光。
2019 年 《新堆栈》上揭橥的一项调查报告称，开拓职员在编写或改进代码上花费的韶光不到三分之一。
我自己与 CTO 的非正式谈天表明，估计有 80% 以上的运用程序团队韶光花在了不创造代价的繁琐事情上。
也便是说，开拓职员正在构建自己的内部平台，专注于运营事情负载，并实行许多其他非创意任务。

CTO 和开拓职员都希望减轻这种包袱。
平台工程可以供应帮助——如果组织投资探求适宜其业务的抽象。
这是一个很大的 如果，由于没有一个放之四海而皆准的平台，这也是一个潜在的障碍。

一种常见的方法是经典的糟糕的 DevOps“你写它，你运行它”的心态，在这种心态中，各个团队决定构建自己的平台，结果创造其他多个内部团队也投资创建了他们的平台。
撇开导致这种情形发生的组织沟通孤岛不谈，这样做是摧残浪费蹂躏的、低效的，并且没有利用平台工程的力量。

如何确定精确的抽象

什么是“精确的抽象”？一个很好的出发点是讯问我们从平台中须要哪些关键属机能力使其有代价。
它将如何为组织供应最大的效率、安全性和生产力？实现这一点须要查看组织中对团队的 期望，但 对业务来说是独一无二的。
如果某件事对行业来说并不独特，那么购买现成的产品可能更故意义，或者得到现有的云做事来知足需求，而不是试图自己构建它。

决定精确抽象的一种方法是理解缺点的抽象。
强制每个人走上一条规定性的“黄金路径”，旨在展示事情该当如何完成，这会造成摩擦和阻力。
这种“独裁式方法”是一种常见的冲突，由于不同的见地和履历与“这便是统统运作办法”的方法发生冲突。
无论是 CI/CD、利用的确切框架、暂存和生产，还是其他工具，创建（可）分解的抽象以确保人们更有效率并具有一定的灵巧性 非常主要。
以高等抽象形式供应选项有助于供应一些不会变成电网的指路牌。

紧张要点

精确的抽象将对组织及其需求是独一无二的，这意味着：

找到对您的团队的期望，但对您的业务来说是独一无二的没有灵巧性的承诺的“黄金路径”会降落生产力并造成摩擦不要对运用程序团队发号施令；他们会对事情如何运作有自己的意见。
您该当考试测验让他们的生活更轻松，但要以互助的办法，不要推翻他们的履历。
民主化您的平台

在企业中交付故意义、高效且有代价的软件常日涉及许多利益干系者。
尽早让这些人“参与进来”，否则您将在将代价投入生产和为组织的客户供应代价方面碰着困难。

全体过程中有许多人有权对您试图做的事情说“不”——出于各种缘故原由。
从一开始就民主化平台有助于将这些利益干系者纳入个中，并尽早将他们的代价带入平台。
对付企业来说，代价实现韶光是一个主要的考虑成分，在某些组织中，繁芜性、合规性和管理（以及其他成分）会严重减缓代价交付。

民主化平台力量的一个例子：一家保险公司将六个月到两年的支配周期缩短到将所有将代码支配莅临盆的活动整合到一个平台并将其自动化，从而将他们的支配周期缩短，并能够每天支配多次。

紧张要点

让得当的利益干系者参与进来，并将他们及其代价带到会谈桌上来，这对您终极得到的平台有很大影响。
民主化过程的一些关键点：

为您的平台创建一个自助式 API，并供应不同的接口来访问它帮助其他团队（身份、CI/CD、数据库）将他们的代价贡献到该平台使安全、网络和其他赋能团队能够供应他们供应的做事，例如，子系统团队从赋能团队得到代价，等等。
无处不是棕地，统统都很繁芜

天下不是一个原始的绿色空间，这适用于拥有大量遗留内容的组织。
是的，统统都是棕地 并且很繁芜，纵然是最有代价的办理方案也不能取代所有内容或在所有地方利用。

作为一个现实天下的例子，我和一家环球顶级银行的首席技能官谈过，他阐明说他很喜好 Cloud Foundry 的功能，但想知道他卖力的其他 99% 的事情负载该当用什么。
实质上，思考须要完成什么以及可以用现有资源完成什么至关主要，有时乃至至关主要。
如果你规模很小或拥有根本运用程序，利用 Heroku、Netlify 或其他平台即做事将非常合理。
但是，对付面临可扩展性、合规性和管理问题以及无数不符合新平台和做事的长期遗留运用程序的组织来说，繁芜性是不可避免的。

大多数企业都是棕地，繁芜程度弗成思议，而且难以处理。
这种现实见告我们必须以老实的办法思考我们的平台以及它们如何以及是否能够适应这种环境，而不是试图对其进行支配。

在大多数组织中，底层只有一个根本举动步伐层。
不可能说，“所有东西都在 Kubernetes 上”。
相反，更有可能看到 Terraform、Pulumi、云 API 以及 Chef、Puppet 等根本举动步伐即代码工具，以及大量脚本，一些是声明性的，一些是命令式的，等等。
如果平台要为组织供应真正的代价，它必须与所有这些内容协同事情。
在构建平台时，让用户能够以 X 作为做事的理念带来他们的代价至关主要。
你须要一个大略同等的 API，作为人们长期以来一贯在供应的代价的接口。
如果平台要在组织内部供应实际代价，这个 API 必须同时适用于旧资源和新资源。

紧张要点

做好应对繁芜性和遗留问题的准备。
办理这一现实的一些关键考虑成分包括：

适应，不要支配。
理解和方案平台将须要处理大量棕地内容。
为旧资源和新资源供应大略同等的 API第一天很随意马虎；第二千天很难

第一天，从头开始创建一些东西很随意马虎。
在第 2000 天，掩护第一天构建的东西要困难得多。
纵然经由精心操持，随着韶光的推移，组织中也会发生很多事情——人们离开并带走了大量的机构知识；层层叠叠，第 2000 天存在的东西与第一天截然不同。

如何应对这种情形？正如所指出的，一些寻衅是无法预见的，但组织和标准化为可管理的构造是第一步。
通过 X 作为做事的理念，将我们须要管理的内容纳入构造化设置，以便理解它们在哪里、它们是什么版本以及在那里安装了什么软件，可以做到这一点。
考虑将你供应的做事标准化，而不是共享代码库（一颗定时炸弹），这有助于确保用户参与进来，而不是承担他们的掩护噩梦。

紧张要点

第 2000 天可能比看起来更随意马虎。
考虑从第一天到第 2000 天，确保你的平台为用户供应做事的方法：

组织和标准化考虑构建运用程序很随意马虎，但掩护起来更具寻衅性共享代码是一个掩护噩梦；将事物作为做事供应（管理舰队，让每个人都参与进来，保持更新和安全）保持 5 个教训

无论组织处于平台工程旅程的哪个阶段，这五个教训都可以在评估和设计未来平台时派上用场：

产品思维：将你的平台打造成产品找到得当的抽象：将你的平台打造成适宜你的产品民主化你的平台：通过尽早从利益干系者那里获取尽可能多的代价，并在此过程中更随意马虎得到认可，使你的平台更加健壮。
处处都是棕地，处处都是繁芜：使你的平台能够适应遗留企业及其根本举动步伐和系统的现有繁芜性。
第一天很随意马虎；第二千天很难：尽可能组织和标准化平台的各个方面，以确保从第一天到第 2000 天及往后的易用性和可掩护性。