为什么应用交付应该更像工厂（而不是工匠店）

回顾过去……

在很久以前的云计算时代之前，应用交付与今天有很大不同。 这是因为没有什么比 IT 采购和配置运行应用s的服务器的速度更快。 规划新的应用s或主要应用更新需要花费数月甚至数年的时间。 与此同时，企业应用s变得越来越复杂，相互依赖的关系越来越多，难以跟踪和管理。 出现的安全威胁可能会导致整个系统关闭数天，或导致职业生涯终结的数据泄露。 即使没有外部不良行为者，实施导致网络（及其支持的应用s）崩溃的变更的风险也会随着复杂性指数的上升而上升。

为了管理这些风险并确保其负责的每个应用的安全性和可靠性，网络和安全团队制定了大量依赖人工审查的流程和政策，并且通常涉及手工制定的政策，旨在满足每个应用的独特需求。 虽然这些程序很麻烦，但它们并不一定是瓶颈。 他们经常掌控采购流程。

晴空万里……

然后云就出现了。 突然之间，部署过程开始成为原本快速运行的系统的拖累。 大约在同一时间，GitHub 和其他社交编码平台让开发人员更容易地进行代码协作，无论是在同一团队内还是在开源项目中。 新的应用架构通过减少应用某一部分的工作与其他部分发生冲突的机会（辛劳、返工和延误的主要原因），大大提高了开发人员的效率。 微服务和服务网格架构减少了应用本身各部分之间的依赖，而容器和无服务器减少了对底层基础设施的依赖——使个人开发人员和应用团队可以按照自己的节奏前进。 开发人员现在可以在几分钟内而不是几个月内部署应用s。 最初，此类部署仅限于开发和测试项目，但对更快访问生产系统的需求迅速增长。

数字化转型： 正在进行的工作

网络管理员和安全工程师难以跟上步伐，部分原因是与开发人员不同，他们的专业经验集中在确保业务安全而不是优化工作流程。 对于开发人员来说，DevOps 运动背后的许多核心概念已成为他们的第二天性：自动化流程、简化系统、减少系统之间的依赖性以及尽可能利用可重复使用的流程和代码。 相比之下，网络管理员和安全工程师则接受过工匠式的培训。 他们工作的关键性质要求每个应用都必须经过人工审查、由变更审查委员会进行维护，并通过手工制定的政策进行管理，这些政策可以根据不断变化的情况进行（手动）更新。

好消息是，尽管在理解自动化部署流程方面一开始就远远落后于开发人员，但网络和安全团队正在迎头赶上。

application工厂： 将系统思维应用于application交付

思考这种转变的一个好方法是想象一个应用工厂。 网络和安全专家不需要手工制作策略和手动审查流程，而是需要定义可重复使用的策略，然后将其推送给开发人员，作为自动化部署管道的一部分与他们的应用s一起部署。

不可否认，说起来容易做起来难。 正如从手工制品到工厂生产产品的转变不仅仅是购买重型设备和重新分配工人到新岗位的问题一样，向系统方法的转变不仅与工具和流程有关，也与思维方式和文化有关。 精心设计的自动化应用交付系统不会改变审查委员会和安全团队费力地调查每一个可能的安全威胁载体和性能风险，而是将故障域保持在较小范围内以最大限度地减少影响，并建立有效的反馈回路以实现早期检测和响应。 工具和管道决策应该在开发人员的自由和一致服务的效率价值之间取得平衡。 理想的系统为开发人员提供了最大的自由，让他们能够围绕影响功能开发的工具做出决策，但提供一套一致的多云基础设施和安全服务。 将一致的服务构建到应用交付管道的核心中，可以减少技术债务并提高运营和合规效率。 这反过来又使开发人员能够专注于为企业提供更多创新价值。

（点击下图查看完整的 F5application工厂信息图。）