简介

DevOps 团队仍在寻找尽可能高效地开发和发布企业软件的方法。虽然软件开发生命周期改变了应用程序的生成方式，但是 DevOps 团队必须保持利用这种现代实践的势头。这将需要寻找使开发团队的工作效率达到最大化的创新方法，以便开发团队在使用企业提供的资源的情况下以最优方式开展工作。其中一种创新方法是通过内部开发平台实现自助服务。内部开发平台具有各种优势和挑战，更多企业都在采用这种技术。

IDP/自助服务概述

内部开发平台（简称 IDP）是一层技术元件，使开发人员在使用其组织的现有技术的情况下能够独立地进行交互。这就为开发人员提供了他们运行应用程序所需的资源。这些资源包括但不限于容器镜像、数据库、日志、虚拟机或管道配置。

运营或 DevOps 团队通常负责管理公司的 IDP。他们会制定基线配置模板，防止编写会造成额外维护的非结构化脚本。这就确保开发团队能够通过可靠的平台，在生成软件的过程中集成现有工作流。除了管理平台之外，运营/DevOps 团队还负责搭建平台、为所需基础设施创建 API 以及设置访问和合规防火墙。API 能够使开发人员以编程方式访问该平台，因此是实现 IDP 的正常运行的必要元件。设置的防火墙确保 API 不会使用企业范围之外的工具，并尽量减少会在开发过程中出现的基础设施方面的问题。

IDP 通常使用编排工具作为平台基础。如今的 IDP 是在使用容器作为工作负载的情况下，在 Kubernetes 集群的顶端进行构建的。之所以使用 Kubernetes 构建 IDP，是因为该系统能够提供描述性地使用已知为清单的 YAML 文件的资源。IDP 需要制作关于其所需资源的清单，以便在集群中部署和使用该资源。此外，Kubernetes 的自定义选项的粒度，使 DevOps 团队能够配置工具来满足企业的资源和安全需求。另外，IDP 能够限制开发人员访问 Kubernetes 中的某些元件，允许访问特定命名空间的资源，或者在部署过程中测试应用程序代码，看看它是如何大规模运行的。Kubernetes 有足够的开发潜力，使其成为创建 IDP 的一种合格工具。

IDP 与 PaaS

IDP 为开发人员提供了用于构建和测试代码的平台，使其很容易被混淆为一种平台即服务解决方案。平台即服务（简称 PaaS）是一种能够在云中使用现成的整个平台或开发环境的服务，或者第三方服务。通过这项服务，开发人员能够在无需过于担心底层基础设施（类似于 IDP）的情况下构建应用程序。但是，PaaS 和 IDP 之间确实存在不同。最大的不同是 PaaS 解决方案通常要求建立伙伴关系，或者订阅第三方供应商。虽然可以在 PaaS 中进行一些自定义，但在大多数情况下，订阅者仅能使用供应商在平台环境中开放的配置选项。由于 PaaS 解决方案缺少使其软件熟练运行的必要特性，因此这会给需要应用程序与其现有技术资源实现集成的企业带来困难。

通过 IDP，企业可以加入其特有的工具和资源。尽管 IDP 提供了自定义功能，但它的缺点是必须手动进行构建；而 PaaS 解决方案已经由第三方完成了配置和管理。但是，IDP 是以开发团队已经熟悉的工具和流程为基础进行构建的，而 PaaS 则将要求团队在有效使用平台之前作出了解。由于伴随采用 PaaS 解决方案而形成的学习曲线会因服务而存在不同，特别是在进行故障排除或者调试应用程序代码时，因此这可能会导致更新完成的软件被延迟发布。

优势

使用 IDP 的企业会获得多方面的好处。以下介绍了 IDP 具有的一些显著内在优势。

推广自助服务

IDP 使得开发团队能够按照项目需求自行开展工作。由于开发人员能够自行开展工作，因此 IDP 所具有的自助服务减少了开发团队的操作负载。如此，DevOps 团队能够有更多的时间关注关键问题，并有效地维持其企业的技术资源。另外，IDP 设定了所有开发人员都能够使用的标准基线。开发人员可以选择其运行应用程序所需的工作负载，将修改内容应用到基线配置中，并启动部署。他们将了解到可用的默认配置，并在必要时基于这些配置进行扩展。如果经过编辑的配置不适合开发人员，则开发人员可以恢复到默认设置，几乎不会带来问题。推广 IDP 向开发人员提供的自助服务技术能够减少部署新功能的等待时间，缩短反馈回路，校准工具，以及提高劳动能力。因此，开发团队可以在不必依赖其他团队或与其他团队进行沟通的情况下持续部署应用程序。这样，团队能够交付出 NoOps，而无需对操作作出干预来管理将运行应用程序代码的基础设施。

DevOps 团队实现他们的目标。

DevOps 团队通常会遇到瓶颈。但是通过 IDP 及其自助服务，他们能够以更高效的方式实现他们的目标。

众所周知，DevOps 旨在提高企业生成的应用程序、基础设施和服务的开发和维护效率。幸运的是，IDP 能够使团队更容易地实现这些目标。 团队能够更快和更容易地交付出质量更高和更可靠的软件。该平台提供了支持应用程序所需的工具。DevOps 团队已经批准可以使用该平台。另外，由于应用程序的开发人员无需等待运营团队向其提供环境或云资源，他们可以只关注代码以及通过版本控制其工作的数据库。所有开发人员都同意，这样他们可以更快地完成任务，并提早完成工作，因此可以得到极大的缓冲。

治理与合规

IDP 还会为企业带来治理和合规方面的好处。一种切实有效的平台能够在使应用程序团队快速交付产品的同时，实现高效的 IT 治理。这是因为 IDP 使企业能够充分了解他们的资源，从而可以有效地使其技术策略与其经营策略保持一致。通过 IDP，也能更容易地实现合规。使用平台能防止合规团队在整个组织中被分散。团队可以从实际的中心来源（即 IDP）开展全部合作。IDP 能够确保平台上提供的资源满足其企业的经营和安全需求。人们只能想象 IDP 在公司内部各种技术资源的过度压力和管理下为多少支合规团队提供了帮助。

更关注企业

在 IT 领域，维护企业是非常重要的一方面。毋庸置疑的是，技术团队是维持企业经营的主要支柱之一。为了实现继续蓬勃发展，企业需要能够高效管理资源，这随着时间的推移会变得具有挑战性。这就是 IDP 可以帮助解决问题的方面。IDP 缓解了现代应用程序软件系统共有的复杂性，并减少了操作负担。缓解这些复杂性能够将更多的精力投入到实施使行业的利润和成功最大化的企业策略方面，同时使企业能够在最优条件下运行应用程序和系统。

另外，公司可以通过 IDP 试用新的配置和更新。这些配置和更新能够帮助公司持续蓬勃发展。提供即用型环境为在不同的经营模式下进行试用提供了更多机会。试用包括测试应用程序的新的 VM 配置或不同的服务器架构。因此，公司可以尽量减少由试用带来的技术风险，同时确定有效的经营模式。我们很难否认，修改试用内容可能会获得重要的资源，且在不影响整个行业的情况下，在回滚这些修改内容方面更具挑战性。因此，IDP 为企业提供了安全网，如果企业需要回滚默认配置的这些修改内容，则可以使用该安全网。

挑战

虽然 IDP 为企业带来了许多有利之处，但其自身也具有一些挑战。其中一个挑战涉及界定在平台中使用的技术堆栈。技术堆栈包括了用于构建或管理软件的应用程序的工具、编程语言和框架，是公司构建完成的服务的基础。IDP 需要加入技术堆栈来实现有效运行。很遗憾，所有公司并未使用统一的技术堆栈，即使不同团队中使用的技术堆栈也不统一。技术堆栈因其堆栈本身、传统、代码库和幂集而因组而异，这使得在构建 IDP 时，要对该堆栈作出一致界定是相当困难的。

另一项挑战是构建 IDP 本身。要构建 IDP，要求设立平台工程团队。该团队负责构建和管理该平台。在通常情况下，构建该平台的团队包括现有运营或 DevOps 团队。该团队需要确保在 IDP 中加入开发人员所需的所有元件。如果平台缺少几个元件，便使得这项技术很难为企业提供可靠的服务。此外，内部开发平台还必须能够集成新的开发工具和利用新的基础设施。但是，对这些瓶颈作出缓解对 IDP 而言可能是一把“双刃剑”。如果开发团队依赖于需要 DevOps 提供高度维护的 IDP，他们会在访问 DevOps 团队不断配置的内部 VM 或数据库方面遇到问题。因此，开发团队可能会在项目中受到内部资源可用性的限制。

企业采用

尽管在构建 IDP 方面有一些挑战，公司已经在其技术策略中采用该现代技术。根据 Puppet Lab 的《2020 年 DevOps 现状报告》，对涉及全球技术行业的 2400 余名参与者的一项调查发现，约 63% 的参与者都同意使用内部开发平台。鉴于公司持续扩展软件生成方面的 DevOps 实践，像这样的统计信息都合乎常理。事实上，研究人员在 ZDNet 上的一篇关于 IDP 的文章中指出，DevOps 的演进与内部平台的高利用率有很强的相关性。这些平台提供了 DevOps 团队寻求为其公司提供的自动化功能和效率，这就是 IDP 被广泛采用的主要原因之一。

GitHub、HelloFresh、Two Sigma 和 Twitter 等各企业在采用 IDP 方面都有其各自的原因。GitHub 的首席技术官 Jason Warner 指出，需要采用 IDP 的一个原因是企业“无法在 Bash 脚本上扩展高效的工程组织……”。Bash 等脚本工具仅限于使用工具的人员或服务以及脚本内部的代码。因此，任何新的工具和服务都需要不断重构脚本来以覆盖这些资源。GitHub 在采用 IDP 之后，便决定在  Kubernetes 中使用 IDP，形成名为 Moda 的编排工具。该工具不会考虑与 K8s 相关的所有事项，因此应用程序的开发人员便不会接触到这些事项。因此，GitHub 的团队能够尽可能高效地自定义和部署企业资源。那么 Kubernetes 仍然是首选的容器编排工具就不足为奇了。

HelloFresh 的高级产品经理 Samantha Coffman 指出，采用 IDP 的公司帮助解决了由于工程团队持续扩展而使软件越加复杂的问题。公司决定利用 IDP 能够在项目中容易地分配资源的能力，这项能力对于专门为最终用户提供杂货的公司而言是至关重要的。Two Sigma 采用的 IDP 中具有用于构建、测试和审核代码的 Git 环境，以及在容器中包装该代码的内部执行环境。其中，开发人员不考虑所有的基础操作、监测和合规要求。在平台中加入版本控制功能可以在需要时帮助回滚修改内容，这被视为 IDP 成为可靠工具的主要部分。

Twitter 以一种独特的方式看待它采用的 IDP 平台。它认为 IDP 为开发人员铺平了一套可以遵循的道路。这些道路消除了开发团队在开发新的应用程序代码或更新代码时可能遇到的困惑和决策疲劳。开发团队无需花时间来另外寻找哪些工具和技术能够支持其应用程序，这是因为这项工作已经由构建该应用程序的 DevOps 团队负责了。

IDP 工具

在通常情况下，在有新技术或做法出现时，DevOps 团队可以使用一系列不同的工具。但对于 IDP 来说，情况并非如此。内部开发平台后台的工具是专为构建该平台的企业定制的。GitHub 使用的 IDP 是一个内部编目，用于管理与服务级目标挂钩的服务。GitHub 为其工作流配置的服务编目并不适用于 Twitter 或 Two Sigma 等其他公司。否则，该平台便更像是一种 PaaS 解决方案，而不是 IDP 了。此外，IDP 的工具通常包含了只能在企业范围内进行访问的 API。这些 API 集成了可供企业的团队使用的技术和工具，以便全面地将维护和安全风险降至最低。

虽然 IDP 是专为使用该平台的公司设计的，但也有第三方云服务提供商提供了可帮助公司构建其自有 IDP 的公用设施。Amazon 使用了名为 AWS Service Catalog 的工具。组织可以使用该工具创建和管理批准在 AWS 中使用的 IT 服务的编目。虽然该工具适用于 AWS 中的工具和服务，但 DevOps 团队也可以通过该工具配置公司的应用程序所需的 AWS 资源，并使这些资源成为其 IDP 的一部分。例如，公司可以使用 Service Catalog 工具提供 Amazon EC2 实例、AWS 提供的虚拟机或配置用于满足特定需求的 Amazon RDS 数据库。当需要在应用程序中使用 AWS 服务时，开发人员可以使用该工具，并使用其中一种获批可用服务，以支持新的或现有的软件项目。

结论

内部开发平台已经被证明是企业使用的一种有用工具。由于内部基础设施和服务可用于减少企业资源的复杂性，IDP 使得许多技术团队能够更容易地管理软件开发生命周期。开发人员可以访问所需的资源，而运营功能能够使他们不必担心必须由开发团队处理其他资源请求的问题。总的来说，更多企业在采用并将继续采用 IDP 来支持软件。
点击了解 Incredibuild 加速构建的解决方案！

点击获取Incredibuild试用！