一、NVF的承诺
网络功能虚拟化(Network Function Virtualization, NFV)是将网络功能(如路由)实现到云环境中的一种方法。产生的虚拟网络函数(VNF)被设计成在需求增加时创建VNF的副本来共享流量负载。随着需求的减少，VNFs的额外实例将被删除。正是这种动态特性，使网络能够根据需求自动增长和收缩，使得NFV的前景如此诱人。
此外，NFV承诺大幅节省成本，特别是当提供者转向管理网络功能的虚拟实例而不是物理设备时。设备的软件版本比物理设备便宜，此外，欧洲电信标准协会(ETSI)的NFV标准假定自动化可以节省运营成本，该标准已在全世界得到采用。
二、自动化和NFV是密切相关的
NFV自动化的核心原则存在于管理和编制(MANO)层。这一层包括一个NFV协调器，它通过使用VNF管理器(负责创建、修改和销毁VNF实例)和虚拟基础设施管理器(VIM)来管理环境的计算、存储和网络部分，从而管理整个环境。这三个组件在网络的NFV部分提供了自动化。
当端到端服务不仅仅涉及NFV组件(这是很常见的)时，就会出现网络自动化问题。大多数服务还包括物理网络元素，例如从提供者网络到客户的住宅或业务场所的光纤或铜连接。结果是一个操作过程，它是部分手工(或者可能由遗留系统自动化)和MANO自动化nfv相关的部分。通常情况下，这些独立的自动化过程不会相互操作。
三、为什么NFV的承诺还没有实现?
1、缺乏互操作性
NFV停滞不前有很多原因，其中一个主要原因是缺乏互操作性。有许多与管理相关的选项。通常，这些不同的解决方案针对特定的产品或服务。例如，可能有一组用于虚拟防火墙产品的管理工具，另一组用于SD-WAN产品，还有一组用于虚拟CPE产品。这些都是基于NFV的解决方案，它们来自不同的供应商，如果没有复杂的集成就不能很好地协同工作。此外，现有的物理网络是由另一组系统管理的，这些系统并不是本地集成的，结果是多个编排器、多个控制器和多个管理所涉及的物理设备的遗留OSS系统。
2、技术问题
采用停滞不前的第二个原因是VNF技术问题过多。最初的VNFs是基于虚拟机的。供应商开始将运行在其专用硬件上的相同代码移植到虚拟机。结果是一组VNFs，由于性能上的极端差异，它们没有希望与物理设备竞争。在虚拟机上使用的软件针对专用硬件进行了优化，并在虚拟机上以次优水平运行。随着时间的推移，许多供应商开始使用容器技术并从头重写VNF软件。今天，VNFs不再移植没有在虚拟机上运行的现有代码，而是作为容器本机开发。这样可以更快地创建新设备，以及由于遇到问题而修复或销毁和重新创建这些设备。
为管理虚拟机而构建的VIMs(虚拟基础设施管理器)通常也不管理容器，反之亦然。因此，混合使用基于虚拟机和基于容器的VNFs的客户在这个领域还面临多个自动化系统。此外，供应商通常会在VNFs中附带自己的VNF管理器。在多供应商网络环境中，这只会增加需要自动化的系统数量。
3、许可证问题
与购买物理设备相比，供应商未能实现降低购买VNF许可证成本的承诺。在某些情况下，供应商收取的价格与物理设备相同，尽管成本较低。供应商通常没有基于数量的定价，也没有针对批量购买的供应商的其他优惠。这个问题已经导致许多提供商重新考虑使用基于nfc的解决方案，并面临学习新工具的挑战。
4、操作技能差距
开发人员不是网络工程师，网络工程师也不是开发人员。NFV和SDN引入的概念不仅仅是管理类网络软件，而是将网络真正变成软件。这个新学科所涉及的技能集不容易从网络工程操作组转换过来。NFV中的一切都基于模型(服务和设备)，这对网络工程师来说是陌生的。类似地，虽然网络运营商IT部门的开发人员将理解建模以及所使用的建模语言的语法和功能，但是他们对建模的实际设备和服务没有经验。
四、如何快速启动NFV的采用?
1、真正的互操作性
采用NFV最令人畏惧的障碍是管理组件的众多选项所造成的混乱。目前存在的各种解决方案不会有机地变得可互操作。然而，由于这些解决方案都是在过去几年中创建的，所以在设计时考虑了通过api充分展示其功能。这为问题的解决提供了基础。
网络自动化的一种新方法就是只考虑这个场景。任何多供应商网络都将具有多个编排器、控制器和其他网络管理系统。通过使用这些系统的api并提供一个统一的管理层，以公开它们在智能网络自动化工作流中使用的功能，可以从用户那里抽象复杂性。这种新方法关注的是完全端到端自动化，来自多个系统的数据联合，而不是创建更多的数据副本，并且是一个完全与供应商无关的解决方案，从基于意图的角度关注服务。
这种方法的关键组件包括一个基于模型的解决方案(理解常见的建模语言，如YANG、TOSCA和YAML)、API驱动的解决方案、专注于联合(来自外部系统并通过来自这些系统的API使用)和低代码的解决方案。
2、Low-Code操作
随着我们向类似于开发人员的管理网络的方法发展，网络元素变得完全基于软件，网络工程师和开发人员之间的技能差距开始发挥作用。当我们将NFV和SDN引入网络时，它与网络的世界发生了碰撞。许多解决方案需要高水平的开发技能才能有效地使用，但是通常拥有这些技能的人没有网络知识来确切地知道应该编写什么代码。未来的方法是通过一种解决方案来缩小这种技能差距，这种解决方案不仅联合了各种功能，使多个系统可互操作，而且还为网络工程师和开发人员提供了一种画布，这种画布几乎不需要编码就可以创建和使用自动化。这种解决方案必须抽象出对开发技能的需求，以便网络工程师能够自给自足，同时为更复杂的自动化提供一些定制开发。这种方法将有助于减少合并IT和网络工程这一常常痛苦但不可避免的过程。
3、许可对齐
VNF许可和管理必须与传统的基于软件的许可模型保持一致，而不是继续基于大多数供应商继续遵循的遗留硬件模型。许可模型的整合将允许使用企业IT部门现在使用的相同或类似的工具。此外，管理工具的整合将减少与自动化解决方案交互的不同系统的数量。
NFV的承诺是引人注目的——与传统网络设备构建的网络相比，高性能网络具有更大的可伸缩性、灵活性和适应性，成本更低。通过解决NFV面临的问题，并使技术更容易被更多的运营商使用，IT专业人员将更有可能采用该技术并自动化他们的现代网络。
原文链接：
https://thenewstack.io/why-has-nfv-stalled-and-how-can-we-jumpstart-it/
