Cloud Native
AI-Era Cloud Network Transformation: A Reference Architecture and Implementation Roadmap
By Shazia Hasnie, PhD
Introduction:
The physical network infrastructure that underpins cloud computing was designed for an era that no longer exists. Distributed training across hundreds of thousands of GPUs, real-time inference at the edge, and autonomous agent coordination impose requirements that traditional cloud network designs were never intended to meet. The networks that served the cloud era were architected for north-south traffic, best-effort delivery, and human-scale applications. None of these assumptions hold for AI.
This article presents a framework for transforming cloud network infrastructure for the AI era. It is organized around two components: a four-pillar reference architecture that defines what must be built, and a five-phase implementation roadmap that defines how to execute the transformation. Together, they provide infrastructure transformation leaders with a complete program for preparing their organizations’ physical network infrastructure for the age of AI.
The Four-Pillar Reference Architecture:
The physical network infrastructure for AI-era cloud computing is organized around four interdependent pillars. Each pillar groups related layers of the infrastructure stack. Each depends on the pillars that precede it and enables the pillars that follow.
Figure 1: The Four Pillars of AI-Era Cloud Network Infrastructure — a complete reference architecture for physical network transformation.
PILLAR 1: PHYSICAL FOUNDATION
The physical foundation is the literal infrastructure on which all higher-layer network services depend. Optical transport determines the bandwidth, latency, and reliability of every interconnection between data centers, regions, and compute clusters. Physical plant and cabling provide the fiber, connectors, and cable management that make connectivity possible. Power and cooling provide the electrical and thermal infrastructure that keeps everything running.
Optical Transport. Optical link engineering for AI workloads requires a fundamental shift from traditional practice. Traditional optical link engineering treats traffic surges as anomalies and provisions for average utilization. AI workloads generate synchronized, high-bandwidth bursts—checkpointing incast can saturate multiple optical links for minutes at a time—that demand link budgets engineered for peak synchronized demand. The cost of insufficient capacity is not degraded optical performance; it is stalled training runs.
The optical technology roadmap is being reshaped by AI requirements. Co-packaged optics (CPO) integrate the optical engine directly with the switch ASIC, reducing power consumption by 30-50% while increasing port density. Silicon photonics leverage semiconductor manufacturing to produce optical components at scale. 800G and 1.6T per wavelength will be required as GPU bandwidth scales. Linear drive optics remove the digital signal processing from the optical transceiver, reducing power and latency. Breakout optics enable multi-planar topologies where each GPU connects to multiple parallel fabrics. Organizations must ensure that today’s optical investments are forward-compatible with these technologies.
Physical Plant and Cabling. Deployment precision at the physical layer determines whether the architectures designed at higher layers function as intended. Rail-optimized topologies depend on perfect physical cabling—a single miscabled port breaks the single-hop guarantee. Automated cabling verification, where the management interface validates each connection against the reference design, has reduced deployment time by up to 90% for early adopters. Continuous monitoring must detect cabling degradation before it causes performance issues.
Power and Cooling. AI network hardware consumes significantly more power than traditional cloud hardware. A rack of switches populated with 800G pluggable optics can consume over 10 kilowatts. CPO engines may require direct-to-chip liquid cooling. The transition to liquid cooling has implications that extend beyond the network—chilled water systems, heat rejection, building structural load—and retrofitting liquid cooling into a data center designed for air cooling is significantly more expensive than incorporating it into new construction.
PILLAR 2: NETWORK SYSTEMS
Network systems translate the physical foundation into functional network services. Modern data centers operate multiple physical networks—front-end, back-end, storage—each optimized for a specific traffic class. AI training demands a dedicated high-bandwidth, low-latency fabric for GPU-to-GPU communication that must interoperate with existing networks through well-defined interconnection points.
Network Fabrics. AI workloads generate east-west traffic that behaves differently from anything traditional cloud networks were designed to handle. It is dominated by a small number of high-bandwidth elephant flows—sustained, predictable data streams between GPU pairs—that produce synchronized bursts at predictable intervals. Worst-case path latency determines the completion time for collective communication operations, making the performance of the slowest path more important than average performance.
The industry has developed two distinct architectural paths to meet these requirements. For scale-up networks within a single rack or GPU pod, where distances are measured in meters and the cost of a stall is immediate, lossless transport via Priority-Based Flow Control (PFC) and Explicit Congestion Notification (ECN) remains the dominant approach. For scale-out networks connecting GPU clusters across data center halls or buildings, the industry is moving toward efficient utilization with low tail latency through fast recovery rather than absolute loss prevention. The Ultra Ethernet Consortium’s Ultra Ethernet Transport (UET) specification leads this effort, treating packet loss as a recoverable event rather than a failure.
The choice between paths is governed by three criteria: scale of deployment (≤256 GPUs favors lossless; ≥512 GPUs favors low-loss), workload characteristics (tightly coupled training benefits from lossless; loosely coupled inference tolerates low-loss), and organizational maturity (deep PFC expertise extends lossless viability to larger scales).
Four fabric capabilities support both paths. Dynamic load distribution—flowlet switching and packet spray—replaces static Equal Cost Multi-Path (ECMP) with congestion-aware path selection. In-band network telemetry (INT) provides the microsecond-granularity congestion visibility that makes intelligent load distribution possible. Rail-optimized topologies provide single-hop GPU-to-GPU connectivity for the most latency-sensitive collective operations. Advanced transport protocols, add selective retransmission via SACK and NACK that serves both scale-up and scale-out deployments.
Hardware Platforms and Qualification. Hardware must be qualified under AI workload conditions, not standard benchmarks. A switch that performs well under steady-state testing may exhibit unacceptable packet loss under synchronized burst patterns. The qualification process must answer a specific question: will this hardware maintain performance under the traffic patterns that AI workloads generate? Qualification is continuous—a firmware update, a new optics module, or a configuration change can alter behavior and must be validated before reaching production. The endpoint NIC plays a critical role, handling RDMA at line rate, packet-spray reordering, and selective retransmission. NIC qualification must be part of the same AI workload simulation process as switches and optics.
Network Operating Systems. The NOS must support PFC, INT, dynamic load distribution, and automation APIs. Interoperability is an architectural requirement in inherently multi-vendor AI infrastructure. Organizations should prioritize platforms that adhere to open standards—UET specifications, IETF YANG data models, OpenConfig—over proprietary extensions that create long-term supply chain constraints.
Edge and Regional Interconnect. AI inference increasingly occurs at the edge, requiring low-latency connectivity to cloud reasoning agents. Traffic engineering via Segment Routing over MPLS (SR-MPLS) and SR over IPv6 (SRv6) enables explicit path specification for latency-sensitive flows. Model distribution to edge endpoints requires versioned, efficient distribution protocols. Regional interconnect must be treated as a production input, not a shared utility—it is part of the AI supercomputer’s backplane.
PILLAR 3: OPERATIONAL INTELLIGENCE
Operational intelligence provides the control systems that make the network operable at scale. The AI-ready network cannot be managed through manual processes—a single AI cluster may contain thousands of switches requiring consistent configuration, where a single misconfigured buffer can stall thousands of GPUs.
Automation and Orchestration. The architectural response is declarative intent-based automation. The operator declares the desired network state using IETF YANG data models, and the automation framework translates this into device-level configuration via NETCONF, RESTCONF, and gNMI. Zero-touch provisioning enables switches to self-configure from the moment of installation. Configuration-as-code ensures every device conforms to architectural standards, with drift detected and corrected automatically. Network changes move through CI/CD pipelines that validate against policy and test under AI workload conditions before production deployment.
Telemetry and Monitoring. INT captures per-packet, per-path metrics at microsecond granularity. Streaming telemetry replaces polled monitoring with continuous, event-driven data push. The telemetry platform must ingest, store, and analyze millions of data points per second, enabling cross-layer correlation—tracing a GPU-level stall back through the fabric to the specific optical port and wavelength where the loss occurred. Predictive models detect performance degradation before it causes packet loss, shifting operations from reactive to proactive.
Testing and Validation. A dedicated testing environment must replicate production AI workload patterns—synchronized bursts, collective communication operations, checkpointing incast. Fault injection and chaos engineering validate network behavior under failure conditions. A digital twin of the production network, continuously synchronized, within a bounded delay, with real-time telemetry, enables what-if analysis for topology changes, capacity additions, and configuration updates before production deployment.
Security Architecture. Distributed AI dissolves the traditional network perimeter. The architectural response is in-fabric security: microsegmentation at the switch level validates every flow at the point of ingress, policy is bound to workload identity rather than network location, and the enforcement architecture relies on IEEE 802.1X, MACsec, and IPsec. Policy-as-code manages security rules through the same CI/CD pipelines as network configuration. The immutable audit trail serves double duty as both the security record and the compliance record.
PILLAR 4: STRATEGIC RESILIENCE
Strategic resilience ensures the network survives disruptions, scales with demand, and sustains itself over the long term.
Capacity Planning. Traditional capacity planning, based on historical averages and steady-state utilization, systematically underprovisions for AI. AI traffic is bursty, synchronized, and high-volume by design. Capacity must be provisioned for peak synchronized demand. Simulation-based planning models proposed network designs under projected AI workloads, identifying bottlenecks in the design phase before hardware is committed.
Disaster Recovery. AI training runs lasting weeks or months cannot be restarted from scratch. The network must support checkpointing at AI scale, with Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) defined per workload. The optical backbone must provide physically diverse paths with automatic protection switching. Failover architectures—active-active or active-passive—must be designed at the network level for inference workloads requiring high availability.
Business Continuity. The network fabric must tolerate WAN partitions without cascading failures, with local control planes capable of independent operation at each site. State reconciliation architecture—based on the shared event log pattern—must preserve causal ordering across partition boundaries. The network must support non-disruptive infrastructure refresh, with redundant paths and hitless failover enabling component replacement without interrupting workloads that run continuously for weeks or months.
The Five-Phase Implementation Roadmap
The migration from legacy to AI-ready network infrastructure is a multi-phase program that must deliver value at each stage while building toward the target architecture. Each phase has defined activities, deliverables, and success criteria. Each phase delivers measurable value before the next begins. Phase durations are calibrated for a Tier-1 cloud services provider; individual organizational timelines may vary based on scale, complexity, and resource availability. The success criteria stated for each phase are drawn from industry benchmarks and practitioner experience with large-scale network transformation programs. They represent targets that are ambitious but achievable for a Tier-1 cloud services provider with dedicated transformation resources and executive sponsorship.
Figure 2: The Five-Phase Implementation Roadmap — A 24–36 Month Transformation Program.
PHASE 1: FOUNDATION (MONTHS 1–6)
The first phase establishes the essential building blocks. Nothing can be automated, optimized, or secured until the network is instrumented and its state is understood.
The starting point is telemetry. Streaming telemetry must be enabled across all network devices in the AI infrastructure path—switches, optics, fabric elements—using gRPC-based protocols and OpenConfig YANG data models. The deliverable is a centralized telemetry platform receiving continuous data streams from every device. The success criterion is 100% telemetry coverage. Without complete visibility, every subsequent phase operates on incomplete information.
With telemetry flowing, a topology knowledge graph must be built—a dynamic map of all devices, links, and interconnections, continuously updated from telemetry data and discovery protocols. The graph must reflect topology changes within seconds, not minutes. Accurate neighbor discovery across all fabric layers is the foundation on which intent-based automation will reason about the network.
Configuration management must be brought under version control. Every device configuration—PFC thresholds, QoS policies, dynamic load distribution parameters—must be stored in version-controlled repositories. Every change must be tracked and attributed. The success criterion is 100% configuration version control with no out-of-band changes permitted. An automation framework that deploys configuration changes cannot operate reliably if changes are also being made through manual processes that bypass the automation pipeline.
Finally, the foundational intent model must be established. This is a structured format for expressing network intent—topology, capacity, QoS policies—in machine-readable YANG-based models. The deliverable is five foundational intents, defined and validated against the existing network state:
- Lossless Transport Intent: “All Remote Direct Memory Access over Converged Ethernet (RoCE) traffic on the AI fabric shall receive PFC priority treatment with zero packet loss under sustained load.”
- Fabric Capacity Intent: “The AI fabric shall maintain a minimum of 30% headroom on all east-west links during peak utilization.”
- Optical Link Diversity Intent: “Every GPU cluster shall have at least two physically diverse optical paths to its checkpoint storage.”
- Configuration Compliance Intent: “All device configurations shall match version-controlled templates. Any deviation shall be detected and flagged within 60 seconds.”
- Telemetry Coverage Intent: “Every device in the AI network path shall stream telemetry data. Any device that stops streaming shall be flagged within 30 seconds.”
These five intents are scoped to be achievable within Phase 1 while covering the most critical dimensions of AI network operations: lossless transport, capacity, resilience, configuration compliance, and observability.
PHASE 2: TRANSLATION (MONTHS 6–12)
The second phase builds the machinery that translates intent into device-level configuration. This is where declarative automation becomes operational.
The centerpiece is the intent compiler—a translation engine that converts YAML or JSON intent specifications into device-level configuration via NETCONF, RESTCONF, and gNMI. The intent compiler is not merely a template engine. It must understand the capabilities and constraints of each target device, select the appropriate protocol for each configuration operation, and handle the transactional semantics that make configuration changes safe. The success criterion is that the five foundational intents from Phase 1 are compiled and deployed without manual intervention.
Before any compiled configuration reaches production, it must be validated in a digital twin—a virtual replica of the AI network, continuously synchronized with production telemetry. The digital twin enables what-if analysis: if this configuration is applied, what happens to fabric utilization, PFC pause events, and flow completion times? The success criterion is 100% of configuration changes validated in the digital twin before production deployment.
Validation checks must be automated. Every intent must pass feasibility validation (can the network support this intent given current capacity?), capability validation (do the target devices support the required features?), and policy validation (does this intent comply with security and operational policies?). The success criterion is zero invalid intents deployed to production.
Multi-domain support must be enabled. The intent compiler must support both data center fabric and optical backbone domains, translating a single intent into coordinated configurations across domains.
PHASE 3: ASSURANCE (MONTHS 12–18)
The third phase closes the loop between intent and reality. The network may be configured correctly at a point in time, but AI workloads cause continuous change—congestion patterns shift, optical performance degrades, buffer utilization fluctuates. Assurance ensures the network remains in its intended state.
Real-time telemetry monitoring must track SLA compliance for all AI network services, updated continuously from streaming telemetry rather than periodically from polled data. Sub-second detection latency for SLA deviations is the success criterion. A RoCE stall that lasts 500 milliseconds must be detected while it is happening, not after the training run has been disrupted.
Drift detection must compare the intended network state against the actual state continuously. Drift can take many forms: a configuration change applied outside the automation pipeline, a performance degradation that violates the intent without changing the configuration, a topology change due to a link failure. The success criterion is 99% detection accuracy for both configuration and performance drift.
The assurance dashboard must provide all stakeholders—network operations, compute operations, capacity planning—with real-time visibility into network state versus intent. Alerting must be integrated with the incident management system so that 100% of SLA breaches generate alerts within one second of detection.
PHASE 4: REMEDIATION (MONTHS 18–24)
The fourth phase enables the network to respond to drift and failures. Detection without response is observation without action. Remediation closes the loop.
Root cause analysis (RCA) must be automated. When drift is detected, the system must correlate telemetry data across layers—optical, fabric, device—to identify the source. A packet loss event at the GPU layer may originate from a congested optical link three hops away. The RCA engine must trace the event across layers. The success criterion is greater than 80% accuracy for common incident types.
At least three remediation types must be implemented and validated in the digital twin before production enablement: rollback to the last known good configuration, traffic rerouting around congested or failed links, and dynamic QoS adjustment.
A policy engine must govern which remediation actions are fully automated, which require human approval, and which are prohibited. The policy framework must be machine-readable, version-controlled, and enforced at the automation layer. The success criterion is 100% of automated remediation actions comply with defined policies.
Supervised remediation must enable a human-in-the-loop approval workflow for actions that exceed the automated threshold. The goal is that 50% of detected issues are resolved automatically without human intervention, with the remainder escalated for approval.
PHASE 5: AUTONOMOUS (MONTHS 24–36)
The final phase extends over 12 months—longer than the preceding phases—because full autonomy is not a single deployment event. It requires progressive expansion of automation scope, validation of continuous optimization across diverse workload patterns, and accumulation of sufficient operational data for the learning system to deliver meaningful accuracy improvements. Each increment of autonomy must be earned through demonstrated reliability.
The automation scope must be expanded to cover all common incident types identified and validated in Phase 4. The success criterion is that 80% of all incidents are resolved automatically. The remaining 20% represent novel failures, complex multi-domain incidents, or situations where policy requires human judgment.
Continuous optimization must become a background process. The network self-tunes PFC thresholds based on observed congestion patterns, adjusts dynamic load distribution policies as workload distributions shift, and reallocates buffer resources as traffic characteristics evolve. The success criterion is a 20% reduction in SLA violations compared to the Phase 3 baseline.
Cross-domain coordination must achieve full automation for standard intents. When a new GPU cluster is provisioned, the orchestration layer coordinates optical link provisioning, fabric configuration, and security policy establishment across domains without manual intervention. Human involvement is reserved for novel or high-risk changes.
The learning system must improve from experience. Machine learning models trained on historical incident and remediation data must increase root cause analysis accuracy over time. The success criterion is a 10% quarterly improvement in RCA accuracy.
COEXISTENCE: RUNNING LEGACY AND AI-READY NETWORKS IN PARALLEL
The transformation cannot be accomplished through a flag-day cutover. The existing cloud network must continue to operate and generate revenue throughout the transition. The AI-ready network is deployed as a separate physical infrastructure—dedicated optical links, dedicated fabric, dedicated switches—wherever possible. Physical separation eliminates the risk that AI workload traffic patterns will disrupt legacy services. Where physical separation is impractical, logical isolation with strict QoS enforcement provides the necessary workload separation. Interconnection points between the two networks must be engineered with the same packet loss, latency and throughput requirements as the AI-ready network. Operational processes must govern both environments simultaneously during a transition measured in years.
ORGANIZATIONAL TRANSFORMATION
The AI-ready network cannot be operated by a team trained only on legacy network operations. Three new skill domains become critical: AI workload literacy (understanding the traffic patterns and failure modes of distributed training and inference), telemetry and data engineering (building and operating streaming telemetry platforms and correlation engines), and automation engineering (designing and operating intent-based automation and CI/CD pipelines). The talent strategy must balance retraining existing engineers—many of the required skills are extensions of existing knowledge—with external hiring for skills that cannot be developed internally in the required timeframe. Retention of critical talent during the transformation is essential: the engineers who understand the legacy infrastructure are essential to the coexistence strategy.
FINANCIAL MODELING
Network investment for AI must be justified on value generation—the network cost per training run completed, per inference served, per GPU-hour utilized—not traditional cost efficiency metrics. This shift from cost-per-bit to value-per-outcome transforms the investment conversation. A network that costs more per gigabit but enables higher GPU utilization generates a return that far exceeds its cost premium. The five-phase roadmap enables investment to be spread over 24 to 36 months, with each phase delivering measurable value before the next begins. The cost of inaction must be quantified and presented alongside the cost of transformation.
CONCLUSIONS:
The physical network is no longer a utility layer that can be taken for granted. It is the foundation on which AI performance depends. The optical backbone determines whether GPU clusters operate at full utilization or sit idle. The network fabric determines whether distributed training completes in days or weeks. The automation and telemetry infrastructure determines whether issues are detected proactively or discovered after customer impact.
The four-pillar reference architecture defines what must be built. The five-phase implementation roadmap defines how to execute the transformation. Together, they form a complete program for infrastructure transformation leaders.
The technologies described here are deployed and operational in production AI networks today. The challenge for infrastructure leaders is not whether these approaches work, but how to adapt them to their organization’s specific constraints, scale, and timeline.
REFERENCES:
[1] TM Forum, “Autonomous Networks: Business Requirements and Framework,” TM Forum IG1251, 2025. [Online].
[2] AMD, “Next Gen Networking Transport for Large Scale AI Training,” May 2026. [Online].
htt
[3] Tolly Group, “Dell Networking Data Center AI Switch Fabric Congestion Mitigation Evaluation,” April 2026. [Online].
[4] Tech Field Day, “Cisco AI Networking Cluster Operations Deep Dive,” November 2025. [Online].
htt
[5] Akamai / WWT, “East-West Is the New North-South: Rethink Security for the AI-Driven Data Center,” February 2026. [Online]. htt
[6] NIST, “Zero Trust Architecture,” NIST Special Publication 800-207, Aug. 2020. [Online].
[7] IETF, “Network Configuration Protocol (NETCONF),” RFC 6241, June 2011. [Online].
[8] IETF, “RESTCONF Protocol,” RFC 8040, January 2017. [Online]. htt
[9] IEEE, “Priority-based Flow Control,” IEEE Standard 802.1Qbb, 2011.
[10] IEEE, “Congestion Notification,” IEEE Standard 802.1Qau, 2010.
[11] OpenConfig, “OpenConfig: Vendor-Neutral Network Configuration and Telemetry,” [Online]. https://www.
[12] Cloud Native Computing Foundation, “gRPC: A High-Performance, Open Source Universal RPC Framework,” [Online]. https://grpc.io/
[13] Ultra Ethernet Consortium, “Ultra Ethernet Specification,” [Online]. https://
………………………………………………………………………………………………………………………………………………………….
References from IEEE Techblog:
Why Batch Pipelines Break AI Agents: The Case For Streaming-First Network Operations
The enterprise network stack is collapsing; AI’s impact; comparison with “Batch Pipelines Break AI Agents”
ABOUT THE AUTHOR:
Shazia Hasnie, Ph.D., is VP Product Strategy and Innovation at Cuber AI, focused on Agentic Network Operations. Her work explores the intersection of autonomous systems, cloud-native infrastructure, and the economic models that make AI operations sustainable at scale. She brings over 20 years of global experience in communications networks and holds a Ph.D. in Communications Engineering from the Australian National University.
The Financial Trap of Autonomous Networks: Scaling Agentic AI in the Telecom Core
By Pavan Madduri with Ajay Lotan Thakur
The telecom industry wants autonomous, self-healing networks, but nobody is looking at the GPU bill. Running Agentic AI 24/7 “just in case” will bankrupt your IT department and ruin your ESG goals. The only way to survive the autonomous era is ruthless, event-driven orchestration that scales cognitive compute to absolute zero.
Introduction – The Compute Crisis:
The Compute Crisis Nobody is Talking About
Everyone in telecom right now is obsessed with “self-healing” autonomous networks. The vendor pitch sounds amazing. Just drop in some Agentic AI, let it watch your data plane, and watch it fix anomalies without a human ever touching a keyboard. But there’s a massive trap hiding underneath all that hype, and enterprise architects are completely ignoring it. It comes down to the raw physics of AI compute.
Unlike your standard microservices, which just run deterministic, compiled code on cheap CPU cycles, Agentic AI needs massive foundation models. To actually reason through a network failure, these models have to load gigabytes of weights into Video RAM and generate tokens. You need dedicated GPUs for this. We aren’t talking about cheap, stateless API calls here. These are the most expensive, power-hungry workloads in your entire datacenter.
If a telco tries to run an autonomous core the old-fashioned way by keeping high-end GPU nodes spinning 24/7 just in case a BGP route flaps, their cloud bill is going to wipe out any operational savings the AI was supposed to deliver.
The reality is that autonomy is no longer just a software problem. It’s a financial one. The telcos that actually win will not be the ones with the smartest AI. They will be the ones who figure out how to build a strict “scale-to-zero” environment. They need to spin up that expensive cognitive compute exactly when it is needed, and kill it the exact second the job is done.
Why Traditional Auto-scaling is Broken for AI:
When platform engineers first see the compute costs of running these AI agents, their first instinct is usually just to slap standard Kubernetes Horizontal Pod Autoscaling (HPA) on the cluster and call it a day. But standard HPA was built for stateless web servers, not massive cognitive engines. If you try to use it for Agentic AI in a telecom core, you’re going to fail for two big reasons.
The Cold-Start Penalty: Traditional autoscaling is entirely reactive. It sits around waiting for a CPU to hit 80% before it decides to scale up. In telecom, SLAs are measured in sub-milliseconds. If you wait for an anomaly to spike your CPU, then provision a new GPU node, pull a massive AI container image, and load the model weights into VRAM, you are talking about minutes of delay. By the time your AI agent actually wakes up to fix the problem, you have already breached your SLA.
CPU Utilization is a Liar: For AI workloads, standard hardware metrics are completely misleading. A GPU could be pegged at 90% utilization just thinking through a minor log warning, while a massive, critical network failure is stuck waiting in the queue. If your scaling logic is tied to hardware metrics instead of the actual severity of the event queue, you are just going to burn budget scaling blindly.
We have to abandon reactive resource metrics entirely and move to event-driven orchestration.
The Fix – Event-Driven Orchestration:
If standard HPA is broken for this, what is the fix? You have to completely decouple the infrastructure from the workload using strict, event-driven orchestration.
Instead of keeping baseline infrastructure running just to maintain a state, you treat cognitive compute as 100% ephemeral. You don’t scale based on how hard the CPU is working. You scale based on the exact depth and severity of the anomaly queue.
To actually build this, architects need purpose-built event-driven scalers like KEDA (Kubernetes Event-driven Autoscaling). KEDA lets your cluster completely bypass those reactive hardware metrics and listen directly to the network’s data plane.
But how do you avoid the cold-start latency of booting a fresh GPU pod? KEDA solves this by reacting to the event queue length itself rather than waiting for an existing pod’s CPU to max out. By the time a traditional HPA notices a CPU spike, the system is already overwhelmed. (To solve this exact issue in production, I open-sourced a custom KEDA scaler specifically designed to scrape and react to native GPU metrics, allowing the orchestrator to scale cognitive workloads preemptively. You can view the architecture on [GitHub])
KEDA intercepts the telemetry trigger at the source. When paired with a warm pool of paused GPU nodes and pre-pulled container images, KEDA can scale a pod from zero to active in milliseconds. The infrastructure is anticipating the load based on the queue, not reacting to the stress of it.
Here is what the workflow actually looks like when you do it right:
- The Trigger: Telemetry picks up a severe anomaly ,like a sudden 5G slice degradation, and pushes an event straight to a message broker like Kafka.
- The Scale-Up: KEDA intercepts that exact metric and instantly provisions a dedicated, GPU-backed AI pod from a warm standby pool.
- The Execution: The Agentic AI loads into VRAM, figures out the blast radius of the anomaly, and executes a fix. This is usually by reconciling the state through a GitOps controller.
- The Kill Switch: The absolute millisecond that the event queue clears and the network is stable, the orchestrator aggressively terminates the pod and gives the GPU back to the node pool.
You only pay the premium GPU tax during moments of active reasoning. The 24/7 idle tax is gone.
Architecting the Scale-to-Zero Core:
To make this scale-to-zero dream a reality, you have to fundamentally change how you handle network observability. The biggest mistake I see architects make is tightly coupling their monitoring tools with their AI execution layer. If your observability stack is running on the same hardware as your AI engine, you are literally wasting premium GPU compute just to watch logs.
You need a strict, physical separation of concerns:
The Watchers (The Lightweight Control Plane):
Your network data plane needs to be monitored by lightweight, CPU-efficient edge collectors like Prometheus or OpenTelemetry. These sit right at the edge, continuously eating millions of telemetry data points and BGP state changes. Because they don’t do any complex reasoning, they run incredibly cheap on standard CPU nodes.
The Thinkers (The Heavyweight Execution Plane):
Your expensive AI models are completely isolated in a separate, GPU-backed node pool that literally defaults to zero instances.
When the Watchers spot an anomaly, they don’t try to fix it. They just fire an alert to KEDA. KEDA then wakes up the Thinkers, spinning up the exact number of GPU pods needed to handle that specific blast radius. By decoupling the watchers from the thinkers, you guarantee that not a single cycle of GPU compute is wasted on baseline monitoring.
The Bottom Line:
Autonomous telecom networks are going to happen. But trying to brute-force the infrastructure provisioning is a fast track to bankrupting your IT department. The smartest Agentic AI in the world is useless if you can’t afford the cloud bill to run it.
Furthermore, this isn’t just about protecting the IT budget. Running idle GPUs 24/7 creates a massive, unnecessary carbon footprint. By enforcing a scale-to-zero architecture, telcos can drastically reduce the energy consumption of their autonomous networks, turning a massive ESG liability into a sustainable operational model.
Autonomy is no longer just a software engineering problem. It is an infrastructure balancing act. If Agentic AI is going to survive in the telecom core, we have to ditch legacy threshold scaling and embrace strict, event-driven orchestration.
Tools like KEDA give us the ability to build networks that are both cognitively brilliant and financially ruthless. We can spin up massive intelligence at the exact millisecond of failure and scale right back to zero the moment the network is healed.
References and Further Reading:
- Unlocking Energy Saving in Telecom Networks: A Path to a Sustainable Future – A deep dive into the operational and ESG mandates driving energy efficiency in modern telecom infrastructure.
- KEDA Documentation: Kubernetes Event-driven Autoscaling – Technical specifications for decoupling workload scaling from standard CPU/Memory metrics.
- keda-gpu-scaler – An open-source custom KEDA scaler I developed to enable event-driven autoscaling specifically tied to native GPU telemetry and queue depth.
Building and Operating a Cloud Native 5G SA Core Network
How Network Repository Function Plays a Critical Role in Cloud Native 5G SA Network
HPE Aruba Launches “Cloud Native” Private 5G Network with 4G/5G Small Cell Radios
…………………………………………………………………………………………….
About the Author:
Pavan Madduri is a Cloud-Native Architect, CNCF Golden Kubestronaut, and active IEEE researcher specializing in enterprise infrastructure automation, Agentic SREs, and Kubernetes networking. He designs scalable, zero-trust cloud environments and frequently writes about the intersection of AI governance and cloud-native infrastructure.
Connect with Pavan Madduri on [LinkedIn] .
Disclaimer: The author acknowledges the use of AI-assisted tools for structural formatting, language refinement, and copyediting during the drafting of this article. The core architectural concepts, technical opinions, and engineering strategies remain entirely original.
Does AI change the business case for cloud networking?
For several years now, the big cloud service providers – Amazon Web Services (AWS), Microsoft Azure, and Google Cloud – have tried to get wireless network operators to run their 5G SA core network, edge computing and various distributed applications on their cloud platforms. For example, Amazon’s AWS public cloud, Microsoft’s Azure for Operators, and Google’s Anthos for Telecom were intended to get network operators to run their core network functions into a hyperscaler cloud.
AWS had early success with Dish Network’s 5G SA core network which has all its functions running in Amazon’s cloud with fully automated network deployment and operations.
Conversely, AT&T has yet to commercially deploy its 5G SA Core network on the Microsoft Azure public cloud. Also, users on AT&T’s network have experienced difficulties accessing Microsoft 365 and Azure services. Those incidents were often traced to changes within the network’s managed environment. As a result, Microsoft has drastically reduced its early telecom ambitions.
Several pundits now say that AI will significantly strengthen the business case for cloud networking by enabling more efficient resource management, advanced predictive analytics, improved security, and automation, ultimately leading to cost savings, better performance, and faster innovation for businesses utilizing cloud infrastructure.
“AI is already a significant traffic driver, and AI traffic growth is accelerating,” wrote analyst Brian Washburn in a market research report for Omdia (owned by Informa). “As AI traffic adds to and substitutes conventional applications, conventional traffic year-over-year growth slows. Omdia forecasts that in 2026–30, global conventional (non-AI) traffic will be about 18% CAGR [compound annual growth rate].”
Omdia forecasts 2031 as “the crossover point where global AI network traffic exceeds conventional traffic.”
Markets & Markets forecasts the global cloud AI market (which includes cloud AI networking) will grow at a CAGR of 32.4% from 2024 to 2029.
AI is said to enhance cloud networking in these ways:
- Optimized resource allocation:
AI algorithms can analyze real-time data to dynamically adjust cloud resources like compute power and storage based on demand, minimizing unnecessary costs. - Predictive maintenance:
By analyzing network patterns, AI can identify potential issues before they occur, allowing for proactive maintenance and preventing downtime. - Enhanced security:
AI can detect and respond to cyber threats in real-time through anomaly detection and behavioral analysis, improving overall network security. - Intelligent routing:
AI can optimize network traffic flow by dynamically routing data packets to the most efficient paths, improving network performance. - Automated network management:
AI can automate routine network management tasks, freeing up IT staff to focus on more strategic initiatives.
The pitch is that AI will enable businesses to leverage the full potential of cloud networking by providing a more intelligent, adaptable, and cost-effective solution. Well, that remains to be seen. Google’s new global industry lead for telecom, Angelo Libertucci, told Light Reading:
“Now enter AI,” he continued. “With AI … I really have a power to do some amazing things, like enrich customer experiences, automate my network, feed the network data into my customer experience virtual agents. There’s a lot I can do with AI. It changes the business case that we’ve been running.”
“Before AI, the business case was maybe based on certain criteria. With AI, it changes the criteria. And it helps accelerate that move [to the cloud and to the edge],” he explained. “So, I think that work is ongoing, and with AI it’ll actually be accelerated. But we still have work to do with both the carriers and, especially, the network equipment manufacturers.”
Google Cloud last week announced several new AI-focused agreements with companies such as Amdocs, Bell Canada, Deutsche Telekom, Telus and Vodafone Italy.
As IEEE Techblog reported here last week, Deutsche Telekom is using Google Cloud’s Gemini 2.0 in Vertex AI to develop a network AI agent called RAN Guardian. That AI agent can “analyze network behavior, detect performance issues, and implement corrective actions to improve network reliability and customer experience,” according to the companies.
And, of course, there’s all the buzz over AI RAN and we plan to cover expected MWC 2025 announcements in that space next week.
https://www.lightreading.com/cloud/google-cloud-doubles-down-on-mwc
Nvidia AI-RAN survey results; AI inferencing as a reinvention of edge computing?
The case for and against AI-RAN technology using Nvidia or AMD GPUs
Generative AI in telecom; ChatGPT as a manager? ChatGPT vs Google Search
Telco and IT vendors pursue AI integrated cloud native solutions, while Nokia sells point products
The move to AI and cloud native is accelerating amongst network equipment and IT vendors which have announced highly integrated smart cloud solutions designed to migrate their telco customers into a new and profitable cloud future. The Cloud Native Computing Foundation (CNCF), as the name suggests, is a vendor-neutral consortium dedicated to making cloud native ubiquitous. The group defines cloud native as a collection of “technologies [that] empower organizations to build and run scalable applications in modern, dynamic environments such as public, private and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure and declarative APIs exemplify this approach.”
CNCF writes that the cloud native approach “enable[s] loosely coupled systems that are resilient, manageable and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toll.”
In particular, Ericsson, HPE/Juniper, Cisco, Huawei, ZTE, IBM, and Dell have all announced telco end to end solutions that provide a platform for new services and applications by integrating AI, automation, orchestration and APIs over cloud-native based infrastructure. Let’s look at each of those capabilities:
- AI (Artificial Intelligence): Leveraging AI capabilities allows telcos to automate processes, optimize network performance, and enhance customer experiences. By analyzing vast amounts of data, AI-driven insights enable better decision-making and predictive maintenance.
- Automation: Automation streamlines operations, reduces manual intervention, and accelerates service delivery. Whether it’s provisioning new network resources, managing security protocols, or handling routine tasks, automation plays a pivotal role in modern telco infrastructure.
- Orchestration: Orchestration refers to coordinating and managing various network functions and services. It ensures seamless interactions between different components, such as virtualized network functions (VNFs) and physical infrastructure. By orchestrating these elements, telcos achieve agility and flexibility.
- APIs (Application Programming Interfaces): APIs facilitate communication between different software components. In the telco context, APIs enable interoperability, allowing third-party applications to interact with telco services. This openness encourages innovation and the development of new applications.
- Cloud-Native Infrastructure: Moving away from traditional monolithic architectures, cloud-native infrastructure embraces microservices, containerization, and scalability. Telcos are adopting cloud-native principles to build resilient, efficient, and adaptable networks.
While each company has its unique approach, the overarching goal is to empower telcos to deliver cutting-edge services, enhance network performance, and stay competitive in an ever-evolving industry. These advancements pave the way for exciting possibilities in the telecommunications landscape. When fully integrated, these technologies will enable the creation of smart cloud networks that can run themselves without human involvement and do so less expensively — but also more efficiently, responsively and securely than anything that exists today.
Our esteemed UK colleague Stephen M Saunders, MBE (Member of the Order of the British Empire– more below) notes that Nokia is not embracing smart cloud telco solutions, but is instead focusing on individual products. Last October, the company announced strategic and operational changes to its business model and divided the company into four business units. At that time, Nokia’s President and CEO Pekka Lundmark said:
“We continue to believe in the mid to long term attractiveness of our markets. Cloud Computing and AI revolutions will not materialize without significant investments in networks that have vastly improved capabilities. However, while the timing of the market recovery is uncertain, we are not standing still but taking decisive action on three levels: strategic, operational and cost. First, we are accelerating our strategy execution by giving business groups more operational autonomy. Second, we are streamlining our operating model by embedding sales teams into the business groups and third, we are resetting our cost-base to protect profitability. I believe these actions will make us stronger and deliver significant value for our shareholders.”
Steve says Nokia’s new divide-and-conquer strategy is being reinforced at its sales meetings, according to an attendee at one such gathering this year, with sales reps being urged to laser-focus on selling point products.
“The telco capex situation at the moment means Nokia — and others — have no choice but to examine every aspect of their business to work out how to adjust for a future CSP market that is itself going through dramatic change,” said Jeremiah Caron, global head of research and analysis at market research firm GlobalData Technology.
Most telcos are increasingly adopting cloud-native technologies to meet the demands of 5G SA core networks and to better automate their services.. However, some telcos are hesitant to fully embrace cloud-native due to concerns about complexity, cost, and reliability. Other challenges of cloud native are: changing the software development life cycle, privacy and security, guaranteeing end to end latency, and cloud vendor lock-in due to a lack of standards (every cloud vendor has their own proprietary APIs and network access configurations.
References:
https://www.silverliningsinfo.com/multi-cloud/report-smart-cloud-and-coming-paradigm-shift
https://www.fiercewireless.com/5g/op-ed-whither-nokia
Building and Operating a Cloud Native 5G SA Core Network
Omdia and Ericsson on telco transitioning to cloud native network functions (CNFs) and 5G SA core networks
https://www.ericsson.com/en/ran/intelligent-ran-automation/intelligent-automation-platform
https://www.huaweicloud.com/intl/en-us/solution/telecom/cloud-native-development-platform.html
https://sdnfv.zte.com.cn/en/solutions/VNF/5G-core-network/cloud-native
https://www.ibm.com/products/cloud-pak-for-network-automation
https://www.dell.com/en-us/dt/industry/telecom/index.htm#tab0=0
Steve Saunders (a.k.a. Silverlinings‘ Sky Captain), is a British-born communications analyst, investor, and digital media entrepreneur. In 2018 he was awarded an MBE in the Queen’s Birthday Honours List for services to the telecommunications industry and business.
Forbes: Cloud is a huge challenge for enterprise networks; AI adds complexity
Survey data and discussions with enterprise networking professionals reveal they are still grappling with many networking issues spawned by the expansion of the cloud – the most common of which include securing connections for remote work, implementing zero-trust security strategies, and integrating myriad cloud and wide-area networks (WANs).
For example, in Futuriom’s latest survey of 196 enterprise IT and networking professionals, more than 80% said the complexity of connecting the wide variety of networks was a large challenge. At nearly 70% of responses, expertise and knowledge was the second-largest challenge (multiple responses were allowed), and cost was cited by 60%. Please refer to survey highlights below.
Contributing to that complexity is the ephemeral nature of both cloud connectivity and hybrid work. Workers are now moving around more than ever, and cloud services can change and scale nearly every day (or minute).
Survey Highlights:
- Survey respondents indicate strong demand for SD-WAN and SASE managed services. Our survey data and discussions with end users indicate that SD-WAN/SASE technology helps professionals with network and security challenges, including the growing complexity created by distributed applications, cloud connectivity, and sprawling security risks.
- Managing network complexity is the largest challenge driving managed services demand. When asked about the largest challenges in managing WANs, 85% of respondents identified complexity, followed by expertise and knowledge (68%). Rounding out the responses were cost (60%) and time (47%). (Multiple responses were allowed.)
- Hybrid work and the need for zero-trust network access (ZTNA) are key drivers of SD-WAN/SASE technology. In the survey, 98% of respondents said that hybrid work has increased demand for SASE and ZTNA. When we asked respondents if ZTNA is a crucial component of SASE and SD-WAN offerings, 92% said yes.
- Hybrid (cloud/edge deployment) and single-pass architectures will be important components of SASE/SD-WAN services going forward. When respondents were asked if they wanted a hybrid solution that can accommodate networking and security both on premises and using cloud points of presence (PoPs), 98% said yes. In addition, 94% of respondents said they prefer a single-pass architecture.
- There will continue to be a diversity of SD-WAN/SASE deployment models. The two most popular models for deployment are best-of-breed combination (34%) and single-vendor (23%), but survey results show a wide diversity of deployment models.
AI increases complexity as enterprises need to figure out how to store, connect, and move their data in hybrid clouds that will leverage AI.
This complexity, along with the rapid shift to hybrid work spurred by COVID, has triggered a wave of innovation in networking – perhaps more innovation than we have seen in decades. Startups are drawing large funding rounds. Best-of-breed established networking players such as Arista Networks, Extreme Networks, Juniper Networks, and HPE are building new networking and security products and chipping away at the market share of market leader Cisco. Cisco is responding in kind. Sources tell me they think Cisco’s acquisition of Valtix may be the most interesting in years.
All of this sets the stage for the most dynamic networking environment I’ve seen in decades. And it’s only going to get more interesting, as the AI and hybrid work wave makes networking more crucial.
The melding of security and networking remains hot. In the software-defined networking (SD-WAN) and Secure Access Service Edge market, potential Initial Public Offering (IPO) companies such as Aryaka Networks, Cato Networks, and Versa Networks are building our product suites to help secure remote workers and cloud connectivity. These companies will also help enterprises connect to cloud on-ramps and consolidate security functions with a SASE approach. Versa last October tanked up with $120 in funding in what it called a “pre-IPO round.”
Many of the cloud networking startups that are included in the Futuriom 50 list of promising cloud innovators are using this chaotic moment to shore up strategies, raise money — or both.
For example, just this week, cloud-native networking start-up Arrcus announced that Hitachi Ventures would invest additional capital, raising its Series D to $65 million before it closes. Arrcus says its Arrcus Connected Edge (ACE) platform will be more economical for cloud providers and service providers deploying services such as 5G and AI. It claims it is growing revenue 100% year-over-year.
Other cloud networking startups are also going after AI. DriveNets recently announced that its Network Cloud-AI solution, which uses cloud-based Ethernet-based networking to boost the performance of AI clouds, is in trials with major hyperscalers.
Cost optimization, one of the strongest themes of the year in cloud technology, is another focus for cloud networking players. Cloud networking pioneer Aviatrix has beefed up security and cost-optimization features and launched a distributed firewall to help enterprises reduce the costs of cloud networking infrastructure. Prosimo last week made an interesting play to get its application-layer cloud networking suite in the hands of more users by launching a free, introductory-level version of its product called MCN Foundation.
Yes, there is a trend to all these announcements. They are focused on return on investment (ROI) and cost savings. This is the right message for the era we are in. Enterprise tech planners not only want to shift to more flexible cloud-based services, they need to do so to save money.
For example, in its new product release, Prosimo said customers can achieve a 30%-50% reduction in total cost of ownership (TCO) by optimizing cloud network connectivity. With its distributed firewall, Aviatrix says network pros will save money by reducing the expense of additional firewall instances, which many enterprises must buy to support additional cloud connectivity and scaling. (But they may not want to stack firewall upon firewall into the cloud, which after all can function as a firewall itself.) DriveNets says its trials have reduced the idle time of AI clouds by as much as 30%.
Integrating all of this stuff isn’t easy either. That’s the value proposition of Itential, a plucky Georgia-based startup with a set of low-code automation tools that streamline networking for integrations in hybrid networking and cloud environments.
It’s no coincidence that the marketing messages have all shifted toward ROI, which is the mother’s milk of technology. It’s the reason we all use cloud-based software-as-a-service and iPhones instead of minicomputers and rotary dial phones. Innovation is about efficiency.
This makes me very optimistic about cloud networking – and the networking market in general. After decades of stagnation, the cloud has woken up the industry. In addition to innovation, there is also a surge in competition — which will put more efficient and affordable technology into the hands of the users.
References:
Networking Startups Jump On Cloud Costs And AI (forbes.com)
https://www.futuriom.com/articles/news/results-from-our-sd-wan-sase-managed-services-survey/2023/06
Generative AI in telecom; ChatGPT as a manager? ChatGPT vs Google Search
Generative AI could put telecom jobs in jeopardy; compelling AI in telecom use cases
Allied Market Research: Global AI in telecom market forecast to reach $38.8 by 2031 with CAGR of 41.4% (from 2022 to 2031)
Telecom TV Poll: How to maximize cloud-native opportunities?
The adoption of cloud-native methodologies, processes and tools has been a challenge for communications service providers (CSPs), aka telcos or network operators.
- Telcos are embracing cloud-native processes and tools
- It’s part of their evolution towards being digital service providers
- But the cloud-native journey is still in its early stages
- Real cultural change is needed if telcos are to capitalise fully on the cloud-native opportunities
Alongside a a session, Why cloud native is essential to delivering the automation, agility and innovation needed to support new services, at Telco TV’s DSP Leaders World Forum event in Windsor, UK, a poll was taken. The following question was asked, “How can Digital Service Providers maximize the cloud-native opportunities?” Respondents were able to select all the options they deemed relevant. Here are the results:
Please check out the upcoming Cloud Native Telco Summit session on cloud-native application development to see what the industry experts have to say.
Omdia and Ericsson on telco transitioning to cloud native network functions (CNFs) and 5G SA core networks
Huawei Connect 2022: It’s Cloud Native everything!
Cloud RAN with Google Distributed Cloud Edge; Strategy: host network functions of other vendors on Google Cloud
At MWC 2023 Barcelona, Google Cloud announced that they can now run the radio access network (RAN) functions as software on Google Distributed Cloud Edge, providing communications service providers (CSPs- AKA telcos) with a common and agile operating model that extends from the core of the network to the edge, for a high degree of programmability, flexibility, and low operating expenses. CSPs have already embraced open architecture, open-source software, disaggregation, automation, cloud, AI and machine learning, and new operational models, to name a few. The journey started in the last decade with Network Functions Virtualization, primarily with value added services and then deeper with core network applications, and in the past few years, that evolved into a push towards cloud-native. With significant progress in the core, the time for Cloud RAN is now, according to Google. However, whether for industry or region-specific compliance reasons, data sovereignty needs, or latency or local data-processing requirements, most of the network functions deployed in a mobile or wireline network may have to follow a hybrid deployment model where network functions are placed flexibly in a combination of both on-premises and cloud regions. RAN, which is traditionally implemented with proprietary hardware, falls into that camp as well.
In 2021,the company launched Google Distributed Cloud Edge (GDC Edge), an on-premises offering that extends a consistent operating model from our public Google Cloud regions to the customer’s premises. For CSPs, this hybrid approach makes it possible to modernize the network, while enabling easy development, fast innovation, efficient scale and operational efficiency; all while simultaneously helping to reduce technology risk and operational costs. GDC Edge became generally available in 2022.
Google Cloud does not plan to develop its own private wireless networking services to sell to enterprise customers, nor does the company plan to develop its own networking software functions, according to Gabriele Di Piazza, an executive with Google Cloud who spoke at MWC 2023 in Barcelona. Instead, Google Cloud would like to host the networking software functions of other vendors like Ericsson and Mavenir in its cloud. It would also like to resell private networking services from operators and others.
Rather than develop its own cloud native 5G SA core network or other cloud networking software (like Microsoft and AWS are doing), Google Cloud wants to “avoid partner conflict,” Di Piazza said. Google has been building its telecom cloud story around its Anthos platform. That platform is directly competing against the likes of AWS and Microsoft for telecom customers. According to a number of analysts, AWS appears to enjoy an early lead in the telecom industry – but its rivals, like Google, are looking for ways to gain a competitive advantage. One of Google’s competitive arguments is that it doesn’t have aspirations to sell network functions. Therefore, according to Di Piazza, the company can remain a trusted, unbiased partner.
Image Credit: Google Cloud
Last year, the executive said that moving to a cloud-native architecture is mandatory, not optional for telcos, adding that telecom operators are facing lots of challenges right now due to declining revenue growth, exploding data consumption and increasing capital requirements for 5G. Cloud-native networks have significant challenges. For example, there is a lack of standardization among the various open-source groups and there’s fragmentation among parts of the cloud-native ecosystem, particularly among OSS vendors, cloud providers and startups.
In recent years, Google, Microsoft, Amazon, Oracle and other cloud computing service providers have been working to develop products and services that are specifically designed to allow telecom network operator’s to run their network functions inside a third-party cloud environment. For example, AT&T and Dish Network are running their 5G SA core networks on Microsoft Azure and AWS, respectively.
Matt Beal, a senior VP of software development for Oracle Communications, said his company offers both a substantial cloud computing service as well as a lengthy list of network functions. He maintains that Oracle is a better partner for telecom network operators because of it. Beal said Oracle has long offered a wide range of networking functions, from policy control to network slice management, that can be run inside its cloud or inside the cloud of other companies. He said that, because Oracle developed those functions itself, the company has more experience in running them in a cloud environment compared with a company that hasn’t done that kind of work. Beal’s inference is that network operators ought to partner with the best and most experienced companies in the market. That position runs directly counter to Google’s competitive stance on the topic. “When you know how these things work in real life … you can optimize your cloud to run these workloads,” he said.
While a number of other telecom network operators have put things like customer support or IT into the cloud, they have been reluctant to release critical network functions like policy control to a cloud service provider.
References:
https://cloud.google.com/solutions/telecommunications
https://cloud.google.com/blog/topics/telecommunications
Canalys: Cloud marketplace sales to be > $45 billion by 2025
Canalys now expects that by 2025, cloud marketplaces will grow to more than $45 billion, representing an 84% CAGR. That was one of the market research firm’s predictions for 2023 and beyond (see chart below).
Cloud marketplaces [1.] are accelerating as a route to market for technology, led by hyperscale cloud vendors such as Alibaba, Amazon Web Services, Microsoft, Google and Salesforce, which are pouring billions of development dollars into the sector.
Note 1. A cloud marketplace is an online storefront operated by a cloud service provider. A cloud marketplace provides customers with access to software applications and services that are built on, integrate with or complement the cloud service provider’s offerings. A marketplace typically provides customers with native cloud applications and approved apps created by third-party developers. Applications from third-party developers not only help the cloud provider fill niche gaps in its portfolio and meet the needs of more customers, but they also provide the customer with peace of mind by knowing that all purchases from the vendor’s marketplace will integrate with each other smoothly.
…………………………………………………………………………………………………………………………………………………………………….
“The marketplace route to market is on fire and cannot be ignored by any channel leader,” said Canalys Chief Analyst, Jay McBain. “Marketplaces grew more in the first three months of the pandemic than in the previous decade and have just kept growing,” he added.
“We under-called it,” explained Steven Kiernan, vice president at Canalys. “Cloud marketplaces are accelerating at such a dizzying speed that we’ve doubled our pre-pandemic forecast.
Some software vendors that are active on marketplaces, in particular cybersecurity vendors, are publicly reporting as much as 600% year-on-year growth via this channel, according to McBain.
In addition, the hyperscalers are now reporting growing numbers of billion-dollar customer commitments through enterprise cloud consumption credits, which cover more than just software.
The large cloud marketplaces have lowered fees from upwards of 20% down to 3%, enabling vendors to fund multi-partner offers inside the transaction.
Private equity is funding billions more into marketplace development firms such as AppDirect, Mirakl, Vendasta and CloudBlue to enable hundreds of niche marketplaces across different buyers, industries, geographies, customer segments, product areas and business models.
Canalys Chief Analyst, Alastair Edwards:
“The rise of this route to market represents a threat to both resellers and two-tier distribution. But as more complex technologies are consumed via marketplaces, end customers are also turning to trusted partners to help them discover, procure and manage marketplace purchases. The hyperscalers are increasingly recognizing the value of channel partners, allowing them to create customized vendor offers for end-customers, and supporting the flow of channel margins through their marketplaces. Hyperscalers’ cloud marketplaces are becoming a growing force in global IT distribution as a result.”
By 2025, Canalys conservatively forecasts that almost a third of marketplace procurement will be done via channel partners on behalf of their end customers.
Canalys key predictions for 2023 and beyond:
About Canalys:
Canalys is an independent analyst company that strives to guide clients on the future of the technology industry and to think beyond the business models of the past. We deliver smart market insights to IT, channel and service provider professionals around the world. We stake our reputation on the quality of our data, our innovative use of technology and our high level of customer service.
References:
https://canalys.com/newsroom/cloud-marketplace-forecast-2023
https://www.canalys.com/resources/Canalys-outlook-2023-predictions-for-the-technology-industry
https://www.techtarget.com/searchitchannel/definition/cloud-marketplace
Canalys: Global cloud services spending +33% in Q2 2022 to $62.3B
AWS, Microsoft Azure, Google Cloud account for 62% – 66% of cloud spending in 1Q-2022
IDC: Cloud Infrastructure Spending +13.5% YoY in 4Q-2021 to $21.1 billion; Forecast CAGR of 12.6% from 2021-2026
Omdia and Ericsson on telco transitioning to cloud native network functions (CNFs) and 5G SA core networks
Introduction:
Telco cloud has evolved from the much hyped (but commercially failed) NFV/Virtual Network Functions or VNFs and classical SDN architectures, to today’s more robust platforms for managing virtualized and cloud-native network functions that are tailored to the needs of telecom network workloads. This shift is bringing many new participants to the rapidly evolving telco cloud [1.] landscape.
Note 1. In this instance, “telco cloud” means running telco network functions, including 5G SA Core network on a public, private, or hybrid cloud platform. It does NOT imply that telcos are going to be cloud service providers (CSPs) and compete with Amazon AWS, Microsoft Azure, Google Cloud, Oracle Cloud, IBM, Alibaba and other established CSPs. Telcos gave up on that years ago and sold most of their own data centers which they intended to make cloud resident.
………………………………………………………………………………………………………………………………………………………………………………..
In its recent Telco Cloud Evolution Survey 2022, Omdia (owned by Informa) found that both public and private cloud technology specialists are shaping this evolution. In July 2022, Omdia surveyed 49 senior operations and IT decision makers among telecom operator. Their report reveals their top-of-mind priorities, optimism, and strategies for migrating network workloads to private and public cloud.
Transitioning from VNFs to CNFs:
The existing implementations of telco cloud mostly take the virtualization technologies used in datacenter environments and apply them to telco networks. Because telcos always demand “telco-grade” network infrastructure, this virtualization of network functions is supported through a standard reference architecture for management and network orchestration (MANO) defined by ETSI. The traditional framework was defined for virtual machines (VMs) and network functions which were to be packaged as software equivalents (called network appliances) to run as instances of VMs. Therefore, a network function can be visualized as a vertically integrated stack consisting of proprietary virtualization infrastructure management (often based on OpenStack) and software packages for network functions delivered as monolithic applications on top. No one likes to admit, but the reality is that NFV has been a colossal commercial failure.
The VNFs were “lift & shift” so were hard to configure, update, test, and scale. Despite AT&T’s much publicized work, VNFs did not help telcos to completely decouple applications from specific hardware requirements. The presence of highly specific infrastructure components makes resource pooling quite difficult. In essence, the efficiencies telcos expected from virtualization have not yet been delivered.
The move to cloud native network functions (CNFs) aims to solve this problem. The softwardized network functions are delivered as modern software applications that adhere to cloud native principles. What this means is applications are designed independent of the underlying hardware and platforms. Secondly, each functionality within an application is delivered as a separate microservice that can be patched independently. Kubernetes manages the deployment, scaling, and operations of these microservices that are hosted in containers.
5G Core leads telcos’ network workload containerization efforts:
The benefits of cloud-native are driving telcos to implement network functions as containerized workloads. This has been realized in cloud native 5G SA core networks (5G Core), the architecture of which is specified in 3GPP Release 16. A key finding from the Telco Cloud Evolution Survey 2022, was that over 60% of the survey respondents picked 5G core to be run as containerized workloads. The vendor ecosystem is maturing fast to support the expectations of telecom operators. Most leading network equipment providers (NEPs) have built 5G core as cloud-native applications.
Which network functions do/will you require to be packaged in containers? (Select all that apply):
This overwhelming response from the Omnia survey respondents is indicative of their growing interest in hosting network functions in cloud environments. However, there remain several important issues and questions telcos need to think about which we now examine:
The most challenging and frequent question is whether telcos should run 5G core functions and workloads in public cloud (Dish Network and AT&T) or in their own private cloud infrastructure (T-Mobile)? The choice is influenced by multiple factors including understanding the total cost of running network functions in public vs private cloud, complying with data regulatory requirements, resilience and scalability of infrastructure, maturity of cloud platforms and tools, as well as ease of management and orchestration of resources across distributed environments.
…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………….
Ericsson says the adoption of cloud-native technology and the new 5G SA Core network architecture will impact six strategic domains of a telco network, each of which must be addressed and resolved during the telco’s cloud native transformation journey: Cloud infrastructure, 5G Core, 5G voice, automation and orchestration, operations and life cycle management, and security.
In the latest version of Ericsson’s cloud-native 5G Core network guide (published December 6, 2022), the vendor has identified five key insights for service providers transitioning to a cloud native 5G SA core network:
- Cloud-native transformation is a catalyst for business transformation. Leading service providers make it clear they view the transformation to cloud-native as a driver for the modernization of the rest of their business. The company’s ability to bring new products and solutions to market faster should be regarded as being of equal importance to the network investment.
- Clear strategy and planning for cloud-native transformation is paramount. Each individual service provider’s cloud-native transformation journey is different and should be planned accordingly. The common theme is that the complexity of transforming at this scale needs to be recognized, and must not be underestimated. For maximum short-and-long-term impact tailored, effective migration strategies need to be in place in advance. This ensures that investment and execution in this area forms a valuable element of an overall transformation strategy and plan.
- Frontrunners will establish first-mover advantage. Time should be a key factor in driving the plans and strategies for change. Those who start this journey early will be leading the field when they’re able to deploy new functionalities and services. A common frontrunner approach is to start with a greenfield 5G Core deployment to try out ideas and concepts without disrupting the existing network. Additionally, evolving the network will be a dynamic process, and it is crucial to bring application developers and solution vendors into the ecosystem as early as possible to start seeing faster, smoother innovation.
- Major potential for architecture simplifications. The standardization of 5G Core has been based on architecture and learnings from IT. The telecom stack should be simplified by incorporating cloud native principles into it – for example separating the lifecycle management of the network functions from that of the underlying Kubernetes infrastructure. While any transformation needs to balance both new and legacy technologies, there are clear opportunities to simplify the network and operations further by smart investment decisions in three major areas. These are: simplified core application architecture (through dual-mode 5G Core architecture); simplified cloud-native infrastructure stack (through Kubernetes over bare-metal cloud infrastructure architecture); and Automation stack.
- Readiness to automate, operate and lifecycle manage the new platform must be accelerated. Processes requiring manual intervention will not be sufficient for the levels of service expected of cloud-native 5G Core. Network automation and continuous integration and deployment (CI/CD) of software will be crucial to launch services with agility or to add new networks capabilities in line with advancing business needs. Ericsson’s customer project experience repeatedly shows us another important aspect of this area of change, telling us that the evolution to cloud-native is more than a knowledge jump or a technological upgrade – it is also a mindset change. The best platform components will not deliver their full potential if teams are not ready to use them.
Monica Zethzon, Head of Solution Area Core Networks, Ericsson said: “The time is now. Service providers need to get ready for the cloud-native transformation that will enable them to reach the full potential of 5G and drive innovation, shaping the future of industries and society. We are proud to be at the forefront of this transformation together with our leading 5G service providers partners. With this guide series we want to share our knowledge and experiences with every service provider in the world to help them preparing for their successful journeys into 5G.”
Ericsson concludes, “The real winners of the 5G era will be the service providers who can transform their core networks to take full advantage of what 5G Standalone (SA) and cloud-native technologies can offer.”
…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………….
Omdia says another big challenge telcos need to manage is the fragmentation in cloud-native tools and approaches adopted by various technology providers. Again, this is nothing new as telcos have faced and lived through similar situations while evolving to the NFV era. However, the scale and complexity are much bigger as network functions will be distributed, multi-vendor, and deployed across multiple clouds. The need for addressing these gaps by adopting clearly defined specifications (there are no standards for cloud native 5G core) and open-source projects is of utmost importance.
…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………….
References:
Overcoming the challenges telcos face on their journey to containerized network functions
https://omdia.tech.informa.com/OM023495/Telco-Cloud-Evolution-Survey–2022
https://www.ericsson.com/en/news/2022/10/ericsson-publishes-the-cloud-native
https://www.t-mobile.com/news/network/t-mobile-lights-up-standalone-ultra-capacity-5g-nationwide
Dell partners with Wind River on modular cloud-native telecommunications infrastructure
Dell Technologies, together with Wind River (owned by Intel and Delphi Automotive), is introducing a new telecom cloud infrastructure solution to help communications service providers (CSPs) reduce complexity and accelerate their “cloud-native” network deployments.
To facilitate these solutions, Dell’s telecom partner certification program simplifies the process for technology partners to validate and integrate their products within a rapidly growing open technology ecosystem.
Dell Telecom Infrastructure Blocks help accelerate open, cloud-native network deployments. Dell is taking an entirely new approach to solve the complexities of cloud-native network deployments with Dell Telecom Infrastructure Blocks. The fully engineered, cloud-native infrastructure blocks simplify telecom cloud network deployment and management, while accelerating the introduction of new technologies and lowering operational expenses (OpEX).
As the fastest way to deploy the Dell Telecom Multicloud Foundation, launched earlier this year, these blocks include Dell PowerEdge servers, Dell Bare Metal Orchestrator management software, and a CSP’s choice of integrated telecom cloud software platforms, beginning with Wind River Studio.
Dell is the first company to launch a co-engineered system with Wind River, designed and factory integrated to host telecom workloads that can be scaled easily with automation, with streamlined support from Dell for the entire infrastructure stack3. The validated and pre-packaged blocks of hardware and software are designed to meet specific telecom workload requirements and use cases, spanning the network core to Open RAN Distributed Units (DU) and Centralized Units (CU).
Wind River delivers mature production-ready offerings based on proven Wind River Studio technology, live in deployments with leading operators. Wind River Studio provides the Containers-as-a-Service layer for a distributed cloud and the tools to automate and optimize “Day 2” operations at scale.
Holger Mueller of Constellation Research Inc. said today’s partnership with Wind River is all about making it easier for telecommunications firms to go live on Dell’s hardware and services. “What’s really of note is the new partner self-certification program,” the analyst said. “Partner certification can be slow and is normally always very expensive. So unleashing a self-service process for partners can be a huge accelerator, as long as the quality of the certification is not compromised.
Dennis Hoffman, senior vice president and general manager, Dell Technologies Telecom Systems Business:
As the telecom network disaggregates, network operators are challenged to effectively acquire, deploy, test and operate a myriad of open, cloud-native solutions. With our portfolio of software, solutions, development labs and partner programs, including our first open, telecom cloud engineered system with Wind River, a leader in Open RAN deployments, we can partner with communications service providers globally to simplify their transition to cloud-native technologies.
Kevin Dallas, president and chief executive officer, Wind River:
Our collaboration with Dell will help address complex CSP challenges in deploying and managing a physically distributed, ultra-low-latency cloud-native infrastructure for intelligent edge networks. As the de facto infrastructure for OpenRAN and 5G vRAN and only 5G solution that is commercially deployed at scale, Wind River Studio enables flexible networks and offers validated architectures to help service providers quickly and reliably deploy new services with industry-leading total cost of ownership for a cloud native future.
References:
