声明式接口如何推动基础设施普及

F5生态系统 | 2018年11月12日

API已成为新的CLI。但在决定构建哪种API时,声明式方法占据主导地位。

API(应用程序编程接口)是当今的一项关键能力。组织在业务层使用API,以促进合作伙伴集成,并推动所谓“公民开发者”开展创新。应用程序也使用API,以简化集成,并将可能频繁变化的业务逻辑与不应频繁变化的接口解耦。基础设施同样使用API。从交换机到路由器,从应用服务到中间件和数据库,构成交付和部署管道的基础设施均已启用API。

这一点本身就值得我们停下来思考:它对日益壮大的NetOps社区意味着什么?因为组织往往会采用少数几种关键的标准化应用基础设施组件,但不太可能只采用少数几种关键的标准化网络和应用服务基础设施组件。

在组织用于提升应用速度和安全性的平均16种不同应用服务中,可以确定,这些服务由多个基础设施组件提供。即使我们宽松地假设每个组件可提供3种应用服务,仍需要5台不同的设备,并涉及5个不同的API。

问题在于,基础设施提供商往往过于照字面理解“API是新的CLI”这句话。也就是说,API只是CLI的REST化映射。

任何使用过不同基础设施组件CLI的人都明白,CLI的导航结构与基础设施的对象模型高度对应。API往往只是将这种设计原样迁移到HTTP。因此,要使用API,就必须同时了解相关设备的对象模型。

这种抽象层级阻碍了自动化和编排的发展,因为我们现在不仅需要寻找自动化人才,还要求他们对五种或更多不同的网络基础设施模型具备一定的专业知识。所需的专业能力通常还包括领域知识,既要对VLAN配置和路由有基本了解,也要理解虚拟服务器、虚拟IP地址、节点、成员和池之间的关系。

暴露基础设施的底层复杂性,不利于推动采用和实现自动化。接口应对模型和逻辑进行抽象,使用户和运维人员无需面对这些复杂性。GUI正是如此,它让用户无需浏览对象层次结构即可配置简单的服务。

因此,当发现API又带回了这种导航噩梦时,往往令人沮丧。

这一问题并非网络和应用基础设施所独有。例如,MuleSoft在其《API价值日益提升》研究中发现,客户和合作伙伴对API集成需求最高的是“满足特定业务需求的定制API”,占受访者的47%。其后依次是更完善的文档(19%)、“无代码”集成模板(19%),以及针对所需和所用API的SDK封装程序(13%)。

所有这些需求都可以归结为一点:简化。而在技术领域,简化意味着抽象。

这就引出了本文的核心观点:声明式接口正是这种抽象。通过简化当前用于预配、配置、管理和集成基础设施的接口,声明式接口让更多人能够使用基础设施,并创造更多机会。

声明式与命令式

一般来说,声明式和命令式都可以视为API的类型。通常提到API时,想到的就是命令式API。它会明确告诉目标系统如何执行某项操作。例如,要添加虚拟服务器,就需要明确告诉系统具体如何操作,即使这需要分别调用API五次、十次甚至更多次。

这意味着需要指示系统创建一个具有相应属性的特定对象,例如带有IP地址的节点。然后,还必须另行指示系统创建该节点将分配到的池,并为池命名。接下来还要……相信您已经明白了。命令式API要求用户不仅要了解系统及其对象模型,还要掌握实现预期结果所需的步骤。

这就是使用命令式API所要付出的代价。

总体而言,命令式API并非不好。在构建GUI,或与需要命令式API所提供的精细控制能力的其他系统集成时,命令式API非常重要。我们同样需要命令式API,只是不适合面向NetOps和DevOps的自动化与集成。

但对其他人来说,无需了解如此深入的细节。事实上,要求具备如此深厚的知识可能会让人望而却步,并拖慢自动化和编排工作的进度。这显然不利于降低基础设施的使用门槛,也不利于为DevOps和开发人员提供自助服务模式,更不用说特定基础设施领域之外的NetOps人员了。

这正是声明式API发挥作用的地方。

声明式接口指定的是要做什么,并由系统自行确定逻辑和工作流。因此,无需明确指示系统创建节点和池,也无需对所需对象执行所有正确的逻辑,只需描述这些对象及其关系即可。

一些声明式接口使用JSON,另一些使用XML,还有一些甚至仍采用简单的表单数据。它们的共同点是,都假定数据以简单直观的方式描述对象,使用者几乎不需要了解对象模型和系统层次结构。

例如,此声明具有较好的可读性。编写此声明需要对对象模型有基本了解,但无需获得特定产品的认证:

"web_pool": { "class": "Pool", "monitors": [ "http" ], "members": [ { "servicePort": 80, "serverAddresses": [ "192.0.1.10", "192.0.1.11" ] } ] }

声明式接口的价值正体现在这里:它减少了所需的领域知识,并降低了基础设施置备和配置的复杂性。随着专业技能要求降低,NetOps不仅可以更快速、更高效地工作,还能鼓励DevOps和开发人员充分利用这项能力。

将声明式接口作为基础设施管理的标准方法,可以立即扩大可用人才范围,帮助实现自助服务和高级自动化功能。上述声明式接口几乎无需解释,DevOps和开发人员即可理解并使用。相比之下,命令式接口需要投入更多精力来学习基础设施特有的模型和工作流,之后才能取得预期结果。

声明式接口简化了基础设施的置备、配置和管理,使部署流水线自动化以及系统与其他基础设施服务的集成更加便捷,从而让更多人能够使用和管理基础设施。基础设施的普及有助于实现更快速、更智能的自动化,并促进不同运维领域之间的协作与配合,而这正是充分发挥NetOps和DevOps模式优势的必要条件。

分享
标签: 2018

关于作者

Lori Mac Vittie
Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师,在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构,还是探索可扩展系统的极限,她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前,她曾担任技术编辑,并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位,著述颇丰,出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏,并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章

相关博客文章

SOAS 2025:目标不一致,结果难出色
F5生态系统 | 2025/05/13

SOAS 2025:目标不一致,结果难出色

AI部署缺乏协调会导致效率低下。了解如何协调安全、自动化和部署策略,充分释放AI潜力。

AI应用的应用交付与安全:驾驭现代AI架构
F5生态系统 | 2024/08/22

AI应用的应用交付与安全:驾驭现代AI架构

了解生成式AI应用和API安全如何塑造现代应用交付与安全。

借助多云网络简化超级云
F5生态系统 | 2023/09/13

借助多云网络简化超级云

超级云不只是一个流行词。它代表着一种简化愿景,以多云网络为起点,支持跨云提供商的混合IT。

2023年应用策略现状:成本与复杂性是推动多云网络发展的首要因素
F5生态系统 | 2023/03/15

2023年应用策略现状:成本与复杂性是推动多云网络发展的首要因素

多云网络解决方案可在核心、云和边缘环境之间实现无缝、安全的互联,为解决当今混合IT面临的挑战提供支持,因而备受业界关注。

运营演进的必要性
F5生态系统 | 2022/01/11

运营演进的必要性

在数字化成为默认模式的世界中,运维仍然过度依赖人工方式,需要不断演进,才能支持自适应应用。这一演进要求整个IT体系进行重大变革,并具备由AI赋能的自适应能力,以保持可用性、优化性能并保障安全。

多云并非简单使用多个云:让跨云衔接更轻松
F5生态系统 | 2021/10/07

多云并非简单使用多个云:让跨云衔接更轻松

随着企业转向互联云战略,工作负载的管理和保护变得日益复杂。了解F5如何满足市场对多云网络新方法的需求。