随着云计算、容器化、DevOps和微服务架构成为现代应用程序开发的构建模块，对于内部软件开发部门来说，越来越重要的是需要一种简单的方法来管理这些资源。

谷歌、Netflix和亚马逊等很多精英工程企业认为，内部开发者平台(IDP，Internal Developer Platforms)减轻了DevOps部门的运营负担，同时为软件开发人员抽象出了不必要的决策。

正如前总统奥巴马只穿灰色或蓝色西装以减轻他的认知负担一样，使用良好内部开发者平台的开发人员可以只关注自己的代码和Git存储库，其他的则交给负责底层基础设施的平台。

什么是内部开发者平台?

内部开发平台就像雪花片，没有两个是一样的。每个平台因企业的堆栈、文化、代码库和工具集的不同而不同，这使得很难找到一致的定义。

正如ThoughtWorks工程主管Evan Bottcher所说，“很难用语言表示。‘平台’其实是一个非常模糊的术语，我们用来形容对提高大规模交付速度和效率非常重要的方法。”

Bottcher自己的定义(他更喜欢术语“数字平台”而不是“内部平台”)是：“自助服务API、工具、服务、知识和支持的基础，被配置为备受关注的内部产品。”

对冲基金Two Sigma的平台工程主管Camille Fournier认为，关键在于基础设施的软件方面。她在2020年关于这个话题的博客中写道：“像K8s这样的计算平台、存储系统、软件开发工具和服务框架都是任务的一部分。”

一个好的内部开发者平台应该抽象出基础设施决策，支持自助服务环境构建，与现有的持续集成和交付(CI/CD)以及部署过程集成，并分配基于角色的访问控制，所有这些都不需要开发人员学习YAML。

Humanitec公司的首席技术官Chris Stephenson曾在谷歌开发过内部平台，他在博客中写道：“一个有效的内部开发者平台的关键点在于能够把复杂的问题划分好。每个人都有自己擅长处理的一部分复杂问题，而其他人完全可以忽略这些问题。”

Redmonk的首席分析师Stephen O'Grady说，在过去一年里，他看到“有一种明确的愿望，那就是把工具链中必要的部分整合到一个平台上，开发人员可以在平台上编写应用程序，所有可能的复杂问题都被抽象出来了。”

内部开发者平台的好处

Puppet和CircleCI最新的《DevOps状态报告》将自助服务式内部平台确定为使成熟的企业DevOps部门与众不同的3个关键要素之一，其他两个是自动进行变更管理和集成安全性。

一个功能完备的内部平台应能够降低现代软件系统的复杂性，加快软件部署周期，创建更稳定的版本，提高开发人员的满意度和工作效率，同时降低运营负担。

谁需要内部开发者平台?

内部开发者平台有两个核心用户组，每个用户组都有自己的视角：平台/运行/DevOps团队和开发人员团队。

平台/运行/DevOps团队配置平台，为所需的基础设施和工具创建API接口，并建立访问与合规保护措施。平台本身通常由单个产品所有者配置，或者在较大的企业中由专门的内部平台团队配置。

在表现最好的企业中，该团队应该扮演产品所有者的角色，与开发人员协作以收集需求，缓解常见的痛点，并根据需要对平台进行迭代，所有这些都基于一组关键的用户指标。他们也应该善于在内部为平台进行宣传。

云咨询公司Expert Thinking的首席技术官James Whinn表示：“这种产品思维方式是内部平台成功的关键。没有它，团队可能会只专注于某些很酷的东西，而不一定能带来业务价值。”

然后，开发人员将得到一个精简版的平台，该平台将抽象出任何基础设施决策，以便他们能够专注于部署。

初创公司Humanitec成立于2018年，旨在帮助企业建立一个内部平台，该公司首席执行官Kaspar von Grünberg认为：“对于DevOps团队来说，它必须是灵活的，但是对于开发者来说，必须是不灵活的。所有定制功能都应该由DevOps团队承担，为不想考虑底层基础设施的开发人员创造捷径。”

但是这样做，我们不是又把开发人员和运行人员分开了吗?

Puppet的首席技术官Nigel Kersten指出，构建和使用内部平台的团队必须紧密联系在一起，以确保每个人都朝着同一个方向前进，就像在同一个团队一样。如果把他们分开，将最终重蹈开发和运行人员老模式的覆辙。

IDP与PaaS

平台即服务(PaaS)通常由供应商规定开发人员应怎样工作，内部开发者平台与之不同，它是基于开发人员团队已经熟悉的工具和流程构建的，但抽象性和一致性更好。

正如谷歌技术专家Kelsey Hightower在2017年的推特上所说：“我认为大多数管理基础设施的人只想要PaaS。唯一的要求是：必须由他们自己来构建。”

许多小企业借助于PaaS让他们的工程团队快速启动和运行，其中包括Heroku(在2010年被Salesforce收购)，或者OpenShift、Cloud Foundry，以及大型公有云供应商自己的工具等流行的选择，但通常会发现这些工具难以灵活地进行扩展。

选择IDP方法确实会让工程师们在有机会构建自己的平台时去冒险，或者更糟的是，他们试图像亚马逊或谷歌那样运行，这会导致精力分散，带来灾难。

Fournier写道：“即使那些大公司以开源软件的形式提供解决方案，他们也经常对可用产品的周围生态系统以及使用该产品的工程师的文化和需求进行各种各样的假设，而这些假设可能不太适用于你的公司。说‘谷歌做到了，所以我们也应该这样做’，这不是好的产品管理方式。”

Puppet的Kersten是谷歌前SRE(译者注：网站可靠性工程师，可简称运维工程师)，他也有类似的看法：“我们已经看到很多大企业试图采用小型自治团队的模式，这种模式在亚马逊很有效，因为他们有非常熟练的开发人员，但那里的一切都是作为服务构建的，它们不像传统软件那样受到监管或者限制。不过，对其他企业而言，这会造成混乱和企业债务。”

怎样开始采用内部开发者平台

从整体部署过程转变为持续交付过程是一项重大的文化变革，切不可低估。Bottcher写道：“我认为，用‘自己建设，自己管理’的心态来创办一家小公司其实并不难，但要实现转型则需要勇气和远见。”

Kersten已经看到太多的企业试图将现有流程重新包装为一个内部平台，因为这是最流行的。他说：“我们看到的最不同的一种模式是将中心IT重新定义为平台团队，但不进行必要的技术和文化变革。随着其越来越受欢迎，我们预计这种情况会越来越多。”

转移到内部开发者平台或者决定从头开始构建，这很难推广到更多的企业中——从说服管理层做出如此大的转变，到让开发人员适应一种他们无法完全控制的新工作方式。

Kersten说：“更大的问题是能够理解用户，并做出文化上的变革。”

他和其他很多专家的建议是：从小处着手。Expert Thinking的Whinn建议：“建立一个卓越中心，找出开发出的平台能产生真正影响的应用情形。”即使为单个应用程序搭建测试环境并从中构建出所需的API，也可以帮助平台团队走上正确的道路。

在2019年的DevOps企业峰会上，Team Topologies的作者之一Matthew Skelton说，考虑这一问题的一种方法是将其视为最简单的可用平台，或者“明确平台的哪些方面是重要的，一定不能超过必要的规模。我们需确保我们构建的任何东西都是有吸引力的，有很强的开发经验，并将用户视为我们需要与之交流的客户，以便我们能够理解他们的需求并满足他们。”

Humanitec的von Grünberg说：“无论开发或者购买，都是一样的：必须从底层开始。我们经常看到，企业会把一小群最好的工程师组织在一起，要求他们把相互隔离的工具链整合起来。然后，开始围绕团队可以使用的通用API来进行整合，并将结构引入到非结构化工具的海洋中。”