面向集成、微服务和API的快速创新-微服务集成

API开发和使用的快速增长丝毫没有放缓的迹象，API在跨行业数字业务中的核心作用也随着这一增长而继续激增。

最近一项针对IT领导者的调查发现，98%的人认为API是任务关键型的，81%的人目前正在使用微服务，18%的人计划很快这样做。

API的指数级增长使得当今的大多数软件要么使用API，要么就是一个API。API及其背后的集成和微服务已成为面向客户、员工和合作伙伴的新数字化渠道的基本构建块。

然而，你可能已经了解到，在过去十年中，大多数数字化商业计划（一些研究提到70%）都失败了。这些数字化举措要么没有带来所有预期收益，如新的收入来源、每客户收入的增加或利润的增加，要么没有带来任何收益。

关于为什么随着API数量和复杂性的增加，组织生产力降低，上市时间减慢，人们反复提出了两个主要原因。

第一个是关于人的：管理在Kubernetes等相对较新技术之上运行的现代云原生基础设施所需的开发人员和操作技能不足。
第二个是关于流程：由于所有使用API的人对安全、治理和协调变更的需求不断增加，DevOps流程的速度会减慢。随着API使用量的增长，管理数百或数千个API的复杂性可能变得难以承受，从而导致成本和安全风险的增加。由于开发团队被迫将更多的时间用于管理任务和治理，生产力往往会受到影响，发布时间也会延长，这会减缓创新和增长。

如果你深入挖掘根本原因，大多数时候是因为这些组织没有以一种允许他们快速创新和促进重用的方式一起设计、开发和管理他们的API、微服务和集成。这并不容易，因为：

随着开发或使用的API总数增加到数百甚至数千，管理所有这些API以及它们使用的集成和微服务很快就会变得难以承受。

好消息是，许多公司已经能够依靠几种常见的最佳实践快速创新。WSO2根据其在1000多家公司部署的经验总结了这些建议。

你无法购买吸引和留住客户的独特体验，而是必须构建它，并随着时间的推移不断改进它。我们称之为“数字化体验工程”。你的团队、技术和流程都需要专注于快速构建和改进这种体验。

如果你希望API使用者（开发人员）采用你的API，则需要将API视为产品。从外部到内部设计每个API，以改善API使用者的体验。（不要将现有集成或接口公开为API。这是一种由内而外的设计）。

每个好产品都有一个产品经理。为每个外部API指定一名产品经理，该经理将从头到尾负责该API。

在数小时内开发API的唯一方法是，如果大部分工作涉及重用现有组件，这些组件是专门为在API开发期间重用而设计的。API主导的设计意味着每个API、服务和集成都应该是可重用的、松耦合的。大多数更改应该能够在单个组件内进行，而不会影响其他组件。

让核心团队提供一个完整的云原生数字平台，作为一个易于使用的共享服务。它应该为API和应用开发团队提供简化的DevOps和CI/CD工具，将服务开发、集成和API管理结合起来。

你需要支持不同类型的开发人员和技能集。虽然你应该让开发人员易于创建新的API，但也需要让其他人易于重用、集成或组合API，以便广泛采用。

虽然支持不同的开发人员需求以最大限度地提高采用率很重要，但你应该为开发人员提供至少一个首选环境，该环境将围绕数字平台的所有最佳实践编成代码，并简化DevOps，以帮助简化快速创新的道路。

所有需要重用的东西都需要易于发现、学习、采用和随时间变化。这至少需要一个开发人员门户。然而，理想情况下，你还应该在开发环境中提供一个开发人员市场，允许添加组件和其他编码。

使安全和治理流程成为尽可能简化和自动化的通用DevOps流程的一部分。如果你将API发现、API设计、API安全和API生命周期管理构建到开发过程中，将增加重用，加快新API的开发，降低返工量，而不仅仅是取消手动“固定”的后期开发过程。这将有助于更快地交付API。

每个团队重新发明自己的Docker/Kubernetes基础设施或多级CI/CD管道没有任何优势。使他们能够轻松地将API、集成和服务作为复合API或应用程序一起开发、部署、监控、保护和管理。尽可能将云原生部署的复杂性抽象掉。

数字化之旅是各不相同的，也是不易的。但如果你遵循这些规则，成功的机会就会大得多。