集成是实现持续部署的障碍

API 不是集成。 它们是实现集成的一种手段。 从 ITOps 提到的挑战来看，这些挑战不足以让 IT 实现连续性。 

在应用开发领域，“集成”一直是一个贬义词。 从 DLL 到共享库，从 ESB 到消息队列，我们​​探索了将应用s与其他应用程序和服务集成的无数方法。

在网络管理领域，它显得尤为重要。 集成是管理多供应商、异构网络设备和应用服务管道（用于交付和保护应用s）固有的复杂性的关键。

如今，该流程的自动化程度日益提高。 开发人员和 DevOps 成功克服了集成挑战，构建了持续开发流程。 他们现在期望——不，是要求——IT 对部署管道做同样的事情。

IT 正在响应。 根据“ NetOps 与 DevOps 相遇”： 网络自动化现状”，相当大比例的生产流程至少是部分自动化的。 

但采用持续部署并非没有挑战。

通常，我们在调查中看到“文化”被视为 DevOps 和 DevOps 相关实践的最大抑制因素。 在网络自动化状况调查中，文化位列三大因素之一。 然而，这并不是最令人沮丧的事情。 它也没有获得第二名。 这些位置都被因技能差距而产生的挫败感以及我最喜欢的四个字母的词“融合”所占据。

事实上，这两个挑战是相关的。 技能差距在一定程度上是导致融合度降低的一个重要原因。 这是因为 NetOps 不是开发人员（这可能会让您感到惊讶）。

这才是真正的问题。 DevOps 在实现持续交付方面如此成功的原因之一是它主要由开发人员组成。 生活和呼吸都离不开代码的开发人员。 他们知道如何整合需要整合的内容。 NetOps 不一定具备那套技能。 部署管道主要由通过协议集成的设备和系统组成。 定义明确、基于 RFC 的协议不需要基于代码的集成，因为它们的设计目的就不是如此。

对于 NetOps 来说，这是一个全新的挑战，而且他们还未做好准备或不具备应对的技能。

API 无法解决这一挑战。 虽然 API 支持的基础设施仍然很重要（ 2018 年application交付状况调查的四分之三的受访者都认同这一点），但 API 并不是集成。 它们实现了集成，但是，将不同的设备和系统与管理控制台和控件插入和连接起来的实际工作仍然是 IT 的责任。 他们并不一定具备这样做所需的技能。 这些挑战对日常运营产生了深远的影响，因为它们最终决定了部署流程采用非常手动的方式。 

这解释了超过一半（52％）的 NetOps 采用的主要“基于 CLI / 脚本的每设备”管理方法。 DevOps 和 NetOps 所引用的多供应商、协调的运营方法之间存在明显差异。 29% 的 DevOps 采用多供应商编排方法，而只有 12% 的 NetOps 采用同样的方法。

这种差异充分表明，NetOps 需要采取更好的集成方法，社区和市场也需要同样的热情来克服集成挑战。

如果您想了解这个自动化和编排的新世界，请查看我们的免费在线Super-NetOps 程序。 除了专注于将自动化和编排应用于 F5 技术之外，它还提供使用 REST API、使用 Postman 等工具以及制定自动化剧本所需的基础知识。