Since NFV – Network Function Virtualization officially proposed by ETSI in 2012, we have seen exponential development in NFV ecosystem by a contribution by many large vendors and open communities. Till now, NFV stayed in immature stage due to lack of common information or deployment model and certain specified guidelines. But in the last few months, telecom network providers along with leading network solution vendors started to test 5G networks which are mainly based on NFV/SDN technologies. Initially the majority of NFV deployments comprising MANO (Management and Orchestration) layers, NFV infrastructure (NFVi) and development of a core part of NFV i.e. VNFs (Virtual Network Functions) focused towards utilization of virtual machines to host VNFs. But, due to the fact that NFV is backbone technology for 5G networks, it will demand large scale deployment with agility, portability, scalability, highly automated, lower overheads along with minimum CAPEX and OPEX for telecom service providers.
Here, container technology came to rescue and brings a lot of benefits to NFV infrastructure. Containers have existed in Linux in form of LXC containers but with the emergence of Docker Inc., this technology exploded and now with Kubernetes orchestration engine, containers are easily integrated and managed from low to high scale deployments in maximum use cases.
Virtualization is traditional and proven technology which brought huge innovation at data center level enabled businesses to introduce a variety of digital products – enhanced the digital life. As telecom service providers started to think about 5G networks based on NFV, virtual machine deployments were not enough considering a scale and demand for agility in service launches and low latency requirements to support high-end technologies like machine learning, real-time analytics, autonomous cars, virtual reality and augmented reality products, etc.
Due to this reason, for telecom use case, software virtualization approach has to be different than we have seen in previous cases where such agility and performance was not much matter.
Let’s take a look at features offered by both – virtual machines and containers and compare them for NFV use case.
- Resource overheads: Virtual machines are hardware or system level virtualization and Containers are OS-level virtualization. To run a virtual machine guest OS and hypervisor is need on top of server OS. Which means there will be a limited number of isolated VNFs can be mounted on a single server and need more resources (CPE, memory, etc) for guest OSes. Adding to it, there will be more number of VNFs needed to run as – to form a single network service NFV deployment chains the multiple VNFs together. Already, there is huge infrastructure rebuilding is involved at the core and edge part of telecom networks for powering 5G networks with NFV. Due to this fact, telecom network providers will be expecting less number of resources to be utilized to generate high throughput by running maximum number of VNFs. To cope up with it containers can be utilized to host VNFs. Containers are lightweight package bundled with all dependencies to run a single native application. It is an image file package which can be easily ported across various operating systems environments. Containers can be deployed on a host OS and on top of it container orchestration engine is installed which manages the lifecycle of individual and isolated VNFs. OS level set up for containers incur less computing resources need to run the VNFs.
- Faster Deployment & Portability: Containers contain only binaries and dependencies required for application execution along with information for interconnection with other containers and system. It is packaged in a small file having less file size as compared to virtual machine file which enclosed the whole OS encapsulated application environment. Due to lightweight nature containers can move and easily deploy in NFV infrastructure. This advantage helps telecom network providers to launch the new services much faster way to stay ahead in the competition.
- Security: VNFs hosted on Virtual machines has been proved to be more secure as it was isolated by hypervisors at a system level. Containers were lagging security due to sharing same OS kernel i.e. malfunction with OS causes a threat to all container VNFs sharing same kernel features which are not isolated. But due to recent developments in IT communities, kernel security solutions like SELinux and AppArmor can ensure security for container-based VNFs.
- Scalability: Autoscaling ability is the key requirement for telecom network providers to address the sudden resources and services demand by consumers. NFV infrastructure has to be on top of it to provide consistent service. As containers are lightweight, resources required to run container based VNFs can be easily scaled as per demand at MANO layer where Kubernetes container /management orchestration engine is deployed as VIM component. Kubernetes extends automation and dynamic orchestration ability for containers at MANO later of NFV infrastructure. Resource provisioning to virtual machines takes more time than containers.
- Resiliency: In case of failure or error at VNF package a whole service formed with multiple VNFs may get affected. Again, due to lightweight nature and managed with Kubernetes container based VNFs can be easily debugged and replaced. Kubernetes provides self-healing features like auto-placement, restart, and replacement by using service discovery and continuous monitoring at NFV infrastructure. For virtual machine it takes time for rebooting and spin up a new virtual machine to push to working state.
- Agility: Multiple VNFs are chained together to form a new service. For some cases, telecom network providers need to dynamically launch new service or upgrade existing service at runtime. As containers are hosted inside the same host OS, it becomes easier to pass on instructions to deploy new container-based VNFs. Dealing with virtual machine for dynamic service enablement takes more time as instructions have to pass through guest OS and hypervisor to each virtual machine hosted VNFs.
Cloud Native Approach in NFV with container based VNFs
Cloud native application development is a new trend which IT ecosystem has accumulated to enable faster service launches for enterprises who want to stay ahead in the competition. A cloud-native approach promotes a DevOps methodology by integrating continuous integration (CI) and continuous deployment (CD) in application release cycle. As telecom networks impacted with NFV, it becomes imperative for them to switch to cloud-native approach for shortening faster time to market to launch or upgrade VNFs based services. Telecom network providers can take advantages of cloud-native approach as VNFs can be deployed and scale within containers. Cloud native approach using container-based VNFs gives more agility in service launch and upgrade.
To enable cloud-native approach, VNFs can be decomposed into microservices hosted within different containers, automatically scaled and intercommunicated using well-defined APIs. Kubernetes can be used to handle orchestration and control operations to handle several microservices. It takes less time to upgrade the service as there is only need to update specific microservices. Also, CI/CD methodology can be applied as VNFs are decomposed into smaller chunks in microservices.
Deployment Models of using VMs and Containers
There are 3 ways telecom network providers can think of deploying VNFs. Virtual machine only, containers only and a mix of both in NFV infrastructure. Another way could be some VNF components can be deployed in containers and some are in virtual machines. But it makes more complex architecture which someone will hardly use depend on necessity.
There are challenges which limit the use of container-based VNFs only NFV infrastructure. Currently, containers are growing technology as compared to virtualization. So, it is still not advisable to deploy VNFs in a container only. Support for VNF based containers are only on selected operating systems like Linux, Windows, and Solaris at service providers end. Many NFV infrastructures at current stage may not support Linux or other OSes such as Windows and Solaris. So a hybrid approach of deploying VNFs in virtual machines and containers can be employed. To make it possible, there may need to have a specialized controller to handle VMs and containers and message passing mechanism between both. To manage and orchestrate VM and containers combination of two different virtual infrastructure managers (VIMs) can be used at MANO layer. For example, OpenStack for VMs and Kubernetes for containers. Also, VNF vendors will need to supply and support both types of VNF deployments in target NFV infrastructure.
We observed – there are a significant amount of advantages of using container-based VNFs rather than hypervisor driven. But if we look at the current stage of NFV progress in NFV technology innovation was not much faster which were anticipated in 2012 due to lack of common guidelines model. But now, 5G networks are started to deploy and tested in some of the cities by service providers with the help of leading vendors. Some of the leading vendors have worked on PoCs of using containers in NFV environment. The development will be leading to target the more innovative features which 5G is bringing such as network slicing, Mobile Edge Computing (MEC) and cRAN (Cloud Radio Access Networks). These new 5G features will surely require dynamism and benefits offered by containers for highly automated deployment of services towards every edge of the 5G network. We can expect all service provider and network solutions vendors aware of container benefits to be utilized to gain high throughput.
Latest posts by Sagar Nangare (see all)
- Powering Edge With Kubernetes: A Primer - August 14, 2019
- Simplify Storage for Kubernetes with Rook and Ceph - August 2, 2019
- Distributed Application Architecture for Edge-Based Service Delivery - April 19, 2019