这个问题本身就暗含了一个结论：您应该这样做。
数十年来，我们一直在共享平台上部署构成生产流水线大部分环节的应用服务。负载均衡、应用性能服务、Web应用防火墙（WAF）和联合身份认证等应用服务通常由网络运维团队（NetOps）通过共享基础设施提供，并且往往采用应用交付控制器（ADC）的形式。
但随着时间推移和需求变化，以及新兴应用架构（如微服务）的出现，这一管道必须随之改变。这些变化对NetOps和DevOps都有益，因为它们正在转向一种更契合部署计划和基础设施即代码等运维实践的模式。
有些应用服务仍牢牢部署在共享基础设施上，例如DNS、容量型DDoS攻击防御和网络防火墙。这些服务本质上属于企业级服务。也就是说，它们旨在保护、防御并服务于企业。如果这些服务发生故障，整个企业的生产力和盈利能力都将受到影响。
但其他应用服务与特定应用高度关联，其配置、API和服务通常专门用于支持单个应用。不是单一架构，而是单个应用。
这些服务的责任正日益向左转移至应用运维（DevOps），并由负责交付应用的开发人员参与。虽然共享模式仍可（而且通常确实可以）提供必要的应用交付和安全服务，但出于多方面原因，其中许多服务更适合采用按应用部署的模式。
首先，按应用模式可以有效解决部署计划冲突。企业组织在配置和部署共享基础设施所支持的应用服务时，往往会受到共享基础设施冲突的制约。共享基础设施意味着共享资源，这必然会增加配置冲突的可能性。消除这种可能性，有助于减少对更频繁部署或计划外部署的阻力。毕竟，如果一项应用服务专用于我的应用，并在独立平台上使用专属资源运行，冲突便迎刃而解。我的应用，风险由我承担。
其次，按应用模式支持新兴的自动化实践，包括采用基础设施即代码等方法。通过为单个应用分配专用资源和平台，配置中将只包含该应用。这样可以强制实施不可变性，并避免熵增风险。事实上，我认为（我最近也提出过这一观点），如果没有按应用架构，就无法正确实施不可变基础设施。这种方法可将应用服务纳入持续部署流水线，使其覆盖范围从应用基础设施扩展到“网络”。要实现这一能力，需要将配置和持续管理的责任从NetOps转移到DevOps。好消息是，责任越大，控制权也越大。DevOps将成为应用服务的“所有者”，并可根据自身需求和计划进行升级、修补和重新部署。
最后，按应用模式可直接提升可移植性。由于不受共享平台束缚，并且几乎完全依赖部署工件（配置和模板），生产流水线的大部分环节都能以更低的阻力和更少的工作量在不同云之间迁移，或从本地环境迁移到云端。这种灵活性让组织能够为相关应用选择更合适的云和位置，而不必受迁移相关成本的制约。
无论是在本地环境还是公有云中，推动应用服务采用按应用架构，都能让DevOps显著受益。NetOps正面临压力，需要为其他运维领域提供更强的控制能力和可见性。现在正是与NetOps同事轻松交流的好时机，不妨边吃披萨、喝啤酒，边探讨如何转向支持以应用为中心的新一代按应用架构。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。