Applying Cloud native principles to all layers of network infrastructure, applications and services as put forth from the NGMN:
- Decoupled infrastructure and application lifecycles over vertical monoliths
- ‘API first’ over manual provisioning of network resources
- Declarative and intent-based automation over imperative workflows
- GitOps** principles over traditional network operations practices
- Unified Kubernetes (or the like) resource consumption patterns over domain-specific resource controllers
- Unified Kubernetes (or the like) closed-loop reconciliation patterns over vendor-specific element management practices
- Interoperability by well-defined certification processes over vendor-specific optimisation.
Reference
- https://www.ngmn.org/wp-content/uploads/NGMN_Cloud_Native_Manifesto.pdf
- https://www.ngmn.org/highlight/ngmn-publishes-cloud-native-manifesto.html
"Practical challenges and pain points on this journey, which hinder progress towards the target expressed in the NGMN Cloud Native Manifesto, have been identified and are being felt."
"For the new model to work, vendors and CSPs must provide mutual SLAs: the CSP must guarantee a certain level of quality at the platform layer, while CNF vendors need to guarantee that the application will perform on the platform with SLAs that meet defined KPIs.Challenges in Cloud Native Telco Transformation Today (source: Accelerating Cloud Native in Telco whitepaper *)"
"We also use the term cloud-native infrastructure in broader context for the infrastructure that abstracts Infrastructure-as-a-Service (IaaS) layer, that has Kubernetes in its core with useful API abstractions on top of it as as well as auxiliary systems all as a framework that makes managing applications easier and promotes doing so in a cloud native way. This is important because you are free to use Kubernetes (and other "cloud native" technologies) in a very uncloud-native way. Our longer-term goal, underlying this whitepaper, is for all layers of the environment to encompass the cloud native principles from infrastructure allocation + management, through the application workloads"
From the whitepaper Accelerating Cloud Native in Telco
Figure 2-1: Example layers for cloud native infrastructurefrom "Cloud Native Infrastructure" by Justin Garrison and Kris Nova (ISBN: 9781491984307)
Pre-Validation. Historically, Network Functions have been developed and pre-integrated with well-defined infrastructure, which was known in advance. That pre-validation was done by a Network Function vendor and the system was delivered as a validated/certified bundle together with performance and stability guarantees. In the cloud native world, there are too many permutations which makes it impractical to follow the traditional certification path. However, Cloud Native Network Function (CNF) vendors are still sticking to it by picking a small number of opinionated infrastructure flavors (different from vendor to vendor!) to pre-validate against, making any infrastructure outside this selection too complicated, too costly, and too slow to deliver for CSPs. This creates problems in the adoption of those CNFs as CSPs generally prefer to each have a unified cloud native infrastructure layer, which they are free to choose and often it can differ from the opinionated infrastructure already validated by the CNF vendors.
Adaptations. CNFs are typically delivered as a collection of artifacts such as YAML, Helm charts, and container images. These artifacts are intended for deployment in CSP’s cloud native environment. However, every CSP has somewhat different rules, policies, security standards, API versions, and approaches to lifecycle operations (e.g. use of NFVO capabilities, GitOps pipelines, etc.). Due to that, it is often not possible to deploy the CNF directly in any environment in a consistently replicable way, but it requires some adaptations. That shall normally not pose a problem, as most of these adaptations can be performed in deployment configuration often in YAML files, by either CSP’s DevOps team or the vendor’s delivery personnel. Nonetheless, we often encounter situations where CSPs are not allowed to perform such adaptations (under threat of losing support if doing otherwise) since these artifacts are part of the release and could be adapted only in new release delivery or through the custom change request. As a result, this situation often leads to a frustrating cycle of discussions and significantly hampers the CNF onboarding process.
...
Fragmentation of all layers and a need for change in the deployment model
This is a list of modified challenges based on a Sylva article. This Cloud Native Telecom program can be part of solving these solutions.
...
source: https://the-mobile-network.com/2022/11/why-the-eu-big-five-are-launching-sylva/
Runtime interoperability of CNF platforms and CNFs
- CNF-s need to have some assumptions about their environment due to their resource needs (e.g.: multiple pod networks, network and compute latency). The assumptions have to be the same for all CNF platforms.
- To achieve interoperability the CNF platforms need to fulfill these assumptions.
- To ensure that the assumptions of the CNFs are correct and that the platforms fullfill the assumptions both the CNF-s and the platforms need to be tested
- There is no point in doing interoperability conformance testing of only one side, as the conformance will not have a target