There is little doubt in the telecoms industry that network functions virtualisation (NFV) will be the foundation for communications networks of the future. But for NFV to deliver the benefits expected and promised, its constituent virtual network functions (VNFs) must first be developed using cloud-native design principles, writes Ian Maclean, the chief marketing officer of Metaswitch.
Network operators are already working on the deployment and delivery of 5G mobile connectivity and services. This next generation of mobile cannot be run on today’s network functions, which are typically inflexible, expensive to scale and costly to upgrade. According to industry bodies like ETSI, 5G networks need to be [highly] scalable, deliver ultra-low latency connectivity and support a huge number of concurrent sessions. Further, network performance must be reliable and underpinned by a robust security strategy. Essentially, 5G isn’t just about RAN upgrades, it also requires a new kind of core network to deliver on the service, scale, security and quality-of-experience demands.
These demands will present challenges for network operators. If network services are to scale to billions of devices, cost effectively, then the VNFs that deliver them must do likewise. Most operators accept the general premise of NFV – to decouple network functions from hardware and to run these virtualised network functions (VNFs) in a generic IT cloud environment. But many have yet to see how a simple porting of existing software into a hypervisor environment can do anything other than continue the limitations of proprietary, appliance-based solutions. That’s because it can’t. If it’s the same software running in a hypervisor, just on commercial hardware, then not only will the same problems persist, but performance is likely to be seriously degraded.
A cloud native approach to NFV
When NFV technology was first introduced, operators wanted their VNFs to work as well as their existing network appliances, and as quickly as possible. Keen to demonstrate early progress, some vendors chose simply to port their established physical network functions into a COTS (commercial off-the-shelf) server environment. Unfortunately, it quickly became apparent that there were significant issues and disadvantages with simply porting existing code. For example, monolithic code ported from proprietary appliances struggles to deliver anything like the same performance in the cloud. Feature releases cycles are still delivered on an annual basis, and the software has clear call, traffic or number of subscriber limits. These problems are not evident when code is well designed from the ground up to be truly cloud native.
So what does it mean for a virtual network function to be cloud native?
Fundamentally, cloud native VNFs forsake the monolithic software architectures of old for an approach that is based on smaller microservices that are deployed in virtualized containers. These microservices are small, independent processes that are highly composable and reusable, scale independently, and can be incrementally deployed and enhanced. Microservices essentially enable service providers to introduce and upgrade applications more quickly. Compared to virtual machine (VM) deployments, containers are lighter weight, considerably faster to instantiate and more able to interact through RESTful application programming interfaces (APIs). With a much smaller memory footprint, containers can run considerably more efficiently and at significantly higher density than VMs. Container-based processes are also easier to scale, chain, heal, move and back-up.
Cloud native virtual network functions achieve notionally limitless and cost-effective scale by abstracting call state details into a backend (open source) database. In this way, traffic can be passed to any microservice without needing to correlate particular processes with particular media sessions. Likewise, microservices can be added as needed to handle increased capacity or back-up needs. And perhaps most importantly, cloud native VNFs are designed with operations automation in mind, conscious of the need to spin up quickly under the control of next generation management and network orchestration platforms, and to be easily chained to form new services that will be consumed in a digital marketplace.
The time is now
Whilst 5G will require substantial changes to the way networks are built – driving the need for scalable, configurable cloud native VNFs – the growth of LTE-based services is already pushing networks to their limits. With an escalating number of IoT and smart home applications now appearing in market, there is a pressing need for network functions that are designed to fully leverage the cloud and not simply reside in it. Cloud native IMS cores and session border controllers can bring immediate value to operators looking to expand their IMS capabilities into the enterprise, or to slice parts of their existing networks for specific, quality-dependent applications such as the connected car.
As even more mobile end points come to market and more IoT-driven experiences arrive, the range of services that consumers demand from network operators will expand beyond traditional boundaries. We are entering a new era of communications, one where the scale and cost-efficiencies demanded by 5G, dictate that NFV implementations cannot afford to be built on anything but cloud native VNFs. That’s NFV done right. And it’s an architectural decision that will last a generation.
