James Ward（他自称是“写代码的”）最近撰写了一篇精彩文章，对比了应用部署在当今与十年前的差异。整个IT行业有一个鲜为人知的事实：应用架构和部署的变化会直接影响应用交付，也就是确保应用能够快速、安全且持续可用地提供给用户的实际过程。例如，微服务如今带来的变化意义重大，将会改变网络架构及其部署模式。
我知道，我知道。您可能认为，向微服务、容器化和云迁移会将网络抽象化，使应用对网络的依赖降低。从开发人员，甚至可能从运维人员的角度来看，确实如此。但网络仍不可或缺，交换的数据仍需通过这些网络通道传输，而网络中的服务仍负责多项功能，帮助应用提升速度、保障安全并确保可用性。因此，应用的构建和部署位置及方式发生变化，必然会影响这些服务，即使应用并不知道它们的存在（说实话，应用也不应该知道。它们就像守护天使一样默默守护应用。）
鉴于这种关系，即使应用并未意识到它的存在，James的文章也启发我们从类似的视角，审视过去十年间应用交付方式的变化。
部署架构
| 2005 | 2015 |
| 纵向串联架构 | 平台 |
 |  |
早在2005年，网络运维团队（NetOps）采用一种我们称为“康加舞队列”的方式，部署交付应用所需的各种应用服务。这些服务都是独立的单点解决方案。如果需要提升应用速度，就要将Web性能优化产品部署在专用的独立设备上。负载均衡需要另一台设备，应用安全又需要一台，以此类推。最终，大量设备排成了长长的队列，双向流量都必须逐一经过每台设备。
应用交付控制器于2004年出现（但在2005年仍很不成熟），随后逐步演变为如今的形态，即平台。这些平台提供通用功能和处理能力，并可通过模块（也可称为插件、附加组件或其他名称）进行扩展。平台方法大幅缩短了数据“在线路上”传输的时间，这与容器化和虚拟化减少应用与服务之间的传输时间类似。此外，通过共享一个通用基础（即平台），还可以统一管理当前交付应用所需的各种应用服务，从而降低运营成本。
随着应用部署转向更易替换的解耦架构，采用容器和微服务等新兴技术并部署到云环境中，从产品向平台演进将带来优势，因为平台可基于同一套标准化核心部署多种应用服务，也可仅部署一种服务。这意味着，随着已部署应用服务的覆盖范围扩大，管理开销会相应减少；同时，还可随着应用的发展按需添加服务。
部署方法
| 2005 | 2015 |
| 手动部署 | 可编程部署 |
 |  |
2005年，基于Web的GUI才刚开始普及，应用服务主要通过CLI进行部署和配置。与所有手动流程一样，这一过程十分耗时；随着应用服务日益复杂，所需时间也进一步增加。人为错误引发的问题及其影响（网络中的错误配置会导致影响范围呈指数级扩大）意味着监督工作需要投入更多时间。复制粘贴虽已十分普遍，却并非万无一失；服务管理的行政开销也相当高，因此只有较为重要的应用才能受益于这些服务。
时间来到2015年，DevOps革命兴起。API和基于模板的配置所带来的可编程性正在改变一切，网络也不例外。如今，可以通过API，使用Puppet和Chef等常用框架实现应用服务自动化；也可以与Cisco APIC和VMware NSX等编排解决方案预集成，或使用Python、Perl、bash和curl进行自定义驱动。应用服务模板有助于实现标准化和复用，并推动将基础设施视为“代码”，从而将持续交付实践扩展到网络。
尽管应用交付尚未像应用开发中的持续交付那样普及，但它已经并仍在不断演进，可支持可编程部署选项，通过加快服务配置缩短上市时间，并通过自动化和复用降低运营成本。
部署形态
| 2005 | 2015 |
| 大型机 | 虚拟化 |
 |  |
2005年，业界竞相打造规模更大、性能更强、速度更快、功能更丰富的网络硬件。随着以太网速度不断提升、Web应用迅猛增长，网络中部署的大型硬件设备也需要相应扩展，以满足应用服务需求。
如今，重点已转向提高密度和优化资源利用率。这意味着采用虚拟化和云计算，而二者都离不开应用交付平台的虚拟化。现在，应用交付平台既可以部署在AWS、Microsoft Azure和Rackspace等云环境中，也可以作为虚拟设备部署在专用硬件或商用现成硬件上。这项能力不仅是支持云环境的必要条件，也是适应微服务等新兴架构的必要条件。正如James Ward所指出的，如今的微服务和服务器本身都是“可随时弃用、不可变且短暂存在的……”
这意味着，许多正在纳入DevOps领域的应用服务，包括负载均衡、应用安全和优化，都必须满足软件定义数据中心的标准。这些服务至少必须能够大规模适应不可变、可弃置的模式。如今，许多应用交付平台已具备这一能力，并可结合可编程部署选项，应对这一挑战。
部署责任
| 2005 | 2015 |
| 网络团队 | 网络团队和DevOps |
2005年，网络团队全权负责应用交付的部署和管理，时至今日，许多组织仍是如此。从采购、资源调配到配置，交付的各个环节过去由网络运维团队处理，如今也往往如此。这种相互脱节的模式会造成延误，因为各方需要反复讨论需求、创建工单，再由工程师手动调配和配置交付应用所需的应用服务。
如今，许多组织仍然如此，但云和微服务带来的影响，加上DevOps的采用，正在改变这一局面。对IT即服务的需求十分强烈，应用服务的配置职责正转移到运维团队，甚至开发团队。与应用紧密关联的服务需要在物理位置和拓扑结构上更靠近应用。因此，DevOps成为主导力量，负责预置和配置这些服务。
这并不意味着网络团队不再负责应用交付。仍有相当一部分应用和企业关注事项要求以更传统的方式交付应用服务，重点是实现可靠性而非敏捷性。这些服务目前仍由网络团队负责，未来也很可能如此。但其他服务目前已由DevOps负责，并将继续向DevOps转移。
过去十年，应用交付取得了长足发展。它已从一系列产品演变为统一平台，不仅具备可编程能力，还从大型专用硬件转向支持虚拟机监控程序和云部署。随着移动应用、微服务和DevOps持续从根本上改变应用的构建、部署和交付方式，最终负责交付这些应用并帮助其保持快速、安全和可用的服务也将继续演进。
关于作者
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服务。