One of the biggest frustrations that service providers currently have with implementing network functions virtualization (NFV) is on-boarding virtual network functions (VNFs). It’s a common refrain that on-boarding VNFs is very difficult. The reason why this process is proving harder than anyone expected is largely due to the origins of the VNF software – that is, was the VNF originally designed for an appliance or for the cloud?
I discussed this on-boarding issue and the importance of cloud-native software in a recent interview with Telecom TV. Most traditional telecom vendors are working with software that they’ve had running on their own appliances for many years and adapting it to run in cloud environments – essentially porting software from vendor-specific appliances to the cloud. But when it comes to on-boarding VNFs that were not designed for the cloud, the process involves a lot of manual operation and configuration with complex startup instructions. It requires creating a raft of additional software just to do the onboarding process, including extending the orchestrator, hand-crafting scripts, and lots of debugging.
But the pitfalls of complex on-boarding can be avoided if the VNF software was designed and built from scratch and specifically for the cloud. Software designed for a cloud environment looks very different in its overall architecture. It’s decomposed into microservices, it scales out and scales in, it can be instantiated on many virtual machines (VMs) running in parallel and interchangeably. These are architectural patterns that have become common on the web but are completely alien to most telecom equipment vendors.
Cloud-native software is inherently designed to be easy to deploy and easy to orchestrate. Metaswitch recognized early on the importance of taking a cloud-native approach to designing VNFs and we’ve done a great job of bridging this gap. We’ve taken these cloud-native techniques and brought them to telecom standards like IP Multimedia Subsystem (IMS) and all the 3GPP specifications associated with it. Our experience has been that we can get our VNFs on-boarded in a matter of days, compared to weeks or typically months for most of the other VNFs we’ve seen.
More operators are now realizing the value that cloud-native VNFs add to their network virtualization strategies. It’s not only a critical factor in automating and streamlining the on-boarding process to virtual machines, but also it will be even more important as NFV evolves to embrace containers.
Containers or “containerization” is widely considered to be the next phase for NFV, or virtualization 2.0. It’s basically a different way of deploying software in a virtualized form than in a virtual machine. Containers use much less overhead than virtual machines, can spun up quickly, and they’re inherently easier to orchestrate. They take care of scaling, healing, load balancing, which are all complicated to achieve with virtual machines. But not all software can be deployed in containers. Trying to containerize software that was originally written for a physical appliance is not likely to work because the technical characteristics of the software simply don’t lend themselves to containerization.
But if the software is cloud-native, originally written for the cloud, then containers are easy.
For watch the full interview, please visit Telecom TV.