多云一致性是多层次的

一致性。 在科技的世界里，我们使用这个术语来描述等效性。 如果某事物随着时间的推移或在不同条件下表现相同，则该事物是一致的。 对于在多云世界中运营的企业来说，一致性仍然是一个问题。 根据我们的2019 年application服务状况报告，大多数人 (87%) 都是如此。

当然，数据中心和云端应用服务部署率的差异可以归因于一个简单的原因：没有一致地部署应用服务。

但这并不是造成不一致的唯一原因。 根据同一项调查，许多人在本地和公共云中部署应用服务，但仍然在一致性方面遇到困难，尤其是安全性。

这就需要更深入地探究“一致性”的含义，因为我怀疑问题的一部分在于未能认识到一致性有两个不同的层次，并且两者都很重要。

application服务不是application交付控制器

关于一致性的讨论的核心是应用交付控制器 (ADC) 和应用服务之间的区别。

ADC是一个提供应用服务的平台。 ADC 本身就是一个系统，就像 Kubernetes 本身就是一个系统一样。 Kubernetes是一个部署和操作容器的平台。 ADC 是一个部署和运行应用服务的平台。

这很重要，因为平台（或者你愿意的话也叫系统）与其部署和操作的“事物”相比，具有不同的一致性概念。 一致性处于操作层；即平台及其提供的应用服务的管理和操作。

功能一致性

这与每个应用服务提供的功能一致性明显不同。 功能一致性包括应用服务的功能。 当人们指出多云一致性的挑战时，他们通常指的就是这个，因为它是最明显的。

在部署来自不同提供商的应用服务时，功能一致性尤其难以实现。 一个供应商提供的 WAF 或反机器人服务在功能上不一定等同于另一个供应商提供的 WAF 或反机器人服务。

组织难以实现多云一致性的原因之一不是因为他们没有在云中部署应用服务，而是他们部署了具有不一致功能能力的不同应用服务。 基于功能等效性的标准化将帮助组织实现他们所努力实现的一致性。

操作一致性

第二个不一致性来源（较少被提及）是在平台层。 这是相当一部分企业组织的 ADC。 在迁移到公共云时，许多组织（有意或无意地）选择采用云原生选项来提供应用服务。

这会立即导致平台层的操作不一致。 您配置、加入和操作这些应用服务的方式是可操作的，并且在您接入第一个 API 时就会引入运营债务。

您可能没有在本地使用云原生应用服务。 这意味着您现在需要处理两个不同的应用服务平台。 他们有不同的管理、分析、监控等方法。

这就像在现场使用两个不同的 ADC。 虽然一些非常大的组织实现了这一点，但多年来，我们注意到大多数组织都采用单一 ADC 平台进行标准化。 操作一致性和在所有应用s中复制应用服务策略的能力是做出该决定的驱动因素。

但是在转向云时，有些人忘记了他们最初在 ADC 平台上进行标准化的原因：操作一致性和支持。 引入额外的平台必然会增加运营负担并损害对一致性的追求。

一致性需要标准化

对于一些人来说，标准化可能是一个可怕的术语，他们认为标准化会扼杀创新。 但更可怕的是，这种混战可能会鼓励创新，但从长远来看是不可持续的，并会造成混乱的运营环境。

由于 IT 面临着为企业创造价值的压力，增加运营人员以维护多个平台和各种应用服务似乎与实现多云一致性的目标相悖。

标准化（尤其是在操作层）是创新的关键组成部分，因为它减轻了员工专注于操作平台的负担，并鼓励在政策和架构上的协作。

通过确保各个属性的运营和功能一致性，组织可以在不超出预算的情况下实现其所需的政策一致性。