Welcome to “Complex Made Clear” – where we take the intimidating, untangle the technical, and make the complicated feel conquerable. In this series, we break down complex topics into digestible, easy-to-understand pieces without losing their essential meaning. Whether you’re a seasoned professional looking to grasp new concepts or someone just starting their journey, each article serves as your friendly guide through the maze of modern technology and business concepts. No jargon without explanation, no assumptions about prior knowledge – just clear, straightforward explanations that help you have those “oh, now I get it!” moments. Let’s make the complex clear, together.
We covered telco network complexity in the previous blog https://www.vamsitalkstech.com/5g/complex-made-clear-the-network-complexity-crisis-%e2%85%93-why-traditional-telco-automation-is-breaking-down/ , from intent-driven orchestration to configuration-as-data: the emerging patterns that are solving the telecommunications industry’s biggest automation challenges
Beyond Templates: The Configuration-as-Data Revolution
After spending years watching telecommunications operators struggle with template-heavy Infrastructure-as-Code approaches, I’ve become convinced that we’ve been solving the wrong problem. The issue isn’t better templates—it’s treating configuration as what it really is: structured data that needs to be manipulated, validated, and versioned like any other business-critical dataset.
Enter the Configuration-as-Data (CaD) paradigm, most prominently demonstrated in the Nephio project. Instead of embedding configuration logic in imperative scripts or complex templates, CaD treats all system configuration as structured, machine-readable data—typically expressed using the Kubernetes Resource Model (KRM). This isn’t just a philosophical shift; it’s a practical engineering solution that changes how we approach automation at scale.
Figure 1: Evolution from template-based IaC to Configuration-as-Data approaches
What makes this powerful is the separation of concerns. Configuration data is stored in Git repositories where it can be versioned, reviewed, and audited. The logic for transforming high-level intent into specific configurations lives in specialized functions (often called “specializers” or “mutators”) that can be developed, tested, and updated independently. When you need to deploy a 5G network slice across 50 edge locations, you don’t write 50 different configuration files—you declare your intent once and let automated specializers handle the site-specific adaptations.
This approach has already proven itself in practice. Google’s internal infrastructure management has been built on similar principles for years, and we’re now seeing these patterns emerge in telecommunications through projects like Nephio and the broader Kubernetes ecosystem.
Intent-Driven Automation: Declaring What, Not How
One of the most significant paradigm shifts in network automation is the move from imperative (“do this, then do that”) to declarative (“achieve this state”) approaches. Intent-driven automation takes this concept further by operating at an even higher level of abstraction: instead of declaring specific resource configurations, operators declare business intent and let the system figure out how to achieve it.
Figure 2: Intent-driven automation hierarchy from business goals to infrastructure implementation
The beauty of intent-driven systems becomes apparent when things change—and in telecommunications, things always change. When a new edge site comes online, when hardware fails, when traffic patterns shift, or when regulatory requirements change, operators don’t need to manually recalculate optimal configurations. The intent remains constant (“provide low-latency 5G connectivity for manufacturing workloads”), but the system automatically adapts the underlying implementation to maintain that intent.
Projects like ONAP have pioneered many of these concepts, particularly in closed-loop automation scenarios. When ONAP’s Data Collection, Analytics & Events (DCAE) component detects that a network slice is no longer meeting its latency requirements, the Policy Framework can automatically trigger remediation actions through the Service Orchestrator—whether that’s scaling resources, rerouting traffic, or even spinning up additional network function instances at different locations.
The Kubernetes Control Plane Pattern: Scaling Declarative Management
Perhaps the most significant architectural pattern emerging in telecommunications automation is the adoption of Kubernetes-style control loops for managing not just containerized applications, but entire network infrastructures. This isn’t about running everything in containers—it’s about leveraging the proven patterns of declarative configuration, continuous reconciliation, and controller-based automation that have made Kubernetes so successful.
Figure 3: Kubernetes-style control plane pattern for telecommunications infrastructure management
What makes this approach powerful is the active reconciliation model. Instead of “deploy and pray,” controllers continuously monitor the actual state of managed resources and take corrective action whenever they detect drift from the desired state. This isn’t just theoretical—operators like Bell Canada and Orange are already using these patterns in production environments.
The Nephio project exemplifies this approach. By extending Kubernetes with Custom Resource Definitions (CRDs) that model telecommunications concepts—network topologies, service requirements, multi-cluster deployments—it provides a uniform API for managing complex, distributed network infrastructures. When you want to deploy a 5G core across multiple cloud providers, you declare your intent using standard Kubernetes manifests, and specialized controllers handle the complexity of translating that intent into provider-specific actions.
Modular Architecture: The Microservices Lesson for Network Automation
The telecommunications industry is finally embracing the microservices lesson that transformed software development: complex systems are more manageable when broken into smaller, loosely-coupled components with well-defined interfaces. This applies not just to the network functions themselves, but to the automation systems that manage them.
Figure 4: Evolution from monolithic platforms to modular automation architectures
This shift is evident in the evolution of projects like ONAP, which has initiated “streamlining” efforts to make individual components more consumable independently. Instead of requiring operators to adopt the entire ONAP platform, they can now leverage specific capabilities—like the Service Orchestrator (SO) for workflow management or the SDN Controller (SDN-C) for network configuration—in combination with other tools.
The FD.io project demonstrates this modularity at the data plane level. Rather than providing a monolithic networking solution, FD.io offers a plugin-based architecture where network functions can be composed from modular components. Need IPsec encryption? Add the IPsec plugin. Want load balancing? Include the load balancer plugin. This approach allows network function vendors to build exactly the capabilities they need without carrying the weight of unused features.
Hardware-Software Co-Design: The Performance Reality
While much of the industry focus has been on software automation, the reality is that modern telecommunications workloads require careful coordination between software intelligence and hardware capabilities. The most successful automation solutions recognize this and design for hardware-software co-design from the ground up.
Figure 5: Hardware-software co-design for telecommunications performance optimization
Samsung’s 5G UPF implementation, which achieved over 1 Tbps throughput using VPP and Intel hardware acceleration, illustrates this principle perfectly. The solution doesn’t just rely on fast software or powerful hardware—it’s the intelligent coordination between VPP’s vector processing capabilities, Intel E810 NIC’s Dynamic Device Personalization features, and careful NUMA topology management that delivers breakthrough performance.
This hardware-software awareness is being built into automation platforms as well. The Anuket project’s reference architectures explicitly define hardware requirements and capabilities that network functions can depend on. When an automation system deploys a 5G UPF, it’s not just placing a container—it’s ensuring the underlying infrastructure provides the NUMA topology, CPU features, and I/O capabilities that the function needs to perform optimally.
GitOps and Continuous Reconciliation: DevOps Patterns for Network Operations
The telecommunications industry has historically operated with very different practices than the software development world—change control processes measured in weeks, manual approval workflows, and risk-averse deployment practices. While these practices made sense for hardware-based networks where changes were expensive and risky, they become bottlenecks in cloud-native environments where agility is competitive advantage.
Figure 6: GitOps workflow enabling rapid, auditable network configuration changes
GitOps brings software development practices to network operations: all configuration changes are made through Git pull requests, enabling code review, automated testing, and rollback capabilities. But more importantly, it enables continuous reconciliation—the automation system continuously monitors the actual state of network infrastructure and automatically corrects any drift from the declared state in Git.
This approach is particularly powerful for managing configuration across large numbers of edge locations. Instead of manually synchronizing configuration changes across hundreds of sites, operators commit changes to Git and let the automation system handle propagation. The system can even handle partial failures gracefully—if a configuration update fails at one site due to network connectivity issues, it will automatically retry when connectivity is restored.
Data-Driven Operations: From Reactive to Predictive
Perhaps the most significant shift in network automation is the move from reactive operations (responding to problems after they occur) to predictive operations (preventing problems before they impact services). This requires treating operational data as a strategic asset and building automation systems that can learn from patterns in that data.
Figure 7: Evolution from reactive to predictive network operations through data-driven automation
ONAP’s closed-loop automation capabilities demonstrate this approach in practice. By collecting telemetry data through DCAE, analyzing it for patterns and anomalies, and feeding insights back to policy engines and orchestrators, the system can identify and address issues before they impact service quality. When DCAE detects that a network slice is approaching capacity limits, the system can automatically scale resources or distribute load to prevent service degradation.
The emergence of projects like Essedum, focused on AI frameworks for networking applications, suggests this trend will accelerate. As machine learning capabilities become more accessible and telecommunications-specific, we’ll see automation systems that can optimize network configurations, predict equipment failures, and even suggest architectural improvements based on learned patterns from operational data.
Standards Integration: Making Interoperability Actually Work
One of the most pragmatic aspects of modern network automation solutions is their approach to standards integration. Rather than creating entirely new standards, successful projects are finding ways to work with existing telecommunications standards while adding the automation layers that those standards often lack.
The key insight is that standards like 3GPP, ETSI NFV, and O-RAN define excellent functional interfaces, but they often don’t specify how those interfaces should be automated or orchestrated. Projects like Nephio bridge this gap by providing Kubernetes-native representations of telecommunications concepts while maintaining alignment with industry standards.
This approach allows operators to leverage their existing investments in standards-compliant equipment while gaining the automation capabilities they need for cloud-native operations. It’s a pragmatic compromise that recognizes both the value of industry standards and the need for operational innovation.
The Path to Production: Incremental Adoption Strategies
Perhaps the most important lesson from successful automation deployments is the value of incremental adoption. Rather than attempting to automate everything at once, successful operators start with specific, high-value use cases and gradually expand their automation capabilities.
This might mean starting with automated infrastructure provisioning while keeping network function configuration manual. Or beginning with monitoring and alerting automation while maintaining manual deployment processes. The key is building operational confidence and expertise gradually rather than attempting a “big bang” transformation.
The modular architecture of modern automation platforms makes this incremental approach possible. Operators can adopt individual components—a specialized controller here, a monitoring system there—and integrate them with existing processes and tools. As teams build confidence and expertise, they can expand automation to additional domains and use cases.
In our final post, we’ll examine real-world case studies and implementation results from operators who have successfully navigated these complex automation challenges. From Verizon’s custom OpenDaylight distribution to Samsung’s terabit-scale 5G UPF deployments, we’ll see how these solutions perform when they meet the harsh realities of production telecommunications networks
Featured Image Designed by Freepik