This article was originally posted on Wireless Week on January 17, 2017.
Virtualized Network Function (VNF) vendors like Versa Networks, Athonet, and Clearwater are working to re-architect their VNFs for a cloud-native world. They’re doing this because VNFs –like any other application – can leverage the economies and agility of the cloud, if they’re architected as a cloud native-application. This transition can unlock tremendous value for the VNF vendors and their customers (telecom service providers and operators of large enterprise networks) by making network services agile, scalable, and API driven.
Where We Are, Where We’re Going
Many (probably most) network functions – think routers, firewalls, load balancers, and such – have already gone through the transition from physical appliances to virtual ones. Thus, they’ve become “virtualized” network functions, delivered via software that’s abstracted from the underlying hardware.
To be certain, this is a major evolution, but it’s only a step. The next step to cloud-native VNFs adds scaling and management efficiencies that give operators of large networks the same benefits for their VNFs that they’re currently enjoying with cloud-native applications.
Cloud-Native VNFs: What’s in the Box
Take a look at the main attributes that differentiate a cloud-native VNF from one that’s not. A cloud native VNF is:
- Automated, fast deployment, upgrading, and updating, all via APIs
- Simplified management
- Easy and automated scaling as network service demands change
- Lower upfront costs
However, most VNFs are packaged today as a virtual appliance, usually designed to run on a specific set of hardware. They were not designed for cloud-native architectures or hardware agnosticism, and they require human intervention for setup and deployment. They’re not API driven, and they do not support automated scaling as load demands fluctuate. Moreover, most VNFs do not support multi-tenancy.
By contrast, cloud-native VNFs scale easily via common APIs, enable visibility into additional devices in larger environments, and deploy to a wide selection of popular networking platforms. An important factor here is the use of open source standards already widely in use by telecoms and other operators of large networks, like TOSCA and YANG.
What Cloud-Native VNFs Deliver to Operators
All of the value provided by VNFs springs from their software-defined, API-driven nature. This makes deep automation possible, removing human intervention from the process and making fast, reliable deployment and operation possible.
Probably the biggest single value creator for operators requesting cloud-native VNFs is self-management. Cloud-native VNFs offer built-in automation for both installation and configuration. Most also support multi-cloud environments (VMware and OpenStack in the private cloud; AWS, Azure and GCP in the public cloud), which are an increasingly popular deployment and operations model for enterprises. The auto-scaling capabilities of cloud-native VNFs is critical in these environments.
Container support is becoming a bigger deal as well. Platforms like Docker Swarm, Kubernetes, Mesosphere, and CoreOS present new packaging models for VNFs, and cloud-native VNFs offer a shorter implementation path for containers than do their non-cloud-native counterparts.
Monitoring and analytics are a big plus in cloud-native VNF environments, too, as these capabilities are built into the architecture for things like failure detection, performance monitoring, and capacity management. A cloud-native VNF is aware of its behavior and performance relative to pre-defined SLAs, and can automatically trigger remedial action when something goes wrong (and something always goes wrong).
Multi-tenancy is another big win, as it directly impacts the bottom line. Cloud-native VNFs allow multiple users to share the same VNFs, so operators can serve more customers with fewer licenses and hardware.
Managing All those Cloud-Native VNFs: It’s Hard
Turning an existing VNF into a cloud-native VNF can be hard. And it’s not the only hard thing that needs to be done. All those cloud-native VNFs have to be orchestrated. There must be a services layer that manages all that nifty automated deployment, scaling, monitoring, and healing.
Early cloud-native VNF providers had no choice but to build their own proprietary orchestrators. Now there are open-source orchestration options like Cloudify, and they’re built using those open standards mentioned earlier (TOSCA, YANG, etc.). A good cloud-native VNF orchestrator lets VNF vendors and operators build out the management capabilities they need, with the assurance that they’re minimizing vendor lock-in by participating in an open community of like-minded operators, all of whom are trying to accomplish similar end goals with their cloud-native VNFs.
Engage With the Community
Swisscom, Proximus, and Telia had a great idea: they sponsored a Call for Innovation in the cloud-native VNF space. Their goal was to collect the best ideas and proof points for NFV and cloud-native VNF deployment and operations. More than 50 companies submitted entries, and 11 were selected as finalists. Early this year, these finalists will begin working with the three sponsor organizations on proof of concept deployments. This project is worth watching as a crucible for refining the best ideas in NFV, including the design, deployment and operations of cloud-native VNFs that solve real problems for telecoms and operators of large networks.
