This article is based on remarks made by Gabriele Di Piazza, VP of Solutions for VMware Telco Cloud Edge, during a DSP Leaders Virtual Press Room briefing reported by TelecomTV.
NFV Has Laid the Groundwork for Cloud-Native Telecoms
Communications service providers (CSPs) have been building toward cloud-native architectures for years, and the foundation they are building on is Network Functions Virtualization (NFV). According to Gabriele Di Piazza, VP of Solutions for VMware Telco Cloud Edge, the journey began in earnest with 4G. “4G kickstarted the shift towards virtualization and gave the operators experience,” he explained. New additions and expansions in 4G networks have been running in virtualized or cloud-based environments, making a fully physical packet core largely obsolete for new deployments.
A prominent example is Vodafone, which had been on its virtualization journey for more than five years at the time of reporting. Working with VMware, it completed the roll-out of its NFV Infrastructure (NFVi) platform, supporting more than 900 virtual network functions (VNFs) across 21 markets. That scale of deployment represents the operational muscle CSPs have developed through NFV — muscle that now needs to flex in a very different direction.
The Jump from VNFs to CNFs Is Not a Simple Swap
The move from virtual network functions (VNFs) to cloud-native functions (CNFs) is frequently mischaracterized as a straightforward upgrade. Di Piazza pushed back on that assumption directly: “The transition from virtualized functions to cloud native has a lot of implications… as applications are disaggregated into microservices, for the first time in many years there’s a need for the complete re-architecting of applications — it’s not a case of ‘I had a VNF and now I have a CNF and the problem is solved.'”
This architectural shift carries significant operational consequences. Moving to containerized, microservices-based network functions means operators must adopt CI/CD (continuous integration/continuous delivery) pipelines and Platform-as-a-Service (PaaS) deployment models that are fundamentally different from how they managed monolithic VNFs. The transformation is not just technical — it runs across the entire supply chain and introduces a significant skills gap at the human level.
Three Stars Must Align for Cloud-Native Telecoms to Work
Di Piazza outlined three interdependent conditions that must all be in place simultaneously before telcos can operate cloud-native networks at production scale:
- Platform vendor maturity: Cloud infrastructure vendors — including VMware and its competitors — must deliver production-grade telco cloud platforms. Di Piazza was relatively confident here: “Sometimes I think this is the least of the problems because we are technology companies — this is what we do.”
- CNF readiness from network function vendors: The containerized versions of core network functions need to be production-ready. At the time of the briefing, Di Piazza was candid: “Today CNFs, the containerized functions, are either barely ready or still in the process of being released.” Significant R&D work remained before those functions would be fit for telco production environments.
- Carrier operational maturity: Operators themselves need to develop the Kubernetes expertise, CI/CD workflows, and cultural readiness to run cloud-native operations. This includes everything from retraining engineering staff to rethinking how software lifecycle management works at scale.
“If all three things are not in place at the same time — if you miss only one of those three — then you have a gap,” Di Piazza warned. He used a concrete illustration to convey the operational challenge: “Imagine deploying a network function continuously into tens of thousands of sites, updating these, maintaining a fresh version in a world where there is a new Kubernetes version every quarter” — that represents an entirely new operational paradigm for network engineers accustomed to long-lifecycle hardware and software deployments.
VMware’s Strategic Acquisitions Filled the Cloud-Native Gap
A few years prior to this briefing, VMware had limited credibility in the Kubernetes and cloud-native space. A series of acquisitions changed that trajectory. Di Piazza highlighted the purchases of Heptio (a Kubernetes-focused company co-founded by two of Kubernetes’ original creators), Pivotal Software (known for its Cloud Foundry PaaS platform), and Bitnami (an application packaging and deployment platform) as central to VMware’s cloud-native pivot.
“The transition towards the cloud native and containerized world matches really well with our recent acquisitions,” he said, adding that VMware was investing in automation, orchestration, and intelligence to build a more complete end-to-end portfolio. “Things are about to become way more complicated,” he acknowledged, positioning VMware’s portfolio evolution as a direct response to that increasing complexity.
VMware Telco Cloud Automation: From Project Maestro to GA
The product outcome of this portfolio evolution was VMware Telco Cloud Automation, previously known internally as Project Maestro. According to Di Piazza, it became generally available in February 2020. The platform is designed to address the orchestration and lifecycle management challenges that arise when deploying network functions not just in centralized data centers but across distributed edge locations — including central offices (near edge) and radio access network (RAN) sites (far edge).
“You have centralized sites and distributed sites, near edge in the central office or far edge all the way to the RAN, and with the RAN you have tens of thousands of endpoints — think about the impact that will have on orchestration and automation,” Di Piazza noted. Managing software lifecycle at that scale, with Kubernetes release cadence as a constant variable, is precisely the problem VMware’s telco cloud automation tooling aims to solve.
CSPs Are Becoming Their Own Systems Integrators
One of the more strategically significant observations from Di Piazza concerned the changing role of carriers themselves. Historically, CSPs relied heavily on large systems integrators to pull together complex network deployments. That model is shifting.
“The carriers are, de facto, becoming their own systems integrator as they undertake this digital transformation,” he said. “The network is at the heart of that transformation — this is their factory — and they are building those integration skills in-house.” This insourcing of integration capability is both a response to the complexity of cloud-native deployments and a strategic move to retain control over their most critical infrastructure.
Key Takeaways for DevOps and Platform Engineers in Telecoms
- NFV is the bridge, not the destination. Operators who invested in NFVi are better positioned for cloud-native, but the architectural assumptions are fundamentally different.
- CNF maturity was a real constraint in 2020. Platform readiness outpaced the readiness of the actual containerized network functions being deployed on it.
- Kubernetes operational skills are a critical bottleneck. The quarterly Kubernetes release cadence alone creates continuous operational pressure for teams unused to software-defined infrastructure.
- CI/CD isn’t optional for 5G core. Cloud-native 5G functions demand the same delivery automation that web-scale software companies use — applied to carrier-grade, highly available network infrastructure.
- Edge scale changes the orchestration problem entirely. Managing thousands of RAN edge sites is a qualitatively different problem from managing a handful of core data centers.
Image courtesy of VMware. Original reporting by TelecomTV.