从解决方案到堆栈： 组装时代

IT 的组​​件化就像其负责保护和交付的应用的组件化一样。 据估计，80% 到 90% 的现代应用是由第三方组件组成的，其中大多数是开源的。 这样做的好处包括速度、对变化的响应（敏捷性）以及降低创建软件的成本。 毕竟，如果其他人已经编写了轮子的代码，为什么还要重新发明它呢？

目前还无法预估 IT 目前的组件化程度，但未来 IT 的组件化程度却非常明确： 非常。

我们不再构建自己的监控系统。 我们采用一个，就像普罗米修斯一样。 我们不开发自己的搜索引擎；我们与 Elastic Search 或 Lucerne 集成。 我们不需要设计和开发编队和基础设施控制器；我们有 Helm 和 Terraform。 我们不再被问及与系统的集成；我们被问及对生态系统的支持。

我们通过软件堆栈构建系统，而不是自己开发每个组件。

组件化的连锁反应

这种系统级思维在开发中普遍存在，并开始对所有软件（商业和定制）的开发方式产生深远的影响。 它也对我们构建网络的方式产生了重大影响。

几年前，我注意到微服务正在破坏网络。 这是一个尚未解决的分叉，其原因与 DevOps 的思维方式密切相关。 也就是说，DevOps 更有可能以组件化系统的角度来思考，尤其是在受到云的影响时。 随着 DevOps 不断侵蚀传统的 NetOps 和运营领域，他们也带来了自己的思维方式。 这意味着堆栈而不是解决方案。

这种观点自然会导致采用更适合 DevOps 当今运作模式和思维的单个应用服务。 单一用途、功能集中的应用服务用于组成数据路径，而不是构建数据路径。

这意味着负载均衡就是负载均衡。 入口控制就是入口控制。 API 网关就是 API 网关。 通过各种应用服务，运营工匠组成（组装）了一条从代码（应用程序）到客户（客户端）的数据路径。 

我们可以从今年的application服务状况报告中看到的 API 网关、入口控制和机器人防御等目标服务的非凡采用率中看到这一点。

这一转变并未被忽视。 正如数字化转型不断迫使企业重新定义自身并分解为以 API 和应用（数字化功能）为代表的服务一样，它也极大地改变了我们设计、开发和交付应用服务的方式。

爬上堆栈

基于 IP 的路由一直是数据路径的架构方式。 将此流量路由到这里，将这种类型的流量路由到那里，如果有效载荷中有与 X 匹配的内容，则将流量路由到那里。 它非常特定于网络，因此将数据路径与其部署的网络紧密结合。

这使得它很难在其他环境（例如公共云）中复制。 虽然您可以重复使用策略，但您将无法利用将数据路径绑定到网络的配置。

容器和云基本上都强制数据路径向上移动堆栈并从应用服务在应用层进行组装。 由于您操作的元数据（如主机名或标签和未绑定到网络的标签）在不同环境中的可移植性更强。

最终，这意味着我们需要从配置转向可以不受 IP 地址和环境约束地组装数据路径的策略。

毫无疑问，我们正在从解决方案转向堆栈、从手动流程转向管道。 随着我们在业务和运营中扩展数字化能力，对数据路径的组合和控制的需求将继续向上移动，并更加依赖于引导它的应用服务。