我不会读心术（我的孩子们可能不同意，不过这并不重要），但我能读懂《应用交付现状》调查的反馈。从自称应用开发者的受访者视角审视这些反馈时，我看到了一幅非常有意思的图景。
开发人员重视速度、安全性和可扩展性，虽然优先顺序未必如此，但三者都很重要。他们不仅重视这三点，也认识到应用服务有助于实现这些目标。
具体而言，开发人员需要的不只是笼统的应用“加速”服务，而是能够提供TCP优化和缓存功能的具体服务。他们还需要Web应用防火墙以及一定的负载均衡功能。
问题在于，这些应用服务大多采用共享基础设施模式交付。每个应用都有自己的“虚拟实例”，但实际上仍驻留在共享的软件或硬件上。
这可能会引发实际问题，也是IT与应用开发团队之间摩擦持续存在的部分原因。正是由于系统采用共享模式，才出现了变更窗口、评审委员会和周六晚间部署（还得用披萨安抚大家）等做法。这些流程拖慢了开发进度，也让所有相关人员都对部署感到沮丧。
我们不再部署庞大臃肿的单体应用。即使没有盲目追求微服务，也没有将应用拆分成数百个小型服务，我们仍然有更多应用需要更频繁地部署。这些应用采用为期一周的冲刺开发，而不是耗时一年的项目，因此需要更快、更频繁地推送更新。
归根结底，这才是（公有）云如此成功的主要原因。因为这是我的应用和我的基础设施，我无需等Bob、Alice或John，就能推送更新。因为这一切都由我掌控，出了问题也由我负责。
同样的方法也适用于本地环境（而且我认为更可取）。要做到这一点，构成应用交付链的所有环节和组件都需要支持这种按应用管理的方法，而云环境已让这种方法备受青睐。
基本上，按应用交付所需网络和应用服务，就像为该应用分配一个专用子网，也可以称为应用交付VLAN。这种方式专注于单个应用，并为其提供专用服务。
这种隔离不仅有利于安排部署计划，也让其他所有人受益。故障难以避免，一旦发生，就应尽可能缩小影响范围。按应用划分的架构可以严格限制故障影响，让那些“以防万一”而待命的人员不必接到告警电话。我可以每周发布和部署，而不会与每月发布和部署一次的应用相互干扰。我的应用、我的服务、我的部署计划。
按应用划分的架构也便于排查生产环境中出现的问题，而这类问题并不少见。事实上，在2017年Atlassian的一项调查中，50%的开发人员表示，代码发布后生产环境出现了问题。这样就不会存在他人所做的更改可能影响该应用的情况。您可以直接检查相关系统，而不必花费宝贵时间判断哪些系统可能与问题有关。
按应用划分的架构天然更适合公有云或私有云，因为该模型正是基于这一假设。每个应用都有一套专用的应用服务，用于扩展应用、提升应用速度并保障应用安全。
事实上，按应用架构的出现是必然的。 这并不是我第一次这样说。应用的引力不容忽视，而保障应用安全所需的安全措施也日益因应用而异，这意味着按应用方法迟早会出现。
这是一件好事，因为开发人员所需的应用服务往往因应用而异。适用于一个应用的服务不一定适用于另一个应用，甚至可能产生负面影响。采用按应用构建的应用交付架构，不仅可以确保开发人员获得扩展、保护和加速应用所需的服务，还能更好地支持他们期望从云中获得的自助服务模式，无论云部署在本地还是异地。
关于作者
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服务。