Tom Nolle, a well respected consultant in the world of telecom and one of my favorite bloggers, recently posted an article about "Navigating the Road to Cloud-Native Network Functions"
This is my first attempt to paraphrase his words, trying to 'tease out' additional understanding by introducing a slightly different perspective.
===
The NFV community is a loose consortium of vendors and individuals with an established interest in the form of deployed network software products. The continuous evolution in thinking around software architectural engineering principles, the emergence of new software solutions, and changing requirements in both the way these systems get used and in the objectives against which their success is measured, are all forces that drive change.
As humans, we have a tendency to resist change. If it gets colder, we temporarily put on a coat to get warm. If it rains, we may choose a water resistant one to avoid getting wet. Some rare individuals might decide to move to a different country with better weather conditions (on average). And it would take a special kind of - what most other humans would call - "insanity" to even consider more extreme solutions, like inventing a machine or process to eliminate the rain clouds altogether - i.e. bringing about selective, localized climate change.
Back to our Cloud-Native Network Functions - a.k.a. moving to a different planet, from the perspective of the NFV community. A big, unlikely change. Much more difficult than - say - changing terminology, and redefining some of the concepts used when talking about network software.
Take "Virtual Machines" (VMs) for example. They represent a software version of a traditional hardware system, preserving the structure of its components and their suppliers - the eco-system. VMs increase the addressable market for the eco-system partners, as their carefully engineered solution can now easily be replicated and sold to an infinite number of customers, with minimal incremental cost or time. The physical constraints of hardware components are eliminated - or rather, someone else's problem, to be provided as generic resources sometimes called "cloud infrastructure".
The OS and other software components contained within the VM are "overhead", from the perspective of someone with the capability to take individual application processes out of those VMs, and host them directly on the underlying infrastructure. This is an eco-system layer that can be eliminated, to reduce cost (objective) and to achieve more efficient resource utilization (objective) - decomposing the VM into the sub-components that deliver its actual value ("microservices") provides increased flexibility and choice, allowing for more fine-grained optimizations.
The same OS and other software components contained within that VM form a familiar operating environment, for the organization running and maintaining those applications. There are well defined processes for upgrading to newer versions, adding more instances ("scaling out"), etc. When there are problems, a ticket is opened with the support organization of the VM vendor, who might pass it on to the OS vendor, etc. In summary, the operational processes for VMs are well understood and - considered - effective (objective). There are people assigned to these tasks, as part of a job that allows them to make money and provide for their families (objective).
Now consider the transition from VMs to CNNFs. What would drive this transformation, which eco-system actors would benefit/be in favor, and who would be opposed?
Decomposing a VM into CNNFs is like taking a hammer to a mirror on a wall, disposing the frame and then scattering the pieces in various rooms around the house. The pieces are still physically there, but they no longer perform the function they were originally designed to perform, at least not in an effective and aesthetically pleasing way. And you might get hurt in the process - so why would you do this?
Vendor selection and component selection are both eco-system design decisions. The 'optimal' choice depends on many factors, things are inter-dependent and circumstances evolve over time. Each actor has their own definition of "optimal", relative to their own objectives. For a given organization and a given platform solution with hardware and software components, it may very well be the right time to move towards a more cloud-native universe. But it depends - what are the objectives, and how do they align with yours?
