数据路径中的控制与执行

在过去，提供应用程序的应用服务形成了一条笔直而狭窄的数据路径。 所有应用程序基本上都通过同一网络传输同一组服务。 这种架构的简单性使得单点控制和单点执行的结合变得容易。 这反过来又导致了应用交付控制器 (ADC) 的兴起。 通过它，应用程序流量可以在一个地方进行塑造、引导、扩展和保护。 控制和执行相结合，为操作提供了数据路径中的战略点，在此可以强制执行和执行各种策略。

云计算的兴起和容器的持续采用已经扰乱了该数据路径。 我们现在拥有多个有时是动态的数据路径来交付应用程序。 单一的、战略性的控制和执行点通常在操作上或架构上不再可行。

但这并不意味着即使执行被委托给一组不同的应用服务，统一的控制点就不再可能。

重要的是，要有尽可能少的控制点，通过这些控制点可以操作（部署、配置和管理）数据路径中的应用服务。 鼓励使用多个控制点不可避免地会导致政策冲突，从而给应用程序消费者带来问题。 解决问题变得更加复杂和耗时，这引起了用户的愤怒和焦虑。 不幸的是，工具蔓延是那些负责在已经多样化的应用程序组合中添加云原生架构的人员的普遍抱怨。

我们从 2020 年应用服务状况研究中了解到，运维主要负责应用服务的运行，但他们并不是唯一的。 DevOps、NetOps 和 SecOps 都投入于本地和公共云中的应用服务的运营。 

它们之间的区别往往在于它们负责的应用服务的具体功能。

DevOps 主要负责可靠性、性能和特定于应用程序的策略。 另一方面，NetOps，就其名称而言，更注重网络属性。 NetOps 通常从基础设施的角度维护应用服务。 当然，SecOps 关注的是与基础设施和应用程序相关的安全性。

但是，仅仅因为有职责分工并不意味着他们应该使用不同的工具来练习他们的艺术。 今天，有充分的证据表明 CI/CD 和持续部署流程是建立在不同的工具集上。 Jenkins 和 git repos 主导 CI/CD 管道，而 Ansible 和 Python 是持续部署方面的首选工具。 大部分的决策都在于将工具集与必须每天与工具交互的各个组成部分的工作方式相匹配。

因此，如果出现一个单一工具来提高策略一致性，加快故障排除速度，并消除工具蔓延的复杂性和成本，它必须具有正确的接口，以确保数据路径中应用服务的所有主要组成部分能够利用该工具集来执行各自的职责。

这对于应用服务本身的整体安全性和可靠性非常重要。 通过维护统一的控制点，组织可以确信变化得到跟踪和理解。 虽然它不是一个不可变的实现，但通过在一个工具中集中控制，它朝着这个实践迈出了几个步骤。 

这种工具的一个示例是NGINX Controller 。  

您会注意到，正如设想的那样，即使操作和执行是分布式的，各种应用服务（分析、API 管理、安全和服务网格）都可以集中控制。

在任何环境中，减少允许与数据路径组件（应用服务）交互的工具数量以减轻配置错误或配置冲突的潜在问题都很重要。 在现代多云环境中，集中控制变得更加重要，因为构成数据路径的应用服务通常呈指数级增长，从而带来了复杂性。 

对于拥有预算的人来说更有吸引力的是，通过自动化消除重复的手动活动可以减少运营费用。

在单一工具中统一控制是实现这一目标的方法之一。