There's No Easy Evolution Path from VNF to CNF
When thinking about how Virtual Networks Functions (VNFs) can be adapted to become Cloud Native Network Functions (CNFs), the Frog Prince story comes to mind. But the magical transformation of a frog turning into a prince only happens in fairy tales. And in the real world, successfully turning a VNF with legacy codebase into a true CNF is about as likely as a princess breaking a wicked spell with a kiss. At least, it would take some magic to complete the transformation.
As explained in our new white paper on Cloud Native Network Functions, there’s a strong temptation to reposition virtualized network functions as cloud native, given the clear advantages that cloud native has in delivering CAPEX and OPEX savings and accelerating the pace of innovation for CSPs. But vendor claims of cloud native should be treated with caution.
To create a genuine CNF, developers really need to start from scratch and not with a legacy codebase.
In general, it is extremely difficult to refactor monolithic, stateful, legacy network function software to embody the key architectural aspects of cloud native that are essential to the delivery of cloud native benefits. There are three main reasons why this is so difficult, which are related to three cloud native features: stateless processing, microservices and declarative configuration.
1. State is inextricably tied into the code.
Stateless processing is the most important feature in cloud native architecture. But in traditional application architectures, all state is stored locally and elements of state are accessed or updated by individual instructions throughout the body of the code. Unpicking this so as to read all relevant long-lived state from a separate store and to update that store at the relevant points in the processing of any given event is hugely labor-intensive, and in most cases represents an almost complete re-write of the code.
2. Monolithic applications are hard to de-compose.
While legacy codebases typically show a high degree of modularity in the form of function calls and subroutines, these modules rarely offer natural boundaries for decomposition to loosely coupled microservices. Often this is because of mutual dependencies on shared data structures. A microservices architecture requires such dependencies to be eliminated, and this usually demands a complete re-think of the application architecture.
3. Procedural configuration management is very different to declarative.
The key issue here is that, with procedural configuration management, consistency checking is applied in a stepwise manner, with each step dependent on what has gone before. By contrast, declarative configuration requires holistic consistency checking of the entire configuration before any change is applied. These two approaches are fundamentally different, and it requires a great deal of effort to change a complex application from one to the other.
Any claim that a network function is cloud native when it is quite obviously derived from a legacy NF codebase should therefore be treated with great caution.
For a thorough understanding of cloud native design principles, please download the white paper. The paper provides a list of criteria that CSPs can use to test cloud native claims so that they won’t have to kiss too many VNF frogs before finding their CNF prince.