ING 通过更好的开发者体验缩短上市时间

当 ING 最初着手加快上市速度时，他们把重点放在技术解决方案上。但是“平台即产品”的思维方式和 DevEx 让他们实现了目标。我们一再强调，平台工程本质上是社会技术性的。如果没有真正了解开发人员体验，该技术就无法为开发人员提供支持。

这是 ING 在荷兰金融服务公司技术过渡期间学到的教训，因为它希望使15000名 DevOps 工程师能够通过一系列平台更快地向全球30万客户发布产品。

“我们的主要目标是为用户提供专注于其核心目标并轻松操作应用程序的能力，而无需担心底层技术，”ING 技术平台产品负责人 Amir Abadir 在 PlatformCon 的演讲中表示。“这样我们的开发者社区可以在平台的基础上进行构建，并与他们的独特主张保持一致，利用产品和服务可重用性的优势。”

请继续阅读，了解 ING 工程如何设定技术目标，但由于最初构建的平台解决方案只会增加复杂性和上下文切换，因此他们重新关注开发人员的体验，并采用平台即产品的思维方式。

01 平台是如何构建的

Abadir 说：“我们的主要重点是通过流程自动化、更轻松的解决方案组装、集成和简化开发人员在我们的平台上构建解决方案的流程，来增强开发人员在技术平台上的体验。”

他的团队认为，这种方法应该实现以下：

• 缩短上市时间。

• 始终如一的高质量产品和服务。

• 提高生产力。

• 降低与维护服务相关的成本。

最后，他说他们的主要目标是“让开发者社区更快、更有意义地接触客户”。这也促进了基础性服务的创建，包括：

• 在 API、Web 和移动式流水线上运行的 800 多个应用程序。

• 运行超过 1000 个 API 的服务网格。

• 包含 1200 个服务应用程序、300 个 Web 和移动应用程序、2000 多个前端组件的 SDK。

• Kafka 事件上的 5000 多个主题，每秒有70万条消息。

• 每月通过电子邮件、短信和应用内发送 140万条通知。

ING 还发布了一个统一的设计系统（UDS），包括创建统一开发者体验所需的所有工具、指南和可重复使用的组件。

该平台团队还发布了所有应用程序的认证和授权服务，用于每月超过 400 亿次的客户登录，或每秒 400 次的登录，所有事件处理每天都涉及高达上百万次的批准。

但这一技术壮举并没有转化为更高的开发者生产力——如果有的话，它可能会导致上下文切换的增加。

02 大规模平台挑战

虽然 ING 能够通过其开发者门户中的数百个可重复使用的组件显著缩短上市时间，但将服务整合在一起的复杂性和花费在手动、重复配置上的时间依旧会使开发速度减慢。

平台工程在一定程度上，旨在为工程团队提供决策和所有权。但重要的是，集中管理才是促进沟通和设定期望的关键。Abadir 解释说，不同平台集成的复杂性最初几乎抵消了平台的所有好处，并导致了高周转时间。

“工程师不知道从哪里开始，下一步该做什么，在集成服务时与谁交谈，哪个团队提供平台的哪个部分。这导致了一种不连贯的体验。”他继续说，“工程师仍然没有在工作中释放乐趣，这影响了创新能力。最终，将所有必要配置和控制的‘简单应用程序’部署到生产中需要六到七个月的时间。”

Abadir 的团队意识到，它必须致力于创造更统一的开发者体验，而不仅仅是另一个开发者门户的急救带，更需要优先考虑整体开发者体验。也就是说，在构建技术之前，他们必须专注于人。

以前，他们提供的是一些精选的服务，但现在他们的目标是提供一个全面的平台。

“我们开发人员的整体体验才是最重要的，而不是我们作为平台提供商将其视为一堆集体服务”，他们的消费者必须尝试将不一致的产品和服务拼接在一起。他继续说道：“我们的成功取决于平台的整体体验，而不是孤立开发的产品。”

03 自助服务开发人员体验的策略

平台团队将注意力转向与之交互的主要工具，以重建更好的开发人员体验。首先是扩展 CI/CD 流水线，以使其“更丰富”，围绕开发团队尝试部署的共享资源对其进行定制和标准化，如 Web 和移动应用程序、通过 API 提供的服务、小部件和流等。

ING的新战略专注于所有自动化机会，工程师不再需要手动配置产品和服务。相反，他们可以使用带有命令行界面（CLI）的流水线来自行配置服务。他们使用“左移方法”，Abadir 解释说这是将配置作为代码，“而不是我们试图不一致地配置的断开连接的门户。

例如，如果开发人员尝试构建一个后端服务应用程序，他们会在存储在存储库中的 YAML 文件中定义该程序，然后将其推送到配置管理器中的流水线，配置管理器受到 Kubernetes API 的高度影响。此配置管理器接收有关配置更改的所有传入请求，然后根据开放策略代理（OPA）对配置请求进行授权和验证（或不授权）。如果一切都正常，配置管理器就会将此代码移动到 Kafka 事件总线上，不同资源的所有不同控制器将处理此请求，包括创建命名空间和配置虚拟机或 CHP 实例，所有这些都根据开发人员的用户偏好自动配置的。

04 平台团队创建导向

此外，他们还有一个“管理驾驶舱”，开发人员可以在其中监视和管理他们的所有应用程序和依赖项，以及旨在避免任何开发人员从头开始构建某些东西的向导。

“把这个（向导）想象成一个简单的步骤方法，我们带领开发人员通过意图来尝试看看他们想要构建什么，”Abadir说。“这些优化的路径进一步提升了工程师的体验，而这些向导的最终结果将是用户需要存储在 repo 中的一堆YAML，”所有的修改都将在 YAML 中进行，然后被启动回向导。

现在，虽然还没有全部集成到一个平台上，但他们已经创建了集成，以促进技术、基础设施和工程平台之间的协作和一致性。这种合作允许在几分钟内快速配置资源以及环境的衍生和设置。

最后，他们还拥有一个开发人员门户网站来自助服务，该门户网站提供服务目录，鼓励可重用性和一致性，并在整个解决方案生命周期提供广泛支持——从发现和设计到开发，一直到发布。

他们对开发人员体验的总体目标变成了：

• 将准备时间缩短至15钟以内。

• 消除手动、不一致的服务和产品配置方式（如电子邮件和票证）。

• 统一开发人员体验。

• 以平台即产品的思维方式关注开发人员的旅程。

• 改进整体文档、培训、反馈管理和支持。

Abadir 表示，通过实现这些目标，他们可以更好地实现最初的目标，即缩短上市时间、提高质量、提高生产力和降低服务成本。

原文链接：

https://thenewstack.io/how-ing-cut-time-to-market-via-a-better-developer-experience/