传统网络设备商如何向VNF厂商成功转型

作者简介：山石网科资深技术专家，任亮

VNF的技术定义

1、VNF在NFV框架中的位置和功能定义

VNF在ETSI NFV框架中可以说是最重要的组件，因为所有其它的组件都是为它们服务的，它们是具有网络功能的业务虚拟机，利用服务器的计算、存储、网络等资源为用户提供网络相关功能的服务，MANO和VIM则通过API配合起来做VNF的编排管理。

2、区别于传统硬件设备的NFV特性要求

事实上，VNF不仅仅是虚拟机，其在NFV场景下还要具有三大能力，一是支持Cloud-Init用来做0 Day Configuration，二是支持利用NFVI & VIM提供的EPA特性提升自己的性能，三是支持Rest API来支持1 Day Configuration以及满足性能和故障管理需求。从ETSI NFV第二次互操作测试上看，Cloud-Init基本上已经成为大家公认的0 Day Configuration标准；对于EPA特性的要求上，很多NFVI & VIM也能够提供CPU、内存、网卡等各种可提供硬件加速的能力，包括CPU Pinning，NUMA，Huge Pages，DPDK，甚至SR-IOV；但定义Rest API接口的SOL002标准刚刚发布不久，已经落地的还不多。VNF后续的演进是容器形态，这样才能完全满足Cloud-Native的定义和需求，具有极强的健壮和高可靠性。

传统网络设备厂商在向VNF厂商转型过程中的优势

1、积累了多年的网络业务功能

传统网络硬件设备厂商在网络和安全领域的技术积累多年，无论是硬件制造、网络和安全操作系统优化以及网络和安全应用功能上，都已经做的十分成熟，不仅能满足用户需求，而且质量也都经过了打磨，在转向做VNF时，完全不用再花较大的经历在业务功能特性上。

2、面向行业用户的品牌知名度

传统网络硬件设备厂商在网络和安全领域的用户和品牌也积累多年，尤其是运营商和金融行业，对投资和业务风控比较严格和谨慎，一旦大品牌取得份额，小品牌很难再进入。传统网络硬件设备厂商转型做出来的VNF产品也可以继续沿用既有的品牌，在既有的硬件市场里接续下来，形成良好的过渡形势，再根据VNF产品的特点，非常可能再拓展一些以前硬件产品没有覆盖到的用户。

传统网络设备厂商在向VNF厂商转型过程中的劣势

1、对云计算（IT）技术的积累不足

VNF的产品形态是虚拟机，属于IT技术范畴，而很多传统网络硬件设备厂商在云计算（IT）技术领域都积累不足，从研发到售前，都是这个状态。CT技术的特点是低耦合、高内聚，一个硬件盒子部署在用户的网络中，只要保证把自己弄明白，剩下的就是网络连通性；而IT技术的特点却是环境强相关性，VNF产品本身的问题都已经是小问题，而VNF适应环境，并跟环境内其它组件进行配合的问题才是关键。很多传统网络硬件设备厂商对云计算（IT）环境并不熟悉，也就导致做出的VNF产品仅停留在虚拟机的层面，而事实上，VNF并不仅是一个简单的虚拟机。

2、对软件销售和服务模式的经验不足

传统网络硬件设备的销售模式是一次性购买，长时间使用，而虚拟机形态的VNF产品则是按需购买，短时间使用。这是完全不同的两种销售和服务模式，几乎所有的传统网络硬件设备厂商都会不适应，很多刚做出VNF产品的厂商还是沿用之前的硬件产品的销售和服务模式，就会遇到很多代理和渠道的不适应，影响该有的销售业绩。同时，VNF产品又会遇到软件产品都会遇到的盗版问题，为了防盗版，VNF厂商不得不投入大量的人力物力，然后在实际操作中，又会遇到这样那样的麻烦，用户不愿意接受硬件思维的版权控制方案，这些问题在硬件时代都是不曾想到的。

传统网络设备厂商向VNF厂商成功转型的必经之路

1、硬件盒子向虚拟机镜像的转变（包括非X86技术向X86技术的转变）

这一步是基础，对于硬件时代就使用X86技术的厂商来说，比较容易，只需要继续考虑不同Hypervisor的驱动即可，而在硬件时代使用非X86技术的厂商则需要额外考虑平台移植的问题，因为字节序不一致。通常来说四大Hypervisor都要支持，XEN、VMware、KVM、Hyper-V，这是后面上公有云的前提，例如AWS用的XEN，阿里云用的KVM，AZURE用的Hyper-V，VMware则是私有云中常见的Hypervisor类型。

2、非标准NFV的公有云镜像市场应用的经验积累

这一步也很重要，它决定了至少一半传统物理网络技术方案向云中网络技术方案转型的技术积累，不同公有云的虚机上架和使用流程不同，从0 Day Configuration到组网，每家都有不同的方案和要求，经过AWS、阿里云、Azure三大公有云上架和组网方案过程的洗礼，VNF厂商能够积累大量的云中网络技术方案的经验，为后面遵从标准NFV架构打下坚实的技术基础。

3、标准NFV的Cloud-Native VNF的标准与技术跟进

目前来看，标准NFV架构的遵从是终极阶段，ETSI的NFV技术框架经过5年多的技术标准制定和落地，已经具有了相当的技术成熟度，这个时候是VNF厂商跟进标准NFV架构的最佳阶段。经过了前面虚机镜像和共有云上架两个阶段，VNF厂商跟进标准NFV架构的技术难度不大了，主要是API接口等相关工作。有远见的VNF厂商此时还会开始进入产品容器化的预研阶段，因为标准NFV架构中的VNF的终极目标是Cloud-Native，而容器是达到这一目标必须的产品形态。

4、传统CT技术向云计算（IT）技术思维方式的转变

在技术转型的必经之路上，必然伴随着思维方式的转变，深刻理解到IT技术特点的环境强相关性，VNF厂商需要把主要的经历投入到产品的环境适应性和跟环境内其它组件进行配合的研发上。VNF厂商不再仅熟悉网络技术，也开始熟悉IT技术，这更加有利于网络技术向IT技术的融合，因为云中的网路和IT本就是一体密不可分的。VNF厂商的技术人员也需要从CT技术向IT过渡，知识体系需要革新，这可能会是一个痛苦的过程，然而必须在这条路上不断向前，因为后面还有DT技术需要跟进，没有IT技术阶段的过渡，CT技术是无法直接转向DT技术的。

5、传统硬件向软件销售和服务模式的转变

随着VNF产品的技术成熟和推向市场，VNF厂商如果还是按照传统网络硬件设备的销售模式来售卖VNF产品，一定会遇到很多问题和阻力。软件和硬件产品的成本和收益计算方式本就是完全不同的，VNF厂商必须在VNF产品的销售模式上从传统硬件向软件销售和服务模式做出转变，这一过程并不是一蹴而就的，VNF毕竟还是网络产品，直接拷贝操作系统和应用软件的销售和服务模式并不可取，如何在传统网络硬件设备的销售模式和新的软件销售和服务模式之间做出平衡和合理过渡，需要VNF厂商与集成商以及最终用户的共同磨合。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。