Skip to main content

Containers and the evolving 5G cloud-native journey

containers

Since 5G SA (standalone) is still in its early evolution and deployment, why invest and risk implementing a cloud-native core today? In my last blog post, I made the argument that there is greater risk in delaying — having a cloud-native core brings so many advantages to 5G (non standalone) NSA and 4G networks, chief among them, agility and flexibility. In this blog I want to touch on how to keep costs down as you move towards 5G SA and why a performant 4G core is a key investment to ensure a stable footing for the future.

So how do I implement a cloud-native core and avoid costs spiraling out of control? Containers are getting a lot of industry buzz these days. Are they essential? Are they the most cost-effective route to 5G SA? What role do existing virtual machine (VM), OpenStack solutions play?

This is somewhat complex, but I’ll try my best to sort some of it out in this post. First, let’s look at where we’re coming from:

  1. In the beginning, core virtualization was nothing more than moving software to run on a server or vendor-specific hardware
  2. The first step on the journey of cloud-native then began: we provided software modularity of the vertically integrated core network function software by separating the business logic from the storing of the subscriber state to create state-efficient network functions
  3. We created the ability to use network function virtualization infrastructure (NFVI) environments with the use of VMs
  4. Basic cloud operations came next, which included software development and operations (DevOps) techniques and methodologies to improve the reliability and speed of delivery

Moving forward, we will continue on this cloud-native journey:

  1. We will have continued software disaggregation with the application of micro-services as appropriate to the network function
  2. We will see continued infrastructure agnosticism with the expansion of physical network functions (PNF) and virtual network functions (VNF) that can be deployed on VMs or containers 
  3. In the not-too-distant future, the core will become zero-touch in terms of application and solution lifecycle management with real-time elasticity and adaptation to traffic changes
  4. The ultimate endgame is a core network that can self-care with predictive analysis and autonomous configuration of business logic and resource allocation

As we move through the different stages, time-to-market is reduced, and things get more efficient, which drives lower total cost of ownership (TCO).

As discussed above, as part of our evolving cloud-native journey, we are looking to run network functions in containerized cloud environments or as a container within a VM. In the first case, cloud-native network functions (CNFs) should be implemented as a set of optimally disaggregated microservices without compromising performance. There are some benefits to using containerized environments over previous VM environments, which include:

  • Resource management and operations are optimized within a containerized environment, whereas in VMs it is an integral part of the VNF
  • In a containerized environment, scalable units are at the microservice level, which optimizes cloud resource usage and simplifies upgrades and updates; in contrast to a VM environment where a scalable unit is an entire VM

Of course, efficiency is in the eye of the beholder. Containers are more efficient as described above. However, a communication service provider (CSP) may have been running a VM or OpenStack environment for many years and operational teams may be more comfortable continuing to run a cloud-native core in this well-known environment. This is also a kind of efficiency. However, CSPs are looking to move to containers, but there may also be near-term comfort with deploying CNFs in a well-known VM-based environment.

Our approach to the question of containers and whether to implement them is “it will probably happen over time”. Certainly containers seem to be the industry direction, and should provide greater efficiencies, which translates into improved performance and lower costs.

Of course, CSPs will have to evolve skill sets and capabilities in their operations teams to take advantage of the operational advantage’s containers should provide, such as:

  • Simplified and frequent deployments with DevOps to allow new service introduction without impact to existing ones
  • Development at whatever pace suits the CSP, with no compromises on features or capabilities on any deployment option
  • Improved resilience through fault isolation (i.e., an issue in a non-critical software component cannot affect the whole system)
  • Increased testability due to independent and well-defined interfaces of each software component

This is why we have designed our cloud-native core to be completely flexible on this front. We support VMware, OpenStack and Kubernetes implementations. For Kubernetes, we take full advantage of its integrated features and capabilities. Scaling is a key feature where we can use protocol data unit (PDU) sessions as well as memory and processing metrics. We also integrate a multitude of open source components. If you want to fully containerize, you can do it retroactively all the way back to 2G.

The principal goal of a cloud-native core, as we’ve discussed, is to give CSPs more flexibility and agility, as well as to keep their costs down. The specifications for 5G SA make it clear that cloud-native is their future, and strong 5G services will be more easily built on high performing, cloud-native 4G implementations. In our view, it is less risky to start that migration now with existing and legacy network services where the unknowns are fewer, and to begin building skills and development practices on a longer time scale. On containers, it is clear they are also likely the future, but the timing will depend on a customer’s cloud transformation strategy.

Want to know more?

Take a look at our 5G cloud-native core infographic to see this is an investment in the future.

Visit our Cloud Packet Core solutions page to see how our cloud-native design helps you to profitably and cost-effectively evolve.

Share your thoughts on this topic by joining the Twitter discussion with @nokia or @nokianetworks using #5G #cloud #CloudNative #CSP

Rob McManus

About Rob McManus

Rob is a senior product marketing managers of Nokia’s Cloud Packet Core. If you need convincing about the exciting possibilities of a cloud-native packet core – talk to him or keep an eye out at key industry forums where he’s a regular speaker.

Tweet us at @nokianetworks

Article tags