While there's been a lot of talk in the industry in regard to moving from virtual network functions (VNFs) to container network functions (CNFs), Red Hat's Susan James said there are a few key considerations.
James, senior director for telecommunications strategy at Red Hat, said one of those points to ponder on the journey to containerization is "day-two operations." The virtualization journey of network functions virtualization (NFV) included lengthy proof-of-concept trials and the continued on-boarding of VNFs, but for the most part they didn't include day two operations.
"When they (service providers) start moving down the path of containerization, they can't afford not to have considered day two operations and automation," James said. "The network side of things needed some work. When you look at containerized network functions, as opposed to just containerized applications, there are a lot of requirements around the type of interfaces and being able to have multiple insights into those functions.
"And those have been released this year with things like multi-interface software coming into the portfolio. Multi-interface software can be used as part of OpenShift. If you lose the application, you can go in on a different interface, and recover it through an operation maintenance interface."
While there has been a lot of progress this year just since Mobile World Congress in February, James expects VNFs and CNFs to co-exist for sometime going forward until a service provider reaches a "cap and growth scenario." With the continued need for more network capacity, service providers aren't going to pull out their existing network technologies to make the hard switch to containers.
"I would say we're in the early days of those containers or CNFs," James said. "A lot of the VNFs that are deployed today are not cloud-native, and it doesn’t make sense to change to a containerized application unless it's truly cloud-native because otherwise you have to build up so much additional functionality in the platform to support those applications.
"Even the VNF companies understand what it means to be truly cloud native, and there's a difference between being able to run on the cloud and being cloud-native."
As an example, James said an application can run in the cloud, but if there's a problem in that cloud it doesn’t have the ability to relocate itself and continue to run.
"So that's not truly cloud-native," she said. "Those applications need to be resilient to failures of their underlying infrastructures."
While there has been a lot of industry talk about cloud-native, Kubernetes and containers, James said containers will only work if service providers create scenarios where they can recover and relocate themselves to other resources and capabilities in the cloud.
James said the challenge with NFV was that everyone was in a rush to implement it once the applications were on-boarded to the infrastructures. The industry didn't consider how to manage NFV from an operations perspective. A lot of the early customizations were done on OpenStack to fill gaps in the platform functionality. Over the past two or three years, most, or all, of that capability in now on the platform or application.
James said the use of VNFs led to a loss of scale for the industry because they were running on dedicated infrastructure for just that particular application.
"It doesn't really make sense to follow that path when you're actually moving to containerization," James said. "You really do want to be able to share the resources across all of the workloads so that we get the most efficient cloud we can. And that you actually have, again, the ability to have more resilience and you get shared capacity across those workloads. You get that when you truly have cloud-native applications and then you can have capacity to balance across those workloads.
"Moving to containers doesn't mean that you are cloud-native. It's the philosophies of how you solve certain problems of scaling and of resilience. As you go to containerization, you better make sure you are cloud-native. Otherwise there's no value in making that technology shift. A technology shift has to count with some economic or functional benefit. Moving to containers just for the sake of moving to containers brings no benefit."