如何管理庞大且多样的API组合?——探索企业API治理之路

智能真的很好说 2024-09-27 16:22:48

  在当今数字化高速发展的时代,API(应用程序编程接口)的重要性日益凸显。然而,随着 API 数量的急剧增长以及设计风格和标准的多样化,企业面临着如何有效管理庞大、不同的 API 组合这一巨大挑战。

  API 增长趋势迅猛,多范式世界带来挑战

  近年来,API 开发呈现出惊人的增长态势。451 Research 在 2022 年的一份报告中指出,平均组织使用的 API 数量高达 15564 个,单年增长率达到了令人瞩目的 201%。Cloudflare 也宣称,其处理的流量中有超过 50% 是基于 API 的。这些数据充分表明,API 已经成为企业数字化转型中不可或缺的一部分。

  各种趋势共同推动着企业使用的 API 数量呈爆炸性增长。一方面,生成式人工智能、web3 和区块链等新兴领域的崛起,使得 API 在这些领域中发挥着关键作用。Kong 首席技术官兼联合创始人 Marco Palladino 强调:“API 是消费者和企业在网络上访问服务和数据不可或缺的一部分。在新兴领域,API 的作用尤为重要。” 另一方面,传统行业的数字化转型也对 API 产生了巨大需求。例如,现代移动开发严重依赖后端的 API 来促进机器对机器的通信。FireTail 首席执行官 Jeremy Snyder 指出:“实际上,每个移动应用程序都只是云中后端服务的前端,通过 API 来回通信。”

  然而,这种快速增长也带来了一系列挑战。这些集成点往往非常多样化和不受制,使得企业难以有效地管理和整合。随着 API 设计风格和标准的数量不断增加,大多数企业都面临着不断扩大的 API 组合。Axway 数字化转型催化剂副总裁 Brian Otten 表示:“几乎所有组织都在这样做。我最近与一家大型食品零售商进行了交谈,该零售商希望看到 REST API 以及基于事件的资源和 GraphQL。”

  此外,大多数公司同时使用多个 API 网关或管理工具。Gartner 副总裁分析师 Mark O'Neill 指出:“我们已经拥有 API 管理解决方案的组织正在购买 API 管理解决方案。在某些情况下,这是为了取代当前的平台,但在许多情况下,它是累积的。” 这种多范式的世界使得 API 治理成为弥合不同风格和避免庞大技术组合痛苦的关键要素。

  关键技术趋势影响 API 采用

  API 越来越成为许多软件开发趋势的核心,对企业的发展产生了深远的影响。

  在大规模的数字化现代化努力中,大型组织中网络应用程序的普遍现代化一直是一大驱动力。Curity 首席技术官 Jacob Ideskog 表示:“在过去的几年里,大型组织中网络应用程序的普遍现代化一直是一大驱动力。初创企业和快速移动者在这列火车上已经更长了,但更大的组织终于做出了转变,这推动了 API 的普遍采用。” 现代移动开发严重依赖后端的 API 来促进机器对机器的通信,同时,使用基于云的存储和数据库即服务产品也是以 API 为中心的开发的重要贡献者。

  合规性也是影响 API 增长的一个重要领域。例如,全球的开放银行法规促使银行创建或开放 API。Ideskog 说:“这通常是许多银行首次提供面向公众的 API。” 令人印象深刻的是,开放银行跟踪器现在对 500 多个开放银行 API 进行了编目。互操作性要求扩展到所有企业,近年来,由于企业与其合作伙伴和客户之间的互操作性需求,企业 API 的采用率有所增加。软件重复使用也是内部 API 采用的动力之一。

  API 还在帮助人工智能应用程序的开发。APIwiz 产品设计主管 Anurag Shukla 说:“API 通过为 LLM(大型语言模型)提供准确的数据,使人工智能系统能够做出更精确的响应,从而发挥着至关重要的作用。”Web API 不仅是最近生成性人工智能浪潮背后不可或缺的组成部分,而且多年来推动了低代码和无代码开发。

  此外,平台工程、可组合架构、微服务架构、单页应用程序、基于 OAuth 的安全系统、第三方 SaaS 应用程序集成、混合多云策略等领域也都有助于增加 API 依赖。简而言之,API 在企业软件开发趋势中普遍存在。

  大多数组织使用多种 API 样式

  REST API 风格仍然广泛用于内部或外部 API,主要是因为 HTTP 标准是众所周知的,许多工具都适合这种范式。然而,现代企业现在采用了各种 API 设计标准,从 SOAP 到 REST、GraphQL、gRPC、事件驱动架构等。LaunchAny 的 James Higginbotham 正在向 gRPC 迈进,以实现高性能的服务对服务通信,GraphQL 也在上升,以提高开发速度。Curity 的 Ideskog 也看到了 GraphQL 的使用越来越多。Ideskog 说:“它似乎在设计模式景观中找到了它的位置,当它有用时,什么时候它不有用。”

  WSO2 首席技术官 Asanka Abeysinghe 表示:“组织通常采用多种 API 设计风格和标准来满足不同的领域。这是因为不同的问题空间通常需要独特的方法。此外,一个组织可能会为金融、医疗保健或物流等领域部署特定领域的 API。”

  从功能角度来看,利用各种适合目的的 API 样式可能是有意义的,并可能表明越来越多的组织开始协作。此外,授权开发人员选择他们的工具有利于整体开发人员的体验。正如 HCSS 的 API 和数据产品经理 Michaela Halliwell 所分享的那样:“在我的组织中,这是由我们团队对其特定产品用例的自主性以及开发人员的偏好和专业知识驱动的。”

  然而,断裂的 API 景观并不总是有意的。大使实验室技术总监 Matt Voget 表示,当组织在没有根据组织标准调整不同团队的情况下转向微服务时,很容易发生碎片化。“一个用于管理用户帐户的微服务可能由 GraphQL API 支持,而另一个管理付款的微服务可能使用 OpenAPI 和 REST。” 在操作上,这可能会导致浪费精力。FireTail 的 Snyder 说:“在大型组织中,看到两个不同的开发团队在两个独立的业务部门使用两个不同的 API 标准解决了相同的用例并不罕见。”

  最近,多种样式的使用增加也可以归因于不存在的 API 治理标准。APIwiz 销售工程总监 Adeeb Tahir 说:“企业内部的 API 程序缺乏高效的标准化。这主要是由于在孤岛工作的团队,彼此的视野不够。一个太常见的结果是不一致的文档,通常与生产行为不匹配。”

  大部分公司兼顾多个 API 网关

  不仅内部 API 风格通常多种多样,而且组织经常使用各种工具来管理 API。WSO2 的 Abeysinghe 说:“组织同时使用多个 API 网关或 API 管理解决方案并不罕见。” 其中一个原因是整个业务的并行采购。不同的业务部门会根据其特定要求或支持 API 生命周期的不同阶段选择首选解决方案。

  此外,随着时间的推移,组织可能会发现自己不断发展其架构,循环使用各种工具来维护传统 API,支持新的微服务功能,或路由进入流量。API 网关是难以交换的组件,因此当时选择的任何技术都不太可能改变。这使得 API 解决方案在并购后更换变得棘手。

  典型企业的各个部分处于云之旅的不同阶段或多云,进一步影响了不同的 API 管理需求。一些组织正在迁移到 Kubernetes,但尚未完成迁移,因此迫使多个网关存在。此外,遗留实例通常需要遗留网关解决方案。在混合环境中,不同的网关针对特定本地基础设施进行定制。

  多网关条件背后的另一个原因是安全性和合规性。例如,同一组织将不同的 API 网关实例应用于单独的内部、合作伙伴和面向客户的 API 客户端网络流量。这些多个 API 网关实例减少了可能影响不同级别操作的级联故障,同时减少了进行监管审计所需的时间和资源。

  简单地说,当你有很多团队在构建 API 时,你很可能会有多个 API 管理解决方案。FireTail 的 Snyder 说:“如果其他开发人员和安全团队都有良好的集中文档和可见性,这是可以接受的。但它也会带来挑战。”

  如何管理不同的 API 场景

  许多高管认为,治理对于避免技术蔓延是必要的。API 治理旨在为定义不明确和多样化的API 世界带来更多结构。

  记录并统一您的 API 目录首先发现并记录您的所有服务。如果可能的话,采用规范优先的方法。实施一个流程,在规格文件中描述所有不同的 API。适当的机器可读 API 描述,如 OpenAPI 定义,可以帮助可发现性,并用于样式指南、林特和合同测试。

  有一个中心位置来查看和管理定义很重要。有些人称这为 API 清单或目录。将产品组合与技术问题干净地分开。遵循 Gartner 所谓的联合 API 管理,即在不同的 API 网关和管理工具上建立一个单一的控制平面和治理层。最终,目标是创建一个统一的目录,以促进全企业使用标准基础设施组件和网关模式。

  整合各种 API 网关更好地处理 API 网关和管理工具及其使用模式。首先,连接所有孤岛的 API 网关,并收集现有的 API。其次,对这些进行编目并归属所有权,以便可以看到谁负责什么。

  API 管理工具在大多数企业中激增。用单个控制平面整合 API 网关可以提高一致性并使内部实践标准化。许多组织希望有一个单一的控制平面,用于与来自不同供应商的多个不同 API 网关合作。尽管这一概念在市场上的支持有限,但仍有有效的方法来促进跨网关的发现和可重用性。至少有一个统一的开发人员门户,允许联合 API 管理,以便来自不同团队的 API 可以在整个组织中组成和重复使用。构建单个视图也可以帮助您监控跨 API 的流量。

  集中设计和安全模式集中式治理框架跨越了 API 生命周期的许多领域,并取决于由内部 API 启用中心领导的明确组织标准。从定义您的 API 标准开始,并建立一个用于执行和决策的集中框架。这可能是一群技术领导或监督治理的特定团队。

  API 治理应该在遗留服务中循环,但理想情况下嵌入到绿地开发的设计优先流程中。提高 API 程序成熟度的唯一方法是跨设计时间、构建时间和运行时阶段采用系统治理框架。这意味着组织遵循 API 定义和设计优先的方法,需要在设计和实施之前充分概述 API 策略。

  API 治理框架还必须考虑安全性。建立一个干净的身份层,专注于统一的客户标识符和一组定义明确的 API 请求权限。这可以实现更好的授权,从而意味着对使用的东西以及谁可以访问它的可见性更好。除了访问控制外,还可以对 API 标准强制执行林特,利用监控和分析工具,并应用速率限制来保护基础设施。

  不要忘记开发人员的体验API 治理团队应该建立反馈机制,并倡导开发人员消费者。引导 API 设计团队通过基于结果的设计流程,以确保他们思考解决方案,并与 API 消费者感同身受,以选择最适合的 API 设计风格。帮助设计师区分行业标准与基于供应商的标准有助于简化他们的决策。

  积极的开发人员体验还包括尽可能的自动化,既可以发现 API,也可以执行治理规则。使用自动化工具来收集有关 API 的数据,以及该用例所需的正确配置数据。使 API 提供商能够始终如一地管理 API,作为他们在 CI/CD 管道中自动化操作方式的一部分。

  有效 API 治理的好处

  API 治理可以为不同的 API 组合提供许多积极的结果。

  提高合规性和安全性有效的 API 治理确保了安全、可靠和可扩展的数字服务,支持业务目标和监管合规性。治理对于确保所有 API 都遵守严格的标准,保护它们免受漏洞侵害,并符合 GDPR 和 HIPAA 等法规,这是必要的。

  有了适当的 API 治理基础,可以避免影子 IT。如果没有为如何发布 API 和 API 可以访问哪些身份数据提供一个干净的结构,不同的团队将发明自己的解决方案,将新系统引入可能已经具备该功能的平台。定义不明确的访问控制策略是许多 API 计划的祸根。在 OWASP 的十大 API 风险列表中,身份验证和授权损坏排名靠前。解决这些领域的治理有助于跟上攻击者的步伐,攻击者越来越多地转向 API。

  避免浪费精力管理良好的 API 可以为数字景观带来更多的一致性。不受治理的 API 会导致 “资源浪费”,因为相同的问题被多次解决,而不是在平台上建立良好实践。通过适当的 API 治理,可以消除重复工作,并减少为项目寻找 API 的时间。

  在大多数情况下,正在努力减少扩散,统一和简化流程,同时降低许可和维护成本。其他人列举了更快的软件交付、降低许可和维护成本、更容易监控业务效率、更好的货币化潜力以及更精简的整体结果等好处。

  更一致的 API 设计坚实的治理确保 API 是一致的,并使用可预测的模式,使 API 更容易相互配合以及与外部接口配合。API 风格指南、林特规则和合同测试可以帮助减少缺陷或发现缺失的安全方案。如果没有这种治理,这些细节很可能会被忽视,导致严重风险。

  设置这些标准,并在可能的时候自动进行设计审查和检查,这极大地有助于 API 设计过程。这些措施还可以减少 API 生命周期中的重复性任务,并为未来的发展提供信息。有效的 API 治理使团队在开始设计和交付新的或更新的 API 时更容易做出默认决策。这也有助于该组织吸取过去努力的经验教训。

  更好的协作和业务协调API 治理框架到位可以改善与其他利益相关者的合作 —— 无论是内部还是外部消费者。提供一致且记录在案的 API 可以改善他们的体验,并使您的 API 具有易于使用的声誉。

  内部知识共享可以减少低效率,避免黑客化的变通办法。它还可以帮助提高业务利益相关者对 API 的认识。业务经理可以了解哪些 API 可用,以及哪个团队在管理它们。如果 API 存在于很少或没有治理的孤岛中,那么开发人员通常需要在商务会议上解释什么是可能的,什么是不可能的。

API 治理的未来

  API 环境在企业之间差异很大,集中治理的大多数努力仍在进行中。随着 API 组合的增长,对 API 治理的需求变得更加必要。过去十年来,微服务、无服务器功能和 SPA(单页应用程序)的采用只会导致企业 API 组合的规模倍增。

  展望未来,其他人预测了一个拥有更多行业 API 标准的世界。采用 OAuth、GraphQL、OpenAPI 和 AsyncAPI 等标准协议的推动力更强。人工智能将在 API 设计和推动自动化(如预测分析和自动合规)等方面发挥重要作用,这将大大减少手动治理工作。

  与此同时,急于整合人工智能功能可能会加剧已经膨胀的 API 目录。生成式人工智能将作为另一个 API 组合乘数。挑战在于 API 经济是否会重视建立必要的人员、流程和工具,以解决我们今天看到的 API 蔓延。

  新兴的平台工程学科可能有助于响应这一呼吁。我们还可能会看到更多与现有工具分离的统一目录出现。组织应该从执行可发现性和可发现性开始。出于安全和管理目的的 API 注册表可以与该开发人员门户不同。

  其他人认为,安全要求在 API 治理的未来中发挥着更大的作用。未来几年将从授权的角度看待治理。更好的授权工具将实现更强大的治理,并将成为 API 经济治理方面的一大驱动力。

  到那时,行业驱动的安全法规预计将全面鼓励更多 API 治理实践。我坚信,开放银行和医疗保健标准等日益增长的外部法规,加上对人工智能数据安全的日益担忧,将推动组织在其 API 计划中优先考虑严格的治理。

  然而,由于 API 治理的需求无法通过单一工具来解决,组织还需要文化转变。对于一些团体来说,这意味着委托合适的领导者来领导 API 标准。一个简单的事实是,如果正确实施,API 产品经理的存在会照顾 API 的正确性和最新性,这就非常好。

  总之,API 治理需要一种多方面的方法来提高整个组织使用 API 的可见性和控制性,这必须解决多方面的技术困境。无论你称之为治理、标准化还是平台战略,随着 API 的激增以及我们对可编译、灵活的微服务架构需求的增加,它只会对 API 经济变得更加重要。

https://www.infoworld.com/article/3529600/how-do-you-govern-a-sprawling-disparate-api-portfolio.html

0 阅读:0

智能真的很好说

简介:感谢大家的关注