How Netcracker is Working Within the ONAP Community on its Journey to Become Cloud-Native

Delivering software applications through the cloud has become the new norm, and making applications cloud-native is the new goal. The term cloud-native is used a lot in the context of transitioning from virtual network functions (VNFs) to cloud-native network functions (CNFs). This movement is driven by the potential of delivering applications with real agility, on-demand scaling, resiliency, deployment flexibility and the independent development of different application components.

But what does this mean for the orchestration environment which also must be cloud-native?

Orchestration systems, just like VNFs, are software by default. But for them to be cloud-native requires a new way of designing and building its software applications.  

In the pre-cloud era, software applications consisted of a single monolithic code package. This type of architecture still creates numerous operational, management and maintenance challenges today because the application needs to be deployed, scaled and upgraded as a single entity. Taking advantage of cloud characteristics requires the application to be broken down into modular groups or microservices.

There are two critical factors that must be considered when breaking down applications into individual modules or microservices: the microservice boundary/size and its alignment with business capabilities.

1. Microservice Boundary/Size

One of the most challenging aspects of the decomposition is the degree of granularity. On one extreme, breaking down the app into hundreds of modules can ease upgrades but also lead to degradations in operational performance due to the increased overhead in inter-communication between different modules. The other end of the spectrum may consist of deploying the whole monolithic application as one module inside a container or virtual machine and calling it a microservice. A balance is clearly needed between granularity, performance and ease of operation.

2. Alignment With Business Drivers

The grouping of functionalities into modules must also be based on business drivers, such as the testability of modules, the independent development of modules or how the modules can be packaged together and offered in a marketplace as a standalone building block for similar solutions.

How Does This Relate to ONAP?

The Open Networking Automation Platform (ONAP), like any other open source community, is organized as a group of projects. This structure often limits ONAP from adapting essential architectural changes, as different projects follow different guidelines for decomposing functionality. While the structure may have short-term benefits for enhancing the project-specific cloud-native characteristics, it has several limitations.

• Extensibility: It is difficult to introduce new features or support new use cases in ONAP, as many projects are impacted simultaneously.
• Integration complexity: The integration of different modules is difficult, as interdependencies are loosely defined or changed based on ad-hoc needs.
• Interchangeability: ONAP modules cannot be easily replaced with commercial alternatives due to the tight dependency between different modules. Service providers will also find it difficult to use only specific modules in ONAP based on functional gaps they see in their operational environment.

Working within the ONAP community to transform ONAP into a cloud-native platform is one of Netcracker’s main focus areas. Below is a brief summary of Netcracker’s architectural contributions to date.

• Introduction of microservices design best practices, such as domain-driven design (DDD) and TM Forum’s IG1118.
  • Domain-driven design is a popular microservices design methodology which focuses on business domains rather than an application’s software building blocks. Netcracker proposes DDD as a method to align different ONAP projects to business capabilities required by service providers.
  • TM Forum’s IG1118 describes a component-system pattern for representing management systems as an assembly of components. The basic building block is a component with well-defined interfaces, such as operation, application, security, infrastructure, etc. Netcracker proposes component-system pattern as a means for designing modular, repeatable ONAP microservices.
• Promotion of functional decomposition in a top-down manner, leveraging approaches followed in the industry, such as TM Forum’s TAM and eTOM. TM Forum’s TAM gives an exemplary model for decomposing the operational functions on multiple levels. This is similar to how macro-functionality is decomposed into microservices. The advantage of referring to TAM is that it covers the telecom operational domain with functions, which are more or less similar in nature across service providers.
• Consolidation/alignment of different proposals for modularity and functional decomposition, showing examples of functional decomposition with operational functions as the key focus.

All of these architectural contributions share the goal of enhancing ONAP’s modularity and helping ONAP to become a cloud-native platform, enabling service providers to benefit from the real value of the cloud.