The telecom industry’s path to cloud-nativeness has been long and paved with trial and error. Starting with vendor-specific hardware and dedicated appliances, network functions moved to virtual machines, evolved beyond monolithic applications, and ultimately became software-defined.
Because of this today’s networks behave much like a cloud application: they can be deployed, scaled, and managed dynamically. And this work gradually makes network engineers convert into cloud engineers.
Telecom operators have spent years modernizing their networks. The flexibility they’ve achieved opens the door to entirely new capabilities. But has cloud native actually simplified network operations – or merely shifted complexity elsewhere? In this article, we’ll explore both sides of the equation.
The Hidden Cost of Cloud-Native Telecom
Abundance of Moving Parts
As the infrastructure becomes programmable, orchestration itself turns into one of the operator’s greatest nightmares.
Even for organizations that already have strong cloud-native and Open RAN infrastructure assets, orchestration at the infrastructure level may still be fragmented. Kubernetes clusters, Open RAN components, virtual routers, cloud resources, telemetry streams and operational workflows all need to be coordinated to function as a single platform, and not a bunch of disparate services.
Every customer request or network change may trigger a chain of interactions between dozens of independent services. Provisioning a new connectivity service, for example, is no longer limited to configuring a network device. It may involve coordinating cloud resources, identity management, billing platforms, and network functions, all through APIs.
Someone – or something – must keep track of all these moving parts and make sure they work together.
Finding a Needle in a Haystack
Suppose you have several environments, each with around a hundred servers. Something breaks. A customer reports: “5G service is unavailable.” Thousands of alerts appear – but which one points to the root cause?
Anyone working in infrastructure knows this problem. Although cloud-native networks produce enormous amounts of telemetry data, they often provide little context. When a service degrades, operators can spend hours trying to determine the cause. Was it the network itself, the underlying cloud platform, or a dependency several layers away?
Conventional monitoring, which focuses on the health of individual devices, falls short when so many distributed components come into play. Operators don’t lack data – they lack the ability to connect the dots.
When Manual Outlives Itself
One of the biggest problems of manual workloads is that they don’t scale. Things that once worked for a handful of network devices are powerless in complex workflows, let alone cross-platform deployments.
Today enterprise networks may consist of hundreds of servers, all requiring continuous provisioning, policy enforcement, and software updates. At that scale, automation becomes a necessity rather than an option.
Attempting to manage these processes manually quickly becomes counterproductive and risky. It not only slows service delivery but also increases the likelihood of configuration errors and operational inconsistencies.
The Other Side of the Coin
And yet operators continue to embrace cloud-native telecom. Ironically, it is due to the same characteristics that make cloud-native infrastructure so challenging to operate. When viewed from a different angle, they become the enablers of its greatest strengths.
Buying Connectivity Like the Cloud
If it is possible to configure a cloud environment in minutes, why not do the same with a network? This idea underlies Network-as-a-Service (NaaS) – a cloud-like consumption model that allows enterprises to provision public and private connectivity in minutes through APIs and self-service portals.
Instead of purchasing and managing network infrastructure, customers consume connectivity much like they consume cloud services. They can provision connections on demand, scale bandwidth as business needs evolve, and pay only for the resources they use.
Configure Once, Deploy Many Times
Instead of configuring devices manually, the desired network configuration lives in code. This allows telecom operators to apply the principles of Infrastructure as Code (IaC) – one of the core DevOps practices and a foundation of cloud-native automation.
In practice, this means repeatable deployments and the ability to spin up new environments in minutes. Suppose a telecom operator wants to deploy the same edge infrastructure in 50 cities. Instead of engineers configuring every location manually, they apply a single infrastructure template. One change can then be rolled out consistently across every site.
Margin for the Unexpected
Once infrastructure becomes software-defined and orchestrated, it gains one of the cloud’s biggest advantages: elasticity. The system adapts to changing demand by increasing or reducing capacity.
Imagine a telecom operator during a major sporting event. Mobile traffic doubles. Instead of installing another physical gateway, Kubernetes scales network functions by launching more instances of the 5G Core service – before users can even notice.
The same mechanisms also improve resilience: if a container crashes, Kubernetes automatically starts a new one. If the underlying node fails, workloads are rescheduled to another healthy node.
Keeping Configuration Honest
With programmable infrastructure, the desired network state is defined in a configuration file – a canonical setup and the single source of truth for configuration management platforms. Tools such as Argo CD for Kubernetes or network orchestrators like Cisco NSO, continuously compare the running infrastructure with this intended state. If a deviation is detected, they either alert operators or automatically reconcile the infrastructure with the approved configuration.
Giving AI Context
Another advantage of a software-controlled network infrastructure may not be so obvious at first glance, yet it holds enormous potential – it makes the network AI-ready.
And this readiness goes far beyond deploying a chatbot or investing in GPUs. It operates at a much deeper level.
Cristian Vasquez, Cloud & Automation Architect at AT&T Mexico, argues that before AI can deliver meaningful value, it needs operational context. In networking, this starts with building a homogeneous environment – one that exposes consistent interfaces, generates standardized telemetry, and is managed through software.
How AI Can Make a Difference
What makes a software-defined infrastructure such an important prerequisite for AI? It is the foundation it provides for AI to operate atop as an intelligence layer.
With API-first networks, AI finally has something it can interact with – and that transforms it from a chatbot that merely answers questions into an operational assistant. Let’s look at how AI can support engineering decisions and provisioning workflows at the operational layer.
Telemetry Instead of a Crystal Ball
Clive Deakin, a Strategic Technology and Transformation Executive at Iron Mountain and PivotingCloud, sees one of AI’s greatest future opportunities in supporting operational decisions through inference – identifying patterns, anticipating demand, and recommending actions before capacity becomes an issue.
AI loves machine-readable data. A flood of operational data generated by cloud-native systems can quickly overwhelm human operators, but not the machines designed to process that kind of input. Telemetry gives you data. AI turns it into operational context and actionable insights.
By continuously analyzing data produced by the telecom infrastructure, AI can answer questions such as: Will this Kubernetes cluster have enough capacity for Black Friday? It can also make forward-looking predictions: If customer growth continues at the current rate, this cluster will require four additional worker nodes within the next three weeks.
Seeing the Whole Picture
While telemetry helps AI understand how the network behaves over time, topology gives it the structural context to know how every component relates to the others.
Imagine a large operator with hundreds of interconnected locations, each with its own bandwidth constraints, latency characteristics, and maintenance windows. The sheer number of interconnected components makes it difficult for people to understand the network as a whole. AI, however, thrives on this complexity. It can represent the infrastructure as a graph, where devices, links, services, and their relationships form a connected knowledge structure.
This graph model allows AI to understand dependencies and reason over more efficient solutions and possible shortages – all while presenting engineers with a unified view of the network.
Configuration Intelligence
Knowing the system’s underlying dependencies and relationships, AI can help engineers make better configuration decisions. It doesn’t replace existing configuration management tools – it adds an intelligence layer that recommends optimal settings.
The same contextual understanding enables AI to assess the impact of planned changes before they are deployed. Instead of manually tracing every dependency, an engineer may ask: If I upgrade this Kubernetes cluster, what will be affected? AI combines topology, dependencies, and configuration, and estimates which infrastructure components are likely to be affected.
Talking to Your Network
Enhanced with MCP and natural-language APIs, AI becomes an intermediary between operators and the network, enabling a human-like interaction model. Instead of navigating multiple management systems, your teams can interact with the network as naturally as speaking.
Suppose an engineer asks: Connect Customer A to Azure with redundant paths. AI converts this into a sequence of actions executed through API calls, IaC templates, and network orchestrators. It doesn’t configure routers directly – it pulls on the required strings to coordinate the involved systems.
The Future of AI-Driven Telecom Ecosystems
The capabilities described above are by no means an exhaustive list of what AI can do. If anything, they only scratch the surface. Clive puts it this way:
"AI is in the first five minutes after the Big Bang. We're incredibly early. Not early in adoption, but in discovering what's actually possible."
Yet even at this early stage, AI is already reshaping how telecom infrastructures are designed and operated. In particular, it enables the development of intelligent ecosystems in the intersection of connectivity, compute, and commerce.
This is the idea behind Marketplace 2.0 – a unified platform built to support the needs of cloud-native telecom providers. Instead of treating AI as another capability to bolt onto the platform, Marketplace 2.0 embeds it across every layer of the architecture.
The diagram below illustrates how AI contributes to each of the platform’s layers.
At the heart of this approach lies a programmable infrastructure. By exposing the network through standardized APIs, it becomes observable, automatable, and consumable by software – creating the context that AI needs to deliver operational value. |
Conclusion
The transition to cloud-native telecom enabled entirely new capabilities and solved many challenges of traditional network infrastructure – from dependence on proprietary hardware and manual configuration to the long gap between announcing a new service and delivering it to customers. That flexibility, however, has also made networks significantly more complex to operate.
Throughout this article, we’ve explored how programmable infrastructure creates the operational foundation for AI, and how this move changes the way telecom operators build, manage, and evolve their networks.
But AI is not where the journey begins. To turn AI into an operating leverage and a revenue enabler, the network itself has to be standardized enough to make this automation possible. Only then can AI become truly useful.
