API本身并不等同于集成，而是实现集成的一种手段。从ITOps提到的挑战来看，仅靠API不足以让IT实现持续运营。
在应用开发领域，“集成”一直是个令人头疼的词。从DLL到共享库，从ESB到消息队列，我们探索了各种方法，将应用与其他应用和服务集成起来。
在网络管理领域，集成尤为重要。由多家供应商的异构网络设备和应用服务组成的交付链负责交付和保护应用，而集成一直是管理其固有复杂性的关键。
如今，这一流程的自动化程度越来越高。开发人员和DevOps团队已成功克服集成挑战，构建了持续开发流程。现在，他们不仅期望，而且要求IT团队也实现部署流程的持续化。
IT部门正在积极响应。根据《NetOps与DevOps融合：网络自动化现状》，相当一部分生产流水线已实现至少部分自动化。
但采用持续部署也会面临挑战。
通常，调查会将“文化”列为阻碍DevOps及相关实践的主要因素之一。在《网络自动化现状》调查中，文化位列前三。不过，它并不是最令人困扰的问题，甚至没有排在第二位。占据前两位的分别是技能缺口，以及我最喜欢的四字母单词“integration”（集成）。
事实上，这两项挑战相互关联。技能差距在一定程度上导致集成成为一大困扰。原因在于，网络运维人员并不是开发人员，这一点可能会让您感到意外。
这才是真正的症结所在。DevOps在推动持续交付方面卓有成效，原因之一是其成员主要由开发人员组成。这些开发人员以代码为业，深谙代码之道，知道如何集成需要集成的内容。而NetOps不一定具备这类技能。部署流水线主要由通过协议进行集成的设备和系统组成。这些协议定义明确且基于RFC，其设计初衷就是无需通过代码进行集成。
这对NetOps来说是一项全新的挑战，而他们未必已做好准备，也未必具备应对这项挑战所需的技能。
这一挑战无法仅靠API解决。支持API的基础设施仍然很重要，我们的《2018年应用交付现状调查》中有四分之三的受访者也认同这一点。但API本身并不等同于集成。API可以支持集成，但使用管理控制台和控制功能连接并整合不同设备和系统的实际工作，仍需由IT人员负责，而他们未必具备完成这项工作所需的技能。这些挑战会对日常运营产生深远影响，最终导致部署流水线高度依赖手动操作。
这解释了为何超过半数（52%）的NetOps主要采用“基于CLI或脚本、按设备管理”的方法。DevOps与NetOps采用多供应商编排式运维方法的比例差距显著：29%的DevOps采用这种方法，而NetOps中仅有12%。
这一差距充分表明，NetOps需要采用更有效的集成方法，而社区和市场也应以同样的热忱应对集成挑战。
如果希望了解自动化和编排这一新领域，不妨查看我们的免费在线Super-NetOps课程。该课程不仅重点介绍如何将自动化和编排应用于F5技术，还提供使用REST API、Postman等工具以及编写自动化行动手册所需的基础知识。
关于作者
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服务。