比较application交付： 2005 年与 2015 年

编写代码的 James Ward（他的描述）最近写了一篇很棒的文章，其中他对当今和十年前的应用部署进行了比较。 整个 IT 行业中一个保密较好的秘密是，应用架构和部署的变化对应用交付（确保应用快速、安全并可供消费者使用的实际过程）有直接影响。 例如，如今微服务所带来的变化对于网络架构及其部署模型的改变具有重要意义。

我知道，我知道。 您正在考虑向微服务和容器化以及云抽象网络的方向发展，从而减少应用对它们的依赖。 从开发人员甚至操作人员的角度来看，确实如此。 但网络仍然是必需的；交换的数据仍然需要通过这些管道流动，并且网络中的服务仍然负责许多功能，使应用程序运行快速、保证其安全并确保可用性。 应用的组成和部署位置和方式的变化必然会影响这些服务，即使应用不知道它们的存在（老实说，它们甚至不应该知道）。 他们就像守护天使一样。）

因此，考虑到这种关系，即使应用没有回应，詹姆斯的文章也启发了我们对过去十年中我们交付应用方式的变化的平行观察。

部署架构

2005	2015
康加线	平台

早在 2005 年，网络团队 (NetOps) 就以我们称之为“康加线”的方式部署了交付应用所需的各种应用服务。 这些是单独的点解决方案。 如果您需要一些东西来让应用程序运行得更快，您可以在其自己的个人私有盒子上部署一个Web 性能优化产品。 另一个盒子用于负载均衡，另一个用于应用程序安全，等等。 最终，许多箱子排成了长队，每个箱子都必须双向穿过。 

2004 年，应用交付控制器问世（但在 2005 年还非常不成熟），并开始朝着我们今天所拥有的平台发展。 这些平台提供常见的功能和处理，并可以通过模块（或插件或附加组件或任何您想称呼的名称）进行扩展。 平台方法极大地减少了“在线”所花费的时间，就像容器化和虚拟化减少了在应用和服务之间传输所花费的时间一样。 它还可以通过共享一个共同的基础（平台）来降低运营成本，该平台可以规范当今交付应用所需的各种应用服务的管理。

从产品到平台的演变是有利的，因为应用部署转向更加一次性、分解的架构，利用容器和微服务等新兴技术以及在云环境中部署，因为它们可以用来部署各种应用服务，或者只部署一个应用服务，使用相同的标准化核心。 这意味着随着部署的应用服务的占用空间扩大，管理开销会减少，并且随着应用的增长，可以根据需要添加服务。

部署方法

2005	2015
手动部署	可编程部署

2005 年，基于 Web 的 GUI 刚刚开始成为标准使用，配置应用服务的主要方法是通过 CLI。与所有手动流程一样，此过程需要时间，而且随着应用服务变得越来越复杂，所需的时间会更多。 由于人为错误而引入的问题及其产生的影响（网络中错误配置的爆炸半径成倍增加）意味着当时的监督时间会更长。 复制和粘贴很普遍，但并非万无一失，并且管理服务的管理开销非常大，足以确保只有更重要的应用才能享受到这些服务的好处。

快进到 2015 年和 DevOps 革命。 可编程性——无论是在 API 中还是基于模板的配置中——正在改变一切，甚至在网络中。 现在可以使用 Puppet 和 Chef 等流行框架通过 API 实现application服务自动化，预先集成 Cisco APIC 和 VMware NSX 等编排解决方案，并由 Python、Perl、bash 和 curl 进行自定义驱动。 application服务模板可以实现标准化和重用，并鼓励将基础设施“视为代码”，以使持续交付实践能够扩展到网络中。

虽然在应用开发中应用交付并不像持续交付那样普遍，但它已经发展（并将继续发展）到支持可编程部署选项，通过更快的服务配置来缩短产品上市时间，并通过自动化和重用来降低运营成本。

部署形式因素

2005	2015
大铁	虚拟化

2005年，人们开始热衷于构建更大、更好、更快、功能更强大的网络硬件。 以太网速度的不断提高和基于网络的应用的爆炸式增长意味着网络中部署的大型设备的补充扩展，以支持应用服务需求。

今天的重点是资源的密度和最佳利用。 这意味着虚拟化和云计算，两者都由应用交付平台的虚拟化支持。 应用交付平台现在能够部署在 AWS、Microsoft Azure 和 Rackspace 等云环境中，以及可在专用或现成硬件上部署的虚拟设备中。 这种能力是一项要求，不仅是为了支持云环境，而且是为了适应微服务等新兴架构。 正如 James Ward 所说，如今的微服务和服务器本身是“一次性的、不可变的、短暂的……”。

这意味着进入 DevOps 领域的许多应用服务（负载均衡、应用安全和优化）必须满足软件定义数据中心的标准。 至少它们必须能够大规模地适应不可变的、可抛弃的模型。 如今，许多应用交付平台都已存在，并结合可编程的部署选项，随时准备应对挑战。

部署责任

2005 年 - 以及至今在许多组织中 - 网络团队全权负责部署和管理应用交付。 交付的每个方面，从采购到供应到配置，过去和现在通常都由网络运营来处理。 这种脱节的模型意味着延迟，因为需要确定需求、创建票据以及工程师手动调配和配置交付应用程序所需的应用服务。

如今，许多组织仍然处于这种状态，但云和微服务的影响以及 DevOps 的采用正在改变这种状况。 人们对 IT 即服务的需求十分强烈，应用服务配置的责任转移到运营甚至开发团队。 需要将应用关联服务在物理和拓扑上都放置在更靠近应用程序的位置。这使得 DevOps 牢牢占据主导地位，并负责调配和配置这些服务。

这并不意味着网络团队不再负责应用交付。 相当一部分应用和企业需要以更传统的方式交付应用服务，注重实现可靠性而不是灵活性。 这些服务仍然、并且很可能会继续属于网络团队的职责范围。 但其他人正在并将继续转向 DevOps 的责任。

过去十年中，应用交付取得了长足的进步。 它从一组产品发展成为一个统一的平台，获得了可编程性，并从大型机转变为支持虚拟机管理程序和云部署。 随着移动应用、微服务和 DevOps 继续从根本上改变应用的构建、部署和交付方式，我们期望看到最终交付这些应用并保持其快速、安全和可用的服务不断发展。