The OPNFV Project is taking square aim at getting NFV to cloud-native status with its sixth and latest software release, Fraser, announced today. This release includes closer integration with the Cloud Native Computing Foundation and its Kubernetes container automation, as well as more testing tools for cloud-native functions and operations, along with other steps toward hardening NFV in general.

Given that the earlier virtual machine-based network functions virtualization isn't going away any time soon, Open Platform for NFV Project Inc. will continue work on both fronts, says Heather Kirksey, vice president of Community and Ecosystem Development for Linux Foundation , which hosts OPNFV.

"You can look at Fraser in two directions; one is the continued work on hardening and operationalizing the existing VM-centric platform that is out there, and then there is the kind of the shinier news that we did a lot of work around cloud native," she says in an interview.

Fraser -- named for a river in British Columbia -- also marks the first software release since the Linux Foundation reorganization and creation of LF Networking, which includes OPNFV. So not surprisingly, it reflects the closer integration of OPNFV with other LFN projects including Open Network Automation Platform (ONAP) , as well as OpenStack .

For example, OPNFV and ONAP worked together on architectural work related to the former's Functest project, so that it can be reused by ONAP, thus avoiding replicating the work. "Orange helped out with a lot of that work and they were able to speed up the reporting of Functest. They were able to create their first test container for ONAP in just a day and reduce the size of the test VM by ten times," Kirksey says.

An Orange (NYSE: FTE) white paper on that topic can be read here.

Figure 1:

But the cloud-native stuff is a headline-grabber, and that includes extending OPNFV's ongoing work in CI-CD [continuous integration-continuous development] to Cloud Native Computing Foundation and Ansible, the IT software automation platform, expanding cloud-native NFV capabilities in nine different projects and doubling the number of Kubernetes-based scenarios from four to eight. OPNFV integrated some of CNCF's work into what it is doing specifically related to logging, tracing, monitoring and package management, to go beyond basic container orchestration to cloud-native operational requirements.

"We have started integrating more of that full cloud-native ecosystem, in addition to the baseline Kubernetes," Kirksey says. "In addition, we have also looked at a lot of the other cloud-native projects and have worked on integration with a number of those including Prometheus, OpenTracing, we are beginning to look at integration with ServiceMesh, the Istio project, and Fluentd, which is logging and tracing."

OPNFV is also starting to deploy containerized VNFs in its test methodology, she says, and will continue to build a library of those for both front-end and ongoing testing. "We have this great huge library of original cloud infrastructure testing and we now are building the library to be able to more appropriately address the cloud-native and Kubernetes ecosystems," Kirksey says.

OPNFV is also incorporating some of the work done by FD.io, another LFN project, around Kubernetes and the Contiv CMI plug-in.

With all of that, the project continues its ongoing work to improve the OpenStack upgrade process to get to zero downtime, she adds, and improving testing particularly in looking beyond day-zero testing to longer running performance testing.

Boost your knowledge of cloud-native software and innovations driving data center transformations! Join us in Austin at the fifth annual Big Communications Event May 14-16. The event is free for communications service providers -- secure your seat today!

CI-CD remains an area of focus because it is becoming more critical to operators looking to operate more on a dev-ops basis, Kirksey notes.

"One of the nice things about OPNFV is that because we had such heterogeneous requirements from the beginning around doing the systems integration work, we were never able to cheat," she says. "We had to build really strong CI-CD, and automated testing and automated CI-CD from the beginning and so we've really built from that and I think we have now come up with something that begins to look robust enough for people to start adopting into their companies."

Tim Irnich, program manager, Cloud Open Source & Ecosystem at Ericsson, says CI-CD also is becoming more critical to network operators who want to avoid vendor lock-in.

"The more operators talk with their vendors around CI-CD and DevOps, the more they realize that this actually means a different collaboration with their vendors than the one they've traditionally had," he says in an interview. To handle automatic or semi-automatic updates from vendors requires a tighter coupling from a technical viewpoint, but doing this coupling in a vendor-specific way can prevent network operators from easily changing vendors going forward.

"This makes operators very interested in industry practices in order to do this," Irnich adds, "so they don't accidentally lock themselves into the solutions and habits one particular vendor has developed in this space. That makes the work of OPNFV in this area extremely interesting for operators."

— Carol Wilson, Editor-at-Large, Light Reading