为什么 DevOps 从业者应该关心每个应用程序的架构？

这个问题暗示了你应该这么做的结论。

几十年来，我们一直在共享平台上部署构成大部分生产流程的应用服务。 NetOps 通常以应用交付控制器 (ADC) 的形式在共享基础设施上提供负载均衡、应用性能服务、WAF 和联合身份等应用服务。

但时间和需求——以及微服务等新兴应用架构——正在迫使该流程发生变化。 这些变化对于 NetOps 和 DevOps 来说都是好的，因为它们正在转向一种与部署计划和运营实践（如基础设施即代码）更加紧密结合的模型。

有些应用服务仍然牢牢地扎根于共享基础设施之上。 DNS。 防御容量激增的 DDoS 攻击。 网络防火墙。 这些服务本质上是企业服务。 也就是说，它们旨在保护、捍卫和服务企业。 如果这些服务失败了呢？ 整个企业没有生产力或利润。 

但其他应用服务具有高度的应用亲和性；它们的配置、API 和服务通常是专门配置的，以支持单个应用。 不是一个单一的架构，而是一个单一的应用。

这些服务的责任正日益向应用操作（DevOps）转移，并吸引交付应用的开发人员。 尽管共享模型可以（并且通常确实）仍然可以提供必要的交付和安全应用服务，但出于多种原因，对于许多应用而言，采用每个应用的模型是可取的。

首先，每个应用程序模型巧妙地解决了部署计划冲突。 企业组织经常受到其支持的应用服务的配置和部署方面的共享基础设施冲突的限制。 共享基础设施意味着共享资源，这必然会增加配置冲突的可能性。 通过消除这种可能性，可以减轻对更频繁或不按计划部署的阻力。 毕竟，如果一个应用服务专用于我的应用，并且在自己的平台上使用自己的资源运行，那么冲突就得到了巧妙的解决。 我的应用程序，我的风险。

其次，每个应用程序模型支持新兴的自动化工作，包括将基础设施即代码等方法付诸实践。 通过将资源和平台专用于单个应用，配置仅包括该应用。 可以强制执行不变性，并避免熵的风险。 事实上，我认为（并且最近也确实如此）如果没有针对每个应用程序的架构就无法正确地实现不可变的基础设施。 这种方法可以将内容纳入到超越应用基础设施并延伸到“网络”的持续部署管道中。 提供此功能意味着将配置和持续管理的责任从 NetOps 转移到 DevOps。 好消息是，更大的责任带来了更大的控制权，因为 DevOps 成为应用服务的“所有者”，并有权按照自己的条款和时间表进行升级、修补和重新部署。

最后，每个应用程序的模型立即变得更加可移植。 由于不受共享平台的束缚，也几乎完全依赖部署工件（配置和模板），大部分生产流程能够从云端迁移到云端、从本地迁移到外部，而且阻力和精力更少。 这种自由使组织能够为相关应用选择最佳的云和位置，而不受与迁移相关的成本的限制。

通过鼓励在本地和公共云中采用应用服务的每个应用程序架构，DevOps 可以受益匪浅。 由于 NetOps 面临着为其他运营领域提供更大控制和可视性的压力，现在是时候吃点披萨喝点啤酒，与 NetOps 同行讨论如何支持下一代以应用程序为中心的每个应用程序架构了。