回首往昔……

云时代之前的应用交付与今天的应用交付截然不同。这是因为那时 IT 部门采购和配置服务器的速度在所有环节中是最快的。相比之下，规划新应用或重大应用更新则需要耗费数月甚至数年的时间。与此同时，企业应用变得越来越复杂，相互之间的依赖性日益增加，难以跟踪和管理。一旦出现安全威胁，整个系统可能就会出现连日宕机，或者企业遭遇危及生存的数据泄漏。即使没有外部攻击，全网（及其支持的应用）也会牵一发而动全身，瘫痪的风险随着复杂性的增加而上升。

为了有效应对这些风险，确保每个应用的安全性和可靠性，网络和安全团队均制定了相应的流程和策略。这些流程和策略严重依赖于人工审核，并且通常需要根据每个应用的独特需求手动实施策略。虽然它们很繁琐，但不一定构成瓶颈，反而经常能够加快采购步伐。

再看今朝…

然后云诞生了。一夜之间，部署流程似乎成为了累赘，拖慢了整个系统的进程。与此同时，GitHub 和其他社交编码平台异军突起，让同一团队或开源项目中的开发人员可以轻松开展编码协作。新应用架构减少了不同应用组件开发工作之间的冲突，避免了重复、返工和延迟，从而显著提高了开发人员的效率。微服务和服务网格架构减少了不同应用组件之间的依赖性，容器和无服务器则减少了对底层基础架构的依赖性，从而让各个开发人员和应用团队按自己的节奏前进。开发人员现在可以将应用部署时间从几个月缩短到几分钟。最初，此类部署仅限于开发和测试项目，但要求应用到生产系统中的呼声变得越来越高。

数字化转型：驶航中

与开发人员不同，网络管理员和安全工程师的职业经验以保护业务安全而非优化工作流为主，因此在追赶时代步伐时稍显乏力。而开发人员早已对 DevOps 风潮背后的许多核心概念熟稔于心，比如自动化流程、简化系统、减少系统之间的依赖性以及尽可能利用可重用流程和代码等。相比之下，网络管理员和安全工程师更像是“手艺人”。他们的工作性质要求每个应用都必须接受人工审核、由变更审核委员会进行维护以及通过手动实施的策略（可根据情况变化手动更新）进行管理。

虽然与开发人员相比，网络和安全团队在对自动化部署流程的认识上“开蒙”较晚，但也正在逐步赶上。

应用工厂：在应用交付中运用系统思维方法

在考虑如何过渡时，我们不妨将应用设定为工厂。这个“工厂”中没有手动制定的策略和人工审核流程。网络和安全专家需要定义可重用的策略，然后让开发人员将其作为自动化部署管道的一部分与应用一起部署。

但说起来容易，做起来难。从作坊升级为工厂不只是购买重型设备和重新分配岗位那么简单，同样，向系统方法转变也不只是工具和流程的问题，还涉及到思维方式和文化。相比由变更审核委员会和安全团队费心费力地研究每种可能的安全威胁向量和性能风险，一个完善的自动化应用交付系统本身就可以将故障域及其影响最小化，并建立有效的反馈环以实现早期检测和响应。工具和管道决策应该在开发人员的自由和一致服务的效率价值之间进行平衡。在理想的系统中，开发人员可以最大限度地自由制定有关工具的决策，这些工具会影响功能的开发，但也可以提供一系列一致的支持多云环境的基础设施和安全服务。然后再将这些一致的服务构建到应用交付管道的核心中，这既可以减少技术债务，又能提高运营和合规效率，并最终反过来促使开发人员专心交付更多创新业务价值。

（单击下图，查看完整的 F5 应用工厂信息图。）