可配置性和可操作性之间的区别

由于我们最近收购了 NGINX ，我们发表了许多关于交付（应用开发）和部署（生产）之间分歧的博客。其中一篇简要提到了我们今天要探讨的一个概念：操作简单性。

“操作简单”这一短语的背后，存在着可配置性和可操作性之间的分歧。 两者形成了鲜明的对比。 一方面是可配置性。 这就是操纵网络、平台和应用服务层的应用服务特性的能力。 它使您能够打开或关闭 Nagle 算法，以及调整影响协议性能和效率的设置。

另一方面是可操作性。 这就是快速部署、管理和监控应用服务的能力。 可操作性的期望是对应用服务的了解，仅此而已。 不要求操作员成为平台或网络层的专家。 为了实现这一点，应用服务层存在的旋钮和按钮可能会受到限制。 首要目标是使应用服务易于部署和操作。

其中之一就引入了复杂性。 一个减少了它。 人们需要对整个堆栈有深入和广泛的知识。 另外一个则没有。 每个组件在应用的安全交付中都发挥着一定的作用。

职责分工

这种划分之所以重要，是因为云和容器正在对应用服务基础设施施加压力，使其转向更简单的模型。 许多应用服务正在被容器所使用。 负载平衡、入口控制、监控、API 网关和 API 安全被视为成功的容器化策略的必要组成部分。 架构的变革，本质上就是应用服务本身的划分。 有些更适合部署在数据路径中，有些则适合作为应用架构的一部分。

这意味着，越来越多的操作（特别是 DevOps）正在使用本地和公共云中的应用服务。 这对这些应用服务产生了深远的影响，因为 DevOps 的期望包括可操作性而不是可配置性。 DevOps 对调整 TCP 堆栈并不特别感兴趣；他们对快速、频繁的部署和维护应用可用性感兴趣。

这主要是由于对价值实现时间的关注，要求更快的交付和部署速度。 没有人有时间去搞乱基础设施，他们要将应用推向市场。

但这并不意味着可配置性不重要。 确实如此，特别是在安全性和性能方面。 标准化的网络和平台堆栈并未针对任何内容进行优化。 它无法在针对桌面进行优化的同时自行调整以针对移动设备进行优化。 它并没有针对您的网络进行优化，无论是在云端还是在本地。

无论我们是否愿意承认，绩效是一个复合衡量标准。 如果您的网络很慢，您的应用程序也会更慢。 在网络和平台层进行优化的需求是确保可用性和性能的关键因素。 这使得可配置性成为那些可以利用它的人可以使用的东西。

并非二元选择

可配置性与可操作性同样重要。 这实际上不是一个二元选择，因为应用服务的消费并不是二元的。 如今，NetOps 和 DevOps 都使用应用服务；分歧在于他们对这些应用服务的部署和管理的期望。 NetOps 需要可配置性。 DevOps需要可操作性。

企业需要两者，因为如果您的应用程序不快速且不可靠，那么上市速度就无济于事。

存在这种分歧是因为技术正处于过渡状态，即可配置性为主导的世界与可操作性为预期的未来状态之间的过渡状态。 今天，您需要一种方法来弥合两者之间的鸿沟，并提供满足运营商运营期望的应用服务。 这就是为什么今天 F5 与 NGINX 的结合如此令人兴奋的原因。

但我看到了未来你可以同时拥有可配置性和可操作性。 这就是为什么 F5 与 NGINX 的结合对未来如此有前景。 如果您对 F5 和 NGINX 如何提供现代 API 管理特别感兴趣，请注册参加即将举行的网络研讨会。