Benchmarking Cloud-Native Infrastructure Readiness and Performance
Cloud capabilities are well known, but “cloud-native” architectures remain a developing area for most operators prepping to support 5G Standalone (5G SA) and 5G-Advanced deployments.
Historically, operator clouds comprised multiple vertically integrated stacks of applications, cloud software, and hardware provided by single vendors. This was operationally convenient because vendors essentially managed the entire stack’s performance as a black box.
Cloud-native architectures are changing this model by disaggregating hardware from software-based network functions and containerized applications, letting operators mix and match best-of-breed vendors.
As a result, many operators have migrated to horizontal, best-of-breed multi-vendor clouds that disaggregate cloud infrastructure from cloud applications. For example, they’ll use commercial Dell server hardware with a Red Hat OpenShift common cloud as the infrastructure, with Nokia applications running on top.
This approach provides hardware economies of scale and more flexibility — but with that flexibility comes complexity.
Operators now face the challenge of migrating from vendor-managed black box operations to taking responsibility for disaggregated, multi-vendor cloud infrastructure and applications. In doing so, they effectively become their own systems integrator, with new responsibilities.
This blog discusses the challenges of managing cloud-native infrastructures and the importance of thorough benchmark testing for their success.
A new era of cloud-native applications
The new era of 5G Standalone introduces cloud-native applications that leverage containerization, microservices, automatic healing and scaling, and automation to enable scalability, resilience, and rapid service delivery. These cloud-native network functions (CNFs) are a collection of microservices that reside in containers within pods that are orchestrated by Kubernetes.
The 5G core team deploying CNFs (e.g., Access and Mobility Management Function [AMF], Network Repository Function [NRF], Policy Control Function [PCF]) is typically different from the infrastructure team. The CNF team creates the CNFs and expects them to run properly on the cloud-native infrastructure.
The cloud-native infrastructure consists of Kubernetes orchestration software (e.g., Red Hat OpenShift) and general-purpose servers (e.g., Dell). The infrastructure team is responsible for building, managing, and maintaining this cloud-native infrastructure.
A simple way to visualize this division of responsibilities is to think of vehicles (e.g., CNFs) traveling on a highway system (the cloud-native infrastructure), as shown in the graphic.
Cloud-native infrastructure teams build data centers under the control of Kubernetes. Racks of general-purpose servers run applications directly in containers within pods, orchestrated by the Kubernetes control plane. Every cluster contains one or more Kubernetes control plane nodes that orchestrate workload healing, deployment, and scaling — such as switching to different storage as needed. Each worker node can support hundreds of microservices spanning many 5G CNF workloads.
The servers provide the CPU, memory, and storage to handle requests in a distributed manner from the Kubernetes control plane.
The goal of an infrastructure team is to validate that the Kubernetes infrastructure can handle the resources that any CNF needs, no matter what workloads are required to support it.
This shift can be challenging for operators because, until now, vendors managed the infrastructure. Operators are not only taking on a new responsibility, but that responsibility is complicated by increasing workloads and an unfamiliar, disaggregated, multi-vendor architecture. The infrastructure team is now accountable for resolving issues when they arise.
How to validate cloud-native infrastructure
Infrastructure teams must conduct lab validation to ensure CNFs have the resources they need to work as expected. While containerized environments promise scalable, elastic allocation of compute, memory, and storage, teams often encounter contention and inefficiencies that limit performance. Validating whether infrastructure can dynamically scale, recover, and migrate workloads across open, multi-vendor environments adds further complexity.
CNFs need CPU, memory, storage, and networking from the infrastructure. Without benchmarking to establish baselines for throughput, latency, and capacity, CNFs risk underperforming in production, causing outages, wasted investment, and slower time-to-market. Infrastructure validations should include:
- CPU benchmarking: Measures processing power and efficiency under varying workloads, such as CPU utilization and Kubernetes key performance indicators (KPIs) . Do CNFs get enough CPU capacity and consistent compute performance for all the apps being deployed, considering CPU overhead?
- Memory benchmarking: Validates memory throughput, latency, and allocation efficiency to support high session density and low-latency functions. Is there enough memory? Is it efficient enough to provide low latency?
- Storage benchmarking: Assesses input/output (I/O) performance, read/write speeds, and persistence reliability to meet demanding 5G data workloads. Are there enough storage servers for all the workloads?
- Networking benchmarking: Evaluates throughput, latency, jitter, and packet loss to guarantee predictable performance for data plane and control plane traffic. What’s the network performance between two pods in different nodes? What’s the latency between worker and storage node?
An important additional factor in validating the infrastructure is cadence release management. Benchmarking is not a one-off activity. Each vendor has its own release cadence, new vendors may be added, and new interfaces may be deployed. As the infrastructure changes continuously, each release and upgrade needs to be benchmarked. This requires an automated testing solution.
Testing has never been more critical, driven by rapid technology evolution and major organizational change. New teams need to build expertise in cloud applications and cloud infrastructure management and know how to test them before they enter the production network.
Keysight, a trusted cloud-native validation partner
Keysight helps operator teams build, test, and benchmark cloud-native infrastructure, putting them in control of managing their infrastructure competently and speedily.
Keysight’s Landslide cloud-native testing is the first solution purpose-built to test and benchmark the design, deployment, and management of cloud-native 5G SA network environments.
Cloud-native infrastructure readiness establishes performance and resiliency baselines. The solution validates whether clusters can support anticipated CNF workloads and identifies resource bottlenecks before production. Operators can run configurable workload scenarios to test behavior under stress, confirm Kubernetes recovery mechanisms, and compare changes with A/B or shadow testing. The solution provides comprehensive performance metrics and real-time visualization to simplify analysis and accelerate decision-making.
Keysight Landslide enables operators to:
- Accelerate 5G SA and 5G-Advanced adoption by validating infrastructure readiness before CNF deployment.
- Reduce risk of degraded service quality and wasted investment by verifying usable capacity under load.
- Optimize operational efficiency by identifying over- and under-utilized resources.
- Enable data-driven planning for scaling, upgrades, and cloud provider choices.
- Create benchmarks across CPU, memory, storage, and networking resources.
Cloud-native infrastructure testing further expands Keysight Landslide’s capabilities, which include testing and tracking of cloud-native CNF performance and its impact on 5G services, to help service providers accelerate roll-out of cloud-native 5G SA networks.