“单一管理界面”之误区

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

从我记事起（而且这段时间可不短），IT行业就一直被一种愿景所吸引：通过单一管理界面查看和操作基础设施。它就像圣杯一样，始终无人寻得，以至于许多IT专业人员开始怀疑它是否真的存在。

数字化转型彻底终结了这种虚无缥缈的管理模式，取而代之的是一种新的模式：单一控制平面。

好消息是，与过去勇于探索的IT人员所追求的单一管理界面不同，单一控制平面或许已触手可及。这是因为它并非基于GUI，而是基于API。

而且，这并非普通的API，而是声明式API。

要理解其中的原因，让我们回到2010年，当时“基础设施2.0”这一术语正流行。

架构的最底层是基础设施2.0。基础设施2.0旨在促进网络和应用交付网络基础设施的动态调整与协作。它让传统上在通信和管理方面彼此孤立的数据中心基础组件具备连接和协作能力。这主要通过基于开放标准的API实现。这些API提供一组精细的操作功能，可通过编排系统、自定义应用等多种编程方式调用，也可通过与传统数据中心管理解决方案集成来调用。基础设施2.0旨在从管理和运行时（执行）两个层面提升网络的智能化程度，但就其与云和IT即服务的关系而言，重点主要在于管理。

Infrastructure 2.0涵盖各类基础设施的服务化，包括路由器、交换机、负载均衡器和应用加速组件，以及防火墙、Web应用安全组件和服务器（物理和虚拟）基础设施。归根结底，其核心就是支持API的组件。

摘自<https://devcentral.f5.com/articles/infrastructure-20-cloud-it-as-a-service-an-architectural-parfait>

听起来很熟悉？如今，我们不再称之为Infrastructure 2.0，而是使用“持续部署”“自动化”等DevOps术语。但其理念并无不同。这一理念本身也解释了为什么“单一管理界面”始终未能实现。因为要实现这种理想化的架构，单一解决方案必须整合（通过手动方式集成）大量网络、应用服务和安全解决方案。

这根本不可能实现。

坦率地说，即使大部分基础设施都已支持API，这也从来不可能实现。为什么？因为这些API全都是命令式的，与各设备对象模型的紧密耦合程度不亚于其GUI。命令式API本质上与设备或服务特定的对象模型绑定，使用者必须具备丰富的运维专业知识。现在，设想一下贵组织中那位身兼多职、深受信任，负责跨多个供应商对路由器、交换机、安全设备以及五类不同应用服务进行运维管理的IT人员。

没错。这样的全能型人才就像大脚怪一样，常听人提起，却从未有人证实其存在。

这是什么意思？我的意思是：

例如，我们表示池、VIP（虚拟IP地址）或VLAN（虚拟局域网）的方式，与Cisco、Citrix或Juniper表示相同网络对象的方式并不相同。事实上，我们使用的术语甚至也可能不同；我们使用“池”，而其他ADC供应商则使用“场”或“集群”来表示同一概念。再加上虚拟化，又会引入一套术语，而且往往与网络基础设施供应商使用的术语相冲突。对于应用交付供应商和虚拟服务器虚拟化供应商（例如VMWare或Microsoft）而言，“虚拟服务器”的含义截然不同。

摘自<https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards>

这正是我们无法拥有统一管理界面这类理想工具的原因。因为整个行业并没有一个统一的视角来查看基础设施，而这正是它看待基础设施的方式。

但本文并不是要让您感到沮丧，也不是要让IT永远困在逐台设备管理的困境中。恰恰相反，声明式API，真正的声明式API，可以实现统一的控制平面。

但要实现这一点，我们需要摒弃这样一种观念：声明式就是用JSON或YAML对设备配置进行编码。这并非真正的声明式，因为它仍依赖与特定设备对象模型绑定的运维领域专业知识，其他系统无法获取并使用这些配置。

下面以Kubernetes Service和Endpoint资源描述为例，说明声明式模型：

配置虚拟服务器所需的一切都在这里，都包含在这些非常简洁且与具体实现无关的定义中。externalIP是虚拟IP地址，也就是用户或移动应用将与之通信的地址。名称“my-Service”描述了一个虚拟服务器，其中spec提供网络详细信息，例如要使用哪些ports以及哪个池（“MyApp”）。Endpoint资源描述组成“my-service”的各个节点，并为池“MyApp”提供成员。这里只缺少一种方法，用于为支持轮询之外其他算法的服务选择负载均衡算法。我们可以轻松扩展服务描述中的“spec”部分，加入“algorithm: RR | WRR | LC | FR”选项，使其普遍适用于所有负载均衡解决方案。这样就完成了。

理论上，我可以将同一资源提供给10种不同负载均衡解决方案中的任意一种，每种解决方案都会自行确定如何对描述中的意图进行建模和实施，即配置一个位于80.11.12.10的80端口上的虚拟服务，将HTTP请求分发到位于1.2.3.4和2.3.4.5的80端口上的两个应用实例。

也可以这样理解：“我想要一份意大利辣香肠披萨”和下面这种更繁琐的说法之间的区别：“请先和好披萨面团，再把它擀成直径10英寸的圆形。涂上番茄酱，再铺上马苏里拉奶酪，然后在最上面铺满意大利辣香肠。以425华氏度烘烤15分钟。”

其中一种方式更简单，让您不必了解具体细节。另一种方式则要求您不仅要知道自己想要什么（意大利辣香肠披萨），还要知道如何制作。这正是运维专业知识。

与点披萨类似，Kubernetes资源描述是通用的。它不会强制接收此资源的设备采用任何特定的对象模型或实现方法。它描述了需要具备什么，但完全不限制我可以如何实现。

真正的声明式方法，需要提供传达意图和期望最终状态的方式。未来某一天，我们只需说“为‘my-app’配置虚拟服务”，配置即可完成。借助元数据、应用标签以及自动化智能发现，该服务将自行完成从上到下的全部配置*。

如果要实现单一控制平面这一理想目标，就必须潜心制定中立的声明式规范，从而无需通过命令式API逐一集成数据中心内的每台设备。因为逐台设备进行API集成与逐台管理设备并没有本质区别。

我们都希望拥有更好的解决方案，也希望实现统一的单一控制平面。但要实现这一目标，业界不能只是口头认同声明式方法，而必须认识到：如果其他任何人都无法接入并使用您的声明式接口，那么它从根本上就不是真正的声明式接口。

*梦想总是要有的，不是吗？

关于作者

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

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

Lori Mac Vittie 的更多博客文章