单一玻璃的神话

从我记事起——而且我记得很长一段时间了——通过单一玻璃窗口来查看和操作基础设施的诱惑一直吸引着 IT 人员。 就像圣杯一样，它从未被发现，而且很多 IT 专业人士对它的存在持怀疑态度。

数字化转型为这种神秘的管理结构敲响了最后一颗钉子，并催生了一个新的结构：单一控制平面。

好消息是，与过去无畏的 IT 探索者所追求的单一玻璃面板不同，我们可能可以实现单一控制平面。 这是因为它不是基于 GUI，而是基于 API。

而且不仅仅是任何 API，而是一个声明性API。

为了理解原因，让我回顾一下 2010 年，当时“基础设施 2.0”一词盛行。

架构的最底层是基础设施 2.0 。 基础设施2.0专注于实现整个网络和应用交付网络基础设施的活力和协作。 它是传统上断开的（从通信和管理的角度来看）数据中心基础组件被赋予连接和协作能力的方式。 这主要通过开放的、基于标准的 API来实现，这些 API 提供了一组细粒度的操作功能，可以通过各种编程方法（例如编排系统、自定义应用）调用，也可以通过与传统数据中心管理解决方案的集成来调用。 基础设施 2.0 是从管理和运行时（执行）的角度使网络变得更加智能，但就其与云和IT 即服务的关系而言，该视图主要侧重于管理。

基础设施 2.0 包括从路由器到交换机、从负载均衡器到应用加速、从防火墙到 Web应用安全组件到服务器（物理和虚拟）基础设施的一切服务支持。 从其核心本质来看，它是一种支持 API 的组件。

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

听起来很熟悉？ 我们不再称之为基础设施 2.0，而是称之为“持续部署”和“自动化”以及其他 DevOps 类型的术语。 但概念是一样的。 这种想法正是“单一玻璃”从未实现的原因。 因为要使这样一个神秘的结构存在，单一解决方案需要结合（通过手动方法集成）大量的网络、应用服务和安全解决方案。

这种事绝不可能发生。

老实说，尽管大多数基础设施都支持 API，但这种情况永远不会发生。 为什么？ 因为所有这些 API 都是必要的，并且与每个设备的对象模型及其 GUI 一样紧密耦合。 命令式 API 本质上与设备/服务特定的对象模型相关，这给尝试使用它们的人带来了沉重的操作专业知识负担。 现在想象一下您的 IT 组织中的一位万事通，您信任他来负责管理多个供应商的路由器、交换机、安全设备以及五种不同类别的应用服务。

确切地。 这种生物就像大脚怪。 经常听说过，但从未证实存在。

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

例如，我们表示池或 VIP（虚拟 IP 地址）或 VLAN（虚拟 LAN）的方式与Cisco 、 Citrix或Juniper表示相同网络对象的方式不同。 事实上，我们的术语甚至可能不同；我们使用池，其他 ADC 供应商使用“场”或“集群”来表示相同的概念。 如果将虚拟化添加到组合中，又会产生另一组术语，这些术语通常与网络基础设施供应商使用的术语相冲突。 当应用交付供应商使用“虚拟服务器”时，它的含义与VMWare或Microsoft等虚拟化供应商使用“虚拟服务器”时的含义完全不同。

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

这就是我们不能拥有美好事物（比如一块玻璃）的原因。 因为该行业没有一块单一的玻璃面板可以监控基础设施。

但这篇文章的目的并不是让您感到沮丧，也不是让您永远走上被基于每个设备的管理所破坏的 IT 生活。 恰恰相反。 声明式——真正的声明式——API 可以导致单一控制平面。

但要做到这一点，我们需要摆脱声明式意味着用 JSON 或 YAML 编码设备配置的想法。 这并不是真正的声明，因为它仍然依赖于与设备特定对象模型相关的操作领域的专业知识 - 并且没有其他人可以吸收和使用它们。

让我使用 Kubernetes 服务和 Endpoint 资源描述作为声明式模型的示例：

配置虚拟服务器所需的一切都在这里，这些定义非常简洁 - 并且与实现无关。 externalIP是虚拟 IP 地址——用户或移动应用程序要与之通信的地址。 名称“my-Service”描述了一个虚拟服务器，其规范提供了网络详细信息，例如使用哪些端口和哪个池（“MyApp”）。 Endpoint资源描述组成“my-service”的每个节点并为池“MyApp”提供成员。 这里唯一缺少的是一种为那些能够执行循环以上操作的服务选择负载均衡算法的方法。  我们可以轻松地扩展服务描述的“ spec ”部分以包含“算法”： RR | WRR | LC | FR”选项普遍适用于所有负载均衡解决方案。 那里。 完毕。

理论上，我可以将相同的资源提供给十种不同的负载均衡解决方案中的任何一种，每个解决方案都会确定如何建模和实现描述的意图- 即配置位于 80.11.12.10 端口 80 的虚拟服务，该服务可在端口 80 上位于 1.2.3.4 和 2.3.4.5 的两个应用实例之间扩展 HTTP 请求。

另一种思考方式是，“我想要一个意大利辣味香肠披萨”和更乏味的“我想要你混合一些披萨面团，然后将其擀成一个直径为 10 英寸的圆圈”之间的区别。 涂上番茄酱。 用马苏里拉奶酪盖住，然后将意大利辣香肠放在上面。 在 425 度下烘烤 15 分钟。”

其中一件事情比较简单，并且会让你对细节产生混淆。 另一件事迫使你不仅要知道自己想要什么（意大利辣味香肠披萨），还要知道如何制作它。 这就是运营专业知识。

就像订购披萨一样，Kubernetes 资源描述是通用的。 其中没有任何内容强制在摄取此资源的设备上采用任何特定的对象模型或实现方法。 它描述了需要存在的内容，但绝不会影响我如何实现它。

真正的声明意味着提供传达意图和期望的最终状态的方法。 在未来的某个时候，我们只需说“为‘my-app’配置一个虚拟服务”，然后就好了！ 使用元数据和应用标签以及自动化、智能发现，该服务将从上到下进行自我配置*。 

如果我们要达到单一控制平面的涅槃境界，我们就必须努力提出中立的声明性规范，从而无需通过命令式 API 集成数据中心中的每个设备。 因为设备与设备的 API 集成实际上与设备与设备的管理并没有太大区别。

我们想要美好的事物。 我们想要一个统一的、单一的控制平面。 但要达到这个目的，业界必须做得更好，而不仅仅是对声明式点头，并认识到如果没有其他人可以采用和使用你的声明式接口，那么它首先就不是真正的声明式。

*女孩也可以有梦想，不是吗？