application服务和 CD 管道

和所有主导数据中心对话的技术一样，DevOps 目前正遭受定义疲劳。 实际上，此时我认为这是疲惫，但两者之间的界限很难确定。 可以这么说，DevOps 距离云和 SDN 一样，还远没有一个被普遍接受的定义。

但 DevOps 的独特之处在于，它的复合概念也经常被混淆和合并。 例如，CD 可以被理解为“持续交付”或“持续部署”。 这两者并不相同，因此不应混淆或合并。 Puppet Labs 在一篇博客文章中很好地说明了这种差异：

您会注意到，定义上的区别在于生产部署是“手动”（持续交付）还是“自动化”（持续部署）。  

问题是，标有“部署到生产”的小橙色框中有大量工作需要自动化。 这不仅仅是部署应用程序及其依赖项（数据库、其他服务、基础设施等）。 它还涉及部署将该应用交付给最终消费者所需的所有网络和应用服务。  这是应用服务发挥作用的地方，也是应用交付（在生产意义上，而不是开发意义上）进入持续部署流程的地方。

为了自动化持续部署流程中的“部署到生产”步骤，必须调配、配置和测试许多活动部件。 这意味着从基本网络到安全性（如防火墙）到可用性（负载均衡）到性能（加速、缓存等）服务的一切。 平均而言，组织使用 11 种不同的应用交付服务来实现其对快速、安全和可用的应用的需求。 每个都必须部署（配置和配置），并且有些依赖于其他的部署。

这些服务中的每一项（对于正在玩游戏的人来说，这就像是圣艾夫斯谜语）都有不同数量的必须配置的特征，将选项设置为真或假，选择算法，建立路线等……

换句话说，从“手动”切换到“自动”并不像听起来那么容易。

什么阻碍了网络？

共享组件和每个应用程序组件之间的差异是实现这些过程自动化的一个重大障碍。 基础设施即代码在应用程序基础设施领域是可能的，正是因为我们可以将基础设施（如 Web 服务器或负载均衡器）专用于应用。 这意味着它的配置文件有点像微服务：它是本地化的，并且专注于为一个应用提供服务。

当我们进入网络和应用服务的世界时，情况并非总是如此。 例如，路由器或交换机的设计目的是为多个应用提供连接和转发服务。 这意味着配置文件必然包含多个应用。 虽然版本控制可能有所帮助，但现实情况是配置与设备而非应用密切相关。应用服务和安全也是如此。

因此，虽然我们都在走向一个 API 即 CLI 的世界，这很好，但我们还必须解决支持每个应用程序（或者如果你愿意，也可以是以应用程序为中心）范例的需求，其中可以根据每个应用程序来管理配置。

这意味着转向微服务风格的网络架构，其中服务是根据每个应用程序进行部署和配置的。 这可以采用专用“设备”的形式（虚拟或硬件，形式因素与本讨论的目的无关）或特定于应用程序的配置（如模板）。

我们到了嗎？

我们正在慢慢接近这一目标，通过声明式的配置和管理模型，利用 API 在每个应用程序上部署模板（即基础设施即代码），但我们还没有到达那一步。 在研究如何协调实现全面成功持续部署所需的自动化方面，还有很多工作要做。

如果我们要将“部署到生产”步骤从“手动”转变为“自动”，则必须包括网络、基础设施、应用服务和安全孤岛，这对于完成从持续交付到持续部署的转变至关重要。 这意味着在自动化层面需要做更多的工作，并且需要进行总体编排，以完全自动化最终推动持续部署投入生产的流程。