简要概述
即使是最先进的组织在面临日益严重的人才短缺时也难以扩大其开发产出。因此，企业和开发团队开始从内部开发平台的角度来看待他们的基础设施，以掌握这些挑战并加速规模化的交付。领先的分析公司如Gartner，思想领袖如Martin Fowler，供应商如Humanitec和Upbound，以及技术巨头如苹果、Netflix和Twitter，都已经开始了围绕内部开发平台的讨论。这篇评论文章总结了不同的声音，提供了一个完整的底细，以及实用的建议和相关的参考资料。我们还将强调在企业层面上规划、实施和运作IDP的几个建议焦点。
内部开发者平台是一个重要的新概念，因为它解决了软件交付生命周期中的三个关键挑战。它
- 提供环境管理，从开发到生产，并集成CI/CD
- 集成可重复的模式，开发团队可以利用它们的应用程序
- 减少了开发和运营团队之间的事务性负担
通常情况下，仅仅雇用更多的工程师并不足以解决所面临的问题，也不足以支持企业组织的发展。我们将在后面更详细地解读这个问题。
云计算、容器化和微服务架构为组织提供了广泛的内部工具和系统选择，以完成对新环境的要求。内部开发者平台有望为开发团队提供足够的工具和资源选择，同时抽象出运营负担。直觉地或有意地，许多开发团队注意到了这些好处，而基础设施的责任则倾向于一小撮提供这种抽象化的不同的个人。通常情况下，企业并不知道他们实际上是在建立一个内部开发平台，或者至少是其变化。InfoWorld的Scott Carey抓住了这个概念，他将内部开发平台描述为 "雪花"，并指出 "没有两个是相同的。每个平台都因组织的堆栈、文化、代码库和工具集的不同而不同。
我们认为，内部开发平台的适应性是这个概念的核心要素。这也是内部开发者平台概念对于软件开发组织来说如此强大和有吸引力的原因之一。因此，我们将避免学术上的定义，而是强调我们在文献中看到的不同功能和实施模式，以促进进一步适应。
什么是内部开发者平台
社区驱动的网站internaldeveloperplatform.org为理解什么是内部开发者平台提供了一个很好的起点。
内部开发者平台（IDPs）由运营团队配置，由开发者使用。运营团队指定什么资源在什么环境下启动或在什么要求下启动。他们还为应用程序配置设置基线模板并管理权限。这有助于他们自动执行经常性的任务，如启动环境和资源，并通过执行标准使他们的设置更容易维护。
Brendan Kamp和他在Container Solutions的团队认为IDP"是一个工具系统，它可以相互整合成一个支持内部开发流程的中央平台。开发人员将其视为'内部平台即服务'"。
前面提到的Scott Carey的InfoWord文章也强调了IDP在开发团队的具体偏好方面的服务特性。
一个好的内部开发者平台应该抽象出基础设施的决定，实现自我服务的环境构建，与现有的持续集成和交付（CI/CD）以及部署流程整合，并分配基于角色的访问控制，所有这些都不需要开发者学习YAML。
内部开发者平台的价值功能
Watts S. Humphrey的标志性名言："每个企业都是一个软件企业"，这句话已经有近二十年的历史了，包括微软的Satya Nadella在内的许多CEO和战略领导人都重申了这句话，并提出了不同的看法。这句话强调了任何组织--无论其实际的行业垂直度如何--都需要为其软件开发团队提供一个适合的环境，以解决现代应用开发中具有竞争力的关键挑战。
经典的供应与需求问题
许多组织的云计算采用项目、数字优先计划和数字转型已经达到了前所未有的增长水平。这些举措给传统上负责为开发团队构建和维护平台的运营团队带来了巨大的负担。
简单地雇用更多的工程师或开发人员来减少整体积压，并更均匀地分配工作量，并不能解决问题。如果没有明确的流程和共同的理解，这将导致 "更多的人 "可能不会立即生效，因为每个组织的内部技术堆栈都是不同的；新的工程师需要时间来 "填补 "他们技能组合的空白，然后才能开始为团队增加价值。
减少团队的认知负担
参与软件交付的团队在日常工作中往往有很多任务和责任需要处理。内部开发平台提升了与各种日常任务相关的一些认知负荷。上下文切换带来的认知负荷经常被认为是开发者生产力损失的一个问题。开发者生产力专家Matthew Skelton和Manuel Pais认为上下文切换带来的认知负荷是团队表现得不堪重负的主要原因。在他们的畅销书《团队拓扑》中，作者对这个问题解释得非常好。"如果不考虑认知负荷，团队就会分散精力，试图覆盖过多的责任和领域。这样的团队缺乏带宽来追求对其行业的掌握，并在转换背景的成本中挣扎。"同样，来自Puppet的2020年DevOps报告指出，"大多数软件开发人员和运营工程师都明白，在两个上下文之间来回切换是一种巨大的认知消耗。这是有原因的，除了上下文切换的正常人类挑战外：每个领域的细节和思维方式都是如此不同"。
然而认知负荷在组织或项目规划期间很少被考虑。这使开发团队处于巨大的劣势，并阻止组织取得富有成效的胜利。内部开发者平台为团队提供了可重复使用的模式集合，让他们在一个单一的互动点上消费他们的角色。这减少了上下文切换的数量，从而降低了团队的认知负荷。
自主性和工具多样化的挑战
Evan Bottcher在Martin Fowler的博客上写道，他很好地解释了组织中的开发和运营团队所面临的挑战以及内部开发者平台如何帮助他们。
......显然，一个好的平台的特点必须是它能减少积压的耦合量。该平台必须提供不需要提出票据和分配工作的服务。自助服务 是一个好平台的关键定义特征......平台应该为团队提供自助服务访问。具体来说，它应该允许对平台能力和资产进行自助式配置、自助式配置、自助式管理和操作 ......在自主式多样化和强制式整合之间找到合适的平衡点，而这在前期更是难以预测。
允许团队更快交付
多年来，以更高的速度交付高质量的软件一直是开发团队和他们所支持的业务的重点，这主要是由于消费者对新功能的需求，以及市场内的竞争。一些非常著名的例子表明，组织在其各自的市场中所面临的压力是AirBnB扰乱了酒店业，或Uber和出租车行业。这表明，公司需要能够做出反应，以保持在不断变化的市场中的相对地位，这催生了敏捷和DevOps，公司早在2015年就开始"踢DevOps的轮胎"了。
从那时起，许多公司，无论是云计算还是更传统的公司，都被称为 "高绩效的DevOps组织"，这是Puppet在其年度DevOps报告中提出的。这个术语考虑到了许多行业领导者和分析师的意见，即这些公司如何做才能更快地交付软件，并在各自的业务领域超越其组成。用来评估一个组织是否可以被认为是一个高绩效的DevOps公司的一些关键指标是。部署频率/进度、准备时间、等待时间和平均修复时间（MTTR）。
在2020年版的DevOps状况报告中，这些高绩效公司与采用内部开发者平台之间有一个明显的趋势。Puppet发现 "DevOps的进化与内部平台的使用之间存在着强烈的关系。进化程度高的公司报告内部平台使用率高的可能性几乎是中层组织的两倍，报告高使用率的可能性是低层组织的六倍"。
参与内部开发平台的团队
内部开发者平台传统上是由一个专门的团队建立和管理的，我们把他们称为平台团队。与平台团队一起，运营团队负责组织的技术需求，而开发团队则负责交付软件。我们将在下面更详细地分解每个团队、他们的需求和挑战。
平台团队
平台团队的组建是内部开发者平台在组织内成功的关键因素，团队的任务必须明确并确定下来。通过将平台团队定义为组织内的一个独立实体，他们的注意力就会变得很集中，这应该会减少他们在组织内先前的角色可能带来的一些事务性的负担。埃文-博彻再次强调。
"平台团队建立、部署、监控，并对平台组件和底层平台基础设施随叫随到...。理想情况下，平台团队甚至不知道平台上运行的是什么应用，他们只负责平台服务本身的可用性。"
在平台的建设和维护中，平台需要采用一种产品思维。我们将在博客的后面进一步深入探讨这个问题。
运营团队
传统上，运营团队负责一个组织的IT基础设施中的一些关键要素。与开发团队可能有少量的并发项目不同，运营团队的工作范围通常要大得多，管理多个环境、数据库、网络、云基础设施和其他许多构成软件解决方案的元素。
与此同时，运营团队还负责组织的实时环境，消费者和内部用户通常在这里与公司进行日常互动。这就要求在使开发团队和 "保持光亮 "之间取得有趣的平衡，以保证业务的运作。这些团队通常按照先进先出（FIFO）的原则工作，由一个票务系统管理，故障优先于其他任务。
2020年的DevOps报告强调，高效的DevOps组织需要投资于内部开发者平台，以实现开发者自助服务，减少运营团队的项目和事务性负载。许多组织在不知情的情况下开始向团队提供内部开发者平台的过程。组织将开始对特定的云进行标准化，或部署到Kubernetes或Openshift等专用容器平台上。在建立内部开发者平台的道路上，组织会玩一个又一个疏通依赖关系的游戏，试图在整个生命周期内改善软件的交付。 "如果你需要更快地发布，你就玩这个疏通障碍和消除瓶颈的游戏，并建立一个策略来解决这个根源，"Zalando公司前平台主管Jan Loeffler写道。
凤凰计划"和"独角兽计划"两本书的作者Gene Kim在AmbassadorFest的演讲中提供了一些有用的指标，运营团队可以利用这些指标来了解其内部平台的有效性。 丹尼尔-布莱恩特在Twitter上引用金说。
"对于运营团队来说，一个很好的衡量标准是你定期从应用交付团队收到多少'感谢'。最终的目标是解决反复出现的障碍，减少部署摩擦，并使之易于向客户提供价值"@RealGeneKim在#AmbassadorFest上的发言pic.twitter.com/bQfpAPvPA
- Daniel Bryant (@danielbryantuk) 2020年11月17日
发展团队
受益于内部开发者平台的核心团队是组织的开发团队。开发团队往往有庞大的任务，他们将新的功能推向市场，或建立组织日常业务的核心内部系统。
开发团队往往需要等待运营或DevOps团队为他们创建环境，以部署和测试他们的应用程序。如果没有一个集中的平台负责特定应用程序的CI/CD，开发团队往往会选择最适合他们的方式。这导致了 "整个组织的控制或审计能力有限"，Jan Loeffler解释说。这通常会导致整个组织内大量的工具蔓延，因为个别团队采用并在他们最了解或碰巧喜欢的工具上建立自己的工作流程。除了这可能造成的工具蔓延，它还可能导致有严格的区域或PCI要求的组织出现大量问题。
Dave Sudia说，在2020年北美KubeCon大会上，许多与会者都强调了开发人员对基础设施自助服务的需求。
在构建平台的背景下，应用开发者是关键客户，可用性是开发者体验的重要部分。除非开发者有能力快速、安全地配置平台如何运行他们的服务--同时配置应用程序如何发布给最终用户--否则云原生平台的价值将不会被完全实现。
如何开始使用内部开发者平台
通常情况下，团队会先将CI/CD、基础设施即代码和Kubernetes的方法正规化和标准化。这些技术构成了大多数内部开发平台的构建模块。将平台作为一个产品建立起来是建立一个成功的内部开发平台的一个关键组成部分。
Evan Bottcher强调了建立一个成功的IDP的三个关键先决条件。
- 平台是一个产品，需要一个长期稳定的产品团队，负责构建和运行。
- 你必须愿意将应用的部分或全部运行责任转移到应用团队中，而不是集中的运营和支持。
- 第三，你必须愿意在严格的执行一致性与你交给自主应用团队的自由和责任之间进行权衡。
与此同时，Micheal Coté在他关于"业务瓶颈"的报告中强调了为什么产品方法是成功的关键，他将内部开发者平台确立为一种产品。
产品方法关注的是软件的整个生命周期：软件是否有用，它是否能帮助客户和用户，从而帮助企业？一切都围绕着收集客户和市场反馈，并相应地不断改变软件。
虽然这是为那些业务依赖于交付软件的公司写的，但它也适用于内部产品，它给了团队一个任务来管理他们的交付物，就像他们在与外部客户互动一样。
Camille Fournier在她的Medium文章《内部平台的产品》中写道
无论你是一个平台工程师，工程经理，还是PM，都要记住，你仍然需要以客户为中心，对你的平台产品进行策略。如果没有一个明确的战略来展示影响和价值，你最终会被忽视，人手不足，而且再酷的新技术也不能解决这个问题。
内部开发者平台的关键组成部分
内部开发平台（IDP）是一系列工具和系统的集合，它们紧密结合，为开发团队提供一致的体验。
这些平台通常是独特的，就像构建它们的团队一样，但有一些组件和模式在许多不同的企业中看到。Internaldeveloperplatform.org的团队将这些内容整理成一个简洁的列表（应用配置管理、基础设施协调、环境管理、部署管理、基于角色的访问控制）。我们将深入研究其中的每一个，并强调其中的一些关键领域。
应用配置管理
在多个不同的环境中管理应用程序的配置很容易变得复杂，特别是当应用程序是由一些不同的服务和平台组成的时候。内部开发者平台通常以与代码相同的方式管理应用配置：通过使用源代码管理平台来维护应用配置，允许有几个关键的功能，如版本和变更管理。
随着应用程序的复杂性增加，运行、部署和管理应用程序所需的配置的复杂性也在增加。通过扩大存储在SCM中的配置范围，它允许从一个中央位置配置外部的依赖关系，并对其相关的应用程序进行版本管理。
基础设施协调
内部开发者平台需要与组织内现有和未来的基础设施兼容。这是通过建立一个可扩展的平台来实现的。内部开发者平台通常会在组织的工具链中进行广泛的整合，包括管道、集群/服务器、网络（DNS、防火墙、路由）、注册表、工件库等。
理想情况下，内部开发者平台成为基础设施即代码的驱动力，允许以编程方式定义和管理解决方案中的组件。通常情况下，个人团队或DevOps团队已经通过Terraform或类似的方式建立和部署他们的基础设施。但是，将现有的脚本集成到内部开发者平台中，允许团队使用已知架构的目录。
环境管理
通常情况下，创建一个新的环境是平台能力、团队瓶颈、有时甚至成本限制之间的混合挑战。团队往往需要等待几天或几周的环境，甚至只是为了测试一些小东西。内部开发者平台以一种整体的方式来处理新的应用环境，将应用的所有依赖性集中在一个单一的环境中运行。这使开发团队能够在需要时访问自助服务环境。这极大地减少了瓶颈，使开发团队能够更快地交付。
通过利用内部开发平台的这种能力，其好处远远大于开发团队需要一个新的测试环境。它允许团队在需要时提出整个应用堆栈及其所有的依赖性，并在不再需要时销毁它们。这通常对云环境特别有利，因为服务的使用是基于消费模式的，而且大型环境，如性能测试环境的闲置往往是昂贵的。
部署管理
将软件交付给消费者是一个组织内任何开发团队的关键角色，对快速交付的需求是一个众所周知的挑战。持续集成和持续部署的采用给了开发更快、更频繁的部署，这往往伴随着自身的挑战和问题。
通过在开发生命周期中引入内部开发者平台，它成为所有自动部署到目标环境的中心点。内部开发者平台成为自动化的自动装置，负责部署的版本，以及围绕部署的相关项目。这种整合通常是通过使用webhooks完成的。
随着应用程序和相关元素的部署，内部开发者平台通常为所有部署的调试提供一个集中点，作为应用程序版本的集中点，允许从部署的同一地点执行回滚。
基于角色的访问控制
基于角色的访问控制（RBAC）是一个不可忽视的因素，也是任何平台都不能排除的因素，因为多个团队将利用一个共享平台。一个有效的RBAC政策将限制各个团队与平台的互动范围，成员也可以根据他们在组织内的角色进行隔离。
在管理允许哪些团队与平台互动的同时，它也限制了未经授权的个人可能获得的爆炸半径。在2021年Kubecon EU的演讲中，Ellen Körbes和Tabitha Sable深入探讨了与组织的Kubernetes RBAC政策存在缺陷有关的一些风险。会议中的一句话是："我们是由星星组成的，但你的RBAC不应该是"，这意味着在一个环境中不应该有对系统或资源的开放访问。
结论
最后，内部开发者平台是一个组织的数字化转型和增长的关键因素。通过允许开发团队专注于构建让客户满意的解决方案，并使公司在其目标市场上发展。但是，与组织内部的任何项目一样，需要对其进行衡量，以了解其对使用和构建团队的影响。内部开发平台在这方面也不例外。
一个成功的内部开发者平台的最大驱动力是在平台的创建和管理中采用产品思维，通过收集最终用户（开发者）的反馈，并在平台成长过程中把这些反馈纳入其中。
在旅程的每一步，关键是要找到下一个任务或问题，使开发和运营团队的注意力从他们的交付成果上移开。对于运营团队来说，这让他们有能力处理真正的业务关键问题，而对于开发团队来说，这让他们能够构建最终能让业务增长的功能或产品。
