Why Cloud-Native VNFs Are Really Important For NFV

DZone 's Guide to

Why Cloud-Native VNFs Are Really Important For NFV

Be sure to incorporate cloud-based virtual network functions into your infrastructure to implement software on your virtual machine.

· Cloud Zone ·
Free Resource

VNFs, or virtual network functions, are the software implementation of network function equipment packaged in a virtual machine, on top of COTS hardware NFV infrastructure. VNFs are core part of NFV, or network functions virtualization, as we know the basis of NFV was to virtualize the network functions and software based to reduce cost and gain full control over network operations with added agility and flexibility benefits. We can say that majority of NFV operations are focused towards how VNFs can be served in NFV infrastructure to introduce new services for consumers. In future, we can expect major developments will be related to VNFs only.

VNFs and NFV are separated by the fact that VNF is provided by external vendors or open source communities to service providers who are transitioning their infrastructure to NFV. There may be several VNFs which combine to form a single service for NFV. This adds complexity to the overall NFV purpose of agility where VNFs from different vendors need to deploy in NFV infrastructure having a different operational model. VNFs developed by different vendors have different methodologies for complete deployment in existing NFV environment. On-boarding VNFs remains a challenge due to lack of standard processes for complete management from development to deployment and monitoring.

At a basic level, traditional VNFs comes with limitations:

  • VNFs consumes a huge amount of hardware to be able to highly available;
  • VNFs are developed, configured and tested to run on specified NFV hardware infrastructure;
  • Need manual installation, configuration and deployment on NFVi;
  • API not provided for VNF to enable automated scaling, configuration to serve the sudden spike in demand for utilization;
  • Not supporting multi-tenancy. VNFs cannot be easily shared in infrastructure for reuse.

Building cloud-native VNFs is a solution for vendors and this is a revolution in software development to have all cloud-native characteristics to VNFs. Features we can expect as cloud-native VNFs are containerized functions, microservices based, dynamically managed and specifically designed for orchestration. The major differentiator of cloud-native VNFs from traditional VNFs could be self-management capability and scalability.

Building cloud-native VNFs overcomes the previously discussed limitations of traditional VNFs and provides the below benefits:

  • Cloud-native VNFs have APIs which enable
    • Automated installation and configuration
    • automated scaling when dynamic requirement from network
    • self-healing or fault tolerance
    • automated monitoring and analysis of VNFs for errors, capacity management and performance
    • automated upgrading and updating VNFs for applying new releases and patches
  • Standard and simplified management enable less power consumption. Reduction of un-necessary allocated resources.
  • Reusability and sharing of processes within VNFs can be achieved. VNFs can be easily shared within NFV environment.

NFV is a key technology used in the development of 5G networks. But NFV is going through a maturation stage where NFV solution providers are resolving many challenges like automated deployment, VNF onboarding, etc. Developing VNF and deploying into NFV infrastructure sounds simple but it raises various questions when it comes to scale, configure or update VNFs. Any task related to VNFs needs manual intervention, leads to more time consumption for launching or updating new services for service providers. To deliver promise of agility by NFV in 5G need exceptional automation at every level of NFV development. Building cloud-native VNFs seems to be the solution but it is at very early stage.

network functions virtualization ,nfv ,cloud (add topic) ,cloud computing

Published at DZone with permission of Sagar Nangare . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}