Telco Cloud and the New Lock-In: From NFV to Kubernetes, the Edge, and Who Really Controls the Operator Stack

1. Software left the box. Control did not follow

In October 2012, a group of thirteen network operators published a short white paper that set the agenda of the industry for the next decade. The Network Functions Virtualisation introductory white paper argued that routers, firewalls, mobile cores and session border controllers should stop being proprietary appliances and become software running on industry-standard servers. The promise was explicit: lower equipment cost, faster service introduction and, above all, an open ecosystem in which operators would no longer be bound to the integrated hardware and software of a few equipment manufacturers.

Fourteen years later, most of the technical part of that promise has been kept. The mobile core of a modern operator runs as software on commodity servers. Voice, signalling, DNS, policy and subscriber databases have been virtualised or are being rewritten as containers. The 5G standalone core was designed from the start as a set of cloud-native services. New infrastructure is built with the same tools used by large internet companies: Linux, Kubernetes, declarative automation and continuous delivery.

The commercial part of the promise has not been kept, or at least not in the form expected. The dependency on equipment vendors has not disappeared; it has moved. It now sits in the cloud platform that hosts the network functions, in the certification of each function on a specific version of that platform, in the automation and management planes that operate it, and in the commercial terms of a handful of companies that have become the new control points of the operator stack: IBM through Red Hat, Broadcom through VMware, Oracle through signalling functions and database licences, the hyperscalers through hybrid cloud offerings that extend their management planes into operator data centres, and the network equipment vendors through their own container platforms.

The thesis of this article is that telco cloud has separated software from hardware, but not operators from their suppliers. The architecture choices made between 2024 and 2028 — which platform hosts the 5G core, how the edge is built, who runs the management plane, which automation framework is adopted — will fix the cost structure and the negotiating position of operators for the following decade. Those choices are being presented as technology decisions. They are, first, decisions about who controls the network.

Four claims follow from that thesis, and the rest of the article develops them.

• The generations of infrastructure overlap; they do not replace each other. Appliances, virtual machines, containers and converged platforms coexist in every large network in 2026, and the hardest engineering problem is running all of them together, not choosing the newest.
• Open source reduces licence lock-in but not the other forms of dependency. Certification, integration, automation, data, skills, contracts and exit cost can bind an operator to an open platform almost as firmly as to a proprietary one.
• The edge multiplies whatever is decided in the core. A platform chosen for three central data centres is an expensive commitment; the same platform replicated across hundreds of edge sites is a structural one.
• Control is preserved by architecture, contracts and in-house engineering, not by picking the right product. Every serious option on the market creates dependencies; the question is whether they remain reversible.

2. Four generations of network infrastructure

2.1 The appliance era: when the network was a set of boxes

Until the early 2010s, every network function was a physical product. A mobile switching centre, a packet gateway, a home location register, a broadband remote access server or a firewall was a chassis delivered by one vendor with its own hardware, operating system, management software and support contract. Many were built on specialised platforms such as ATCA (Advanced Telecommunications Computing Architecture), a carrier-grade blade standard, with custom line cards and network processors.

That model had real strengths, which explain why it lasted so long. The vendor was accountable for the whole box. Performance was predictable because hardware and software were designed together. Availability targets of five nines (99.999%, roughly five minutes of downtime per year) were engineered into the product, and the operator’s job was to dimension, configure and maintain it.

The weaknesses were economic and operational.

• Capacity was bought in boxes. Growth meant buying another chassis or another card, sized for the busy hour of the year, from the same vendor.
• Every function had its own silo. Each appliance came with its own element manager, its own spare parts, its own upgrade cycle and its own specialists.
• Innovation followed the vendor’s roadmap. A new service required the vendor to add a feature to the product, test it and release it, often over 12 to 24 months.
• Utilisation was low. Hardware dedicated to one function could not be reused by another when demand shifted.

In parallel, enterprise IT had already solved part of this problem. Server virtualisation, popularised by VMware in the 2000s, had shown that one physical server could host many isolated workloads, that workloads could be moved between servers and that capacity could be pooled. Operators ran their IT — billing, CRM, OSS — on that model long before they applied it to the network. That is one origin of the “two worlds” problem that still shapes operator infrastructure: an IT cloud built on enterprise virtualisation and a network built on appliances, managed by different teams with different suppliers.

2.2 The NFV bet: network functions as software

Network Functions Virtualisation (NFV) proposed to apply the IT model to the network. The 2012 white paper led to the creation of the ETSI Industry Specification Group for NFV, which in 2013 and 2014 published the reference framework that the industry still uses as its vocabulary, including the architectural framework (GS NFV 002) and the management and orchestration specification (GS NFV-MAN 001).

The framework separates three things that the appliance had fused.

• VNF (Virtualised Network Function). The network function as software — a virtual packet gateway, a virtual firewall, a virtual IMS node — running in one or more virtual machines.
• NFVI (NFV Infrastructure). The pool of compute, storage and network resources, plus the virtualisation layer, on which VNFs run.
• MANO (Management and Orchestration). The software that manages the lifecycle of all of the above, split into three functions:
• VIM (Virtualised Infrastructure Manager), which controls the NFVI resources; in practice, in most deployments, OpenStack.
• VNFM (VNF Manager), which instantiates, scales, heals and upgrades each VNF; usually supplied by the VNF vendor.
• NFVO (NFV Orchestrator), which composes VNFs into network services and coordinates resources across sites.

The economic logic was horizontal. If every VNF ran on the same NFVI, the operator could buy servers from one supplier, the virtualisation layer from another and network functions from many, and make them compete. The pool of servers would be shared across functions, raising utilisation. New functions could be deployed as software in weeks instead of months.

Large operators turned that logic into transformation programmes. AT&T launched its Domain 2.0 programme in 2013 with the goal of virtualising and software-controlling 75% of its network by 2020, and open-sourced its orchestration platform, ECOMP, which merged with the Open-O project in 2017 to form ONAP (Open Network Automation Platform) under the Linux Foundation. European incumbents launched similar programmes, generally with a central NFVI built on OpenStack.

2.3 What NFV actually delivered

NFV delivered the separation of software from hardware, but not the horizontal market it promised. Three patterns explain the gap, and all three still matter in 2026.

The first pattern was lift-and-shift. Many early VNFs were appliance software repackaged into virtual machines with minimal redesign. They kept their internal architecture, their proprietary redundancy mechanisms and their dimensioning rules; they simply moved from a chassis to a hypervisor. The result was sometimes called a “virtualised appliance”: the same product, on different hardware, often with worse performance per euro than the original.

The second pattern was vendor-specific NFVI. Because performance and support were hard to guarantee on an arbitrary infrastructure, network vendors sold their VNFs together with their own NFVI — typically their own OpenStack distribution, hardware recommendations and management tools. Many operators ended up with several NFVI “islands”, one per major network vendor, each with its own OpenStack, its own upgrade cycle and its own operations team. The horizontal pool became a set of vertical stacks.

The third pattern was operational complexity. OpenStack is a powerful but complex system, and operating it at carrier-grade availability required skills that most operators had to build or buy. Upgrading OpenStack under live network functions proved difficult; several operators stayed on old releases for years because the VNF vendor had certified a specific one.

The lesson, which the rest of this article returns to repeatedly, is that a standard architecture does not create interchangeable products by itself. ETSI defined the interfaces; the market built vertical integrations on top of them, because vertical integrations were easier to sell, support and hold accountable.

2.4 The cloud-native turn: containers, Kubernetes and the 5G core

From around 2018, the industry moved from virtual machines to containers. A container packages an application with its dependencies and runs it as an isolated process on a shared Linux kernel, without a full guest operating system. Containers start in seconds, use fewer resources than virtual machines and suit applications designed as many small, independent services (microservices).

Kubernetes became the standard way to run containers at scale. Google released it as open source in 2014, and it became the founding project of the Cloud Native Computing Foundation (CNCF) in 2015. Kubernetes schedules containers onto servers, restarts them when they fail, scales them with demand and continuously reconciles the actual state of the system with a declared desired state.

The 5G standalone core became one of the main catalysts for cloud-native network infrastructure. 3GPP Release 15 (2018) defined the 5G core as a Service-Based Architecture (SBA): a set of network functions — AMF for access and mobility, SMF for session management, UPF for the user plane, UDM and UDR for subscriber data, NRF as a registry, PCF for policy, among others — that expose services to each other over HTTP-based APIs. That design is well suited to microservices and containerised deployment, even though 3GPP does not prescribe Kubernetes, containers or any specific deployment technology; cloud-native implementation is an industry choice that the architecture favours. The network functions built this way are called CNFs (Cloud-native Network Functions).

The vocabulary changed accordingly. Where NFV spoke of NFVI and VIM, cloud-native networks speak of CaaS (Containers as a Service), the Kubernetes-based platform that hosts CNFs. The VNF manager was partly replaced by Kubernetes primitives — deployments, operators, Helm charts — and by vendor-specific lifecycle tools.

But the cloud-native turn did not remove the old world. 4G cores, IMS voice platforms, signalling routers and many IT systems still run as VNFs on OpenStack or VMware, and will for years. Operators found themselves running two infrastructures: one for virtual machines and one for containers.

Keeping a VNF is often a rational decision, not resistance to change. A stable VNF may be supported only in its current form, may not be fully amortised, may have no cloud-native replacement from its vendor, or may carry a migration risk that outweighs any saving. Retiring it early can destroy value; the question is how long it is worth keeping and on which infrastructure.

2.5 Convergence: one platform for VMs, containers, IT and network

The current generation tries to collapse those infrastructures into one. Three technical developments make that possible.

• Virtual machines inside Kubernetes. KubeVirt, a CNCF incubating project since 2022, lets Kubernetes run and manage virtual machines alongside containers. Commercial products such as Red Hat OpenShift Virtualization and SUSE Virtualization build on it.
• OpenStack hosted on Kubernetes. The OpenStack control plane can itself run as containers on a Kubernetes cluster, as in Red Hat OpenStack Services on OpenShift (RHOSO), generally available since August 2024, so that a single platform operates both the IaaS layer and the container layer.
• One platform for IT and network. The same Kubernetes distribution can host enterprise applications, OSS/BSS and network functions, with different tuning profiles per cluster. Convergence here means a common platform family, tooling and management model; it does not require running everything in a single cluster, and most operators keep separate clusters for security, performance or availability reasons (section 5.3).

Standards bodies followed the market. In January 2026 ETSI published GS NFV 008-1, the “Architectural Framework for Telco Cloud” of NFV Release 6 (ETSI explainer), a new architecture that reorganises the NFV framework into four building blocks: Telco Cloud Infrastructure (TCI), Telco Cloud Platform (TCP), Telco Cloud Applications (TCA) and Telco Cloud Orchestration (TCO). It treats virtual machines and containers as two forms of the same infrastructure, adds common platform services for lifecycle, configuration, telemetry and security, and introduces the Telco Cloud Connectivity Graph to model how applications and components are connected across domains.

The architectural direction is sound, and it is worth stating its limit early. The 2014 framework also separated infrastructure, functions and orchestration cleanly, and the market still produced vertical stacks. A better reference architecture makes interoperability possible; it does not make it happen. That depends on how operators buy, certify and contract — which is where most of this article will end up.

The convergence generation is also the one in which the platform becomes the strategic asset. When one platform family hosts the IT estate, the network core and the edge, the supplier of that platform holds a position no single network vendor held in the appliance era. Section 7 returns to that point.

3. The vocabulary, explained

Most confusion in telco cloud discussions comes from treating different layers as alternatives. OpenStack, Kubernetes and OpenShift are frequently compared as if they did the same job. They do not. This section explains each technology, what it is for and where it sits, before section 4 maps the products.

3.1 Virtual machines, hypervisors and containers

A virtual machine (VM) is a set of virtualised hardware resources running its own operating system. The VM sees virtual processors, memory, disks and network cards, has its own operating system (the guest OS), runs on a hypervisor that shares the physical server among several VMs, and is strongly isolated from its neighbours. The two hypervisors that matter in telco are KVM (Kernel-based Virtual Machine), built into Linux and used by OpenStack and KubeVirt, and VMware ESXi, the core of VMware’s platform.

A container is an isolated process that shares the host’s operating system kernel. It carries its own libraries and binaries but no guest OS, so it is lighter and faster to start than a VM. The trade-off is weaker isolation and a dependency on the host kernel — which matters for network functions that rely on specific kernel features or drivers.

The choice between the two is driven by the workload, not by fashion. A legacy VNF designed as a VM image will run as a VM for its remaining life; rewriting it as containers rarely pays. A 5G core function designed as microservices should run as containers. A platform that can host both — the convergence model of section 2.5 — avoids running two infrastructures for the transition.

3.2 OpenStack: the virtual data centre

OpenStack is an open-source platform that turns a set of physical servers into a virtual data centre. It was launched in 2010 by Rackspace and NASA and is governed today by the OpenInfra Foundation, which became part of the Linux Foundation in 2025. It is an Infrastructure as a Service (IaaS) layer: it gives users virtual machines, virtual networks and storage on demand, through APIs.

It is a collection of services, each with a project name that appears constantly in telco documents.

• Nova — compute: creates and manages virtual machines.
• Neutron — networking: virtual networks, subnets, routers and ports, including the high-performance options used by VNFs.
• Cinder — block storage, the virtual disks attached to VMs.
• Glance — the image catalogue from which VMs are created.
• Keystone — identity and access control.
• Heat — templates that describe a set of resources to be created together.
• Ironic — provisioning of physical (bare-metal) servers through the same APIs.
• Octavia, Swift, Placement — load balancing, object storage and resource tracking, among others.

In NFV, OpenStack plays the role of the VIM. It is the layer that receives requests such as “create three VMs with these CPU, memory and network characteristics on servers in this site” and turns them into running resources. Its strength is maturity for VM workloads and a rich networking model; its weakness is operational complexity and difficult upgrades.

OpenStack is not disappearing. The OpenInfra community estimated in October 2025 that OpenStack deployments exceed 55 million cores in production worldwide, up from about 45 million in the previous survey, across all sectors — not only telecoms. For operators, it remains the natural home of VNFs that will not be rewritten, and it is increasingly used as one of the infrastructure options beneath Kubernetes clusters.

3.3 Kubernetes: the orchestrator of containers

Kubernetes decides where and how containers run, and keeps them running. The user declares a desired state — “five replicas of this service, with this configuration, reachable on this address” — and Kubernetes continuously works to make reality match it, restarting failed containers, rescheduling them when a server dies and scaling them with load.

A few concepts recur in every telco cloud discussion.

• Cluster, node and pod. A cluster is a set of servers (nodes) managed by one Kubernetes control plane; a pod is the smallest deployable unit, one or more containers that share network and storage.
• Operator. A piece of software that encodes the operational knowledge of an application — install, upgrade, back up, recover — and runs it automatically inside Kubernetes. Not to be confused with a network operator.
• Helm chart. A package format that describes how to deploy an application on Kubernetes; most CNFs are delivered as Helm charts or operators.
• CNI (Container Network Interface). The plug-in model that connects pods to networks. Telco CNFs typically need several networks per pod, which requires additional plug-ins such as Multus.
• CSI (Container Storage Interface). The equivalent plug-in model for storage.
• Custom Resource Definitions (CRDs). Extensions of the Kubernetes API. Many platform features — and many platform dependencies — are implemented as CRDs.

Kubernetes on its own is not a telco platform. It is an engine. To host a 5G core in production, an operator also needs an installer, a supported operating system, upgrade tooling, high-performance networking, security hardening, monitoring, multi-cluster management, certificate management and a vendor or team that answers the phone at 3 a.m. That gap is what Kubernetes distributions and platforms fill — and where most of the commercial value now sits.

3.4 OpenShift, OKD and the enterprise distributions

Red Hat OpenShift is Kubernetes packaged as a supported enterprise platform. It bundles Kubernetes with Red Hat Enterprise Linux CoreOS (an immutable operating system for the nodes), an installer, automated upgrades, an operator catalogue, security policies, networking, a container registry, monitoring and developer tools, all supported by Red Hat, which IBM acquired in 2019 for about USD 34 billion. Its community upstream is OKD.

Three extensions of OpenShift matter particularly for operators.

• OpenShift Virtualization runs virtual machines inside OpenShift using KubeVirt. It is the route to manage VMs and containers from one control plane. It does not, by itself, provide the full set of OpenStack IaaS services (multi-tenant networking model, quotas, the OpenStack APIs many VNF managers expect).
• Red Hat OpenStack Services on OpenShift (RHOSO) keeps OpenStack’s IaaS capabilities but runs its control plane as containers on OpenShift, with the data plane on RHEL compute nodes. It is aimed at operators with large VNF estates that depend on OpenStack APIs. Red Hat documents NFV features for it such as SR-IOV, DPDK, CPU pinning and huge pages, and publishes performance validations of OpenShift for telco core profiles — the January 2026 test of OpenShift 4.20 measured the default OVN-Kubernetes network reaching 88–89% of theoretical throughput on 25 GbE cards, falling to 81% under heavy churn.
• Advanced Cluster Management and GitOps tooling to deploy and govern hundreds of clusters, including at edge sites.

OpenShift Virtualization and RHOSO are two architecturally different answers to the same problem. The first brings VMs into Kubernetes and manages them as Kubernetes resources; the second keeps OpenStack and its APIs, and only moves the OpenStack control plane onto OpenShift, while the VMs run on separate RHEL compute nodes. The choice depends on whether existing VNFs and their managers need OpenStack APIs.

OpenShift is one of several enterprise Kubernetes platforms competing for the operator stack. The others include SUSE Rancher (with the RKE2 distribution), Canonical Kubernetes, Wind River Cloud Platform (based on the open-source StarlingX project), VMware’s Kubernetes offerings, the network vendors’ own CaaS products and the managed Kubernetes services of the hyperscalers. Section 4 maps them.

3.5 Three ways to deploy a network function

Before the vocabulary, the architectures. Most confusion disappears once three deployment models are distinguished explicitly.

Model	Network function	Runs in	Managed by	Runs on
A. Traditional NFV	VNF	Virtual machines	OpenStack (or VMware) with KVM (or ESXi)	Physical servers
B. Cloud-native	CNF	Containers	Kubernetes or a distribution such as OpenShift	Physical servers or virtual machines
C1. Converged with KubeVirt	VNF and CNF side by side	VMs and containers on the same cluster	Kubernetes / OpenShift Virtualization	Physical servers
C2. Converged with OpenStack on OpenShift	VNF on OpenStack; CNF on OpenShift	VMs on RHEL compute nodes; containers on OpenShift	OpenStack control plane hosted on OpenShift (RHOSO)	Physical servers

3.6 The NFV and cloud-native acronyms, side by side

The same functional roles exist in the VM world and in the container world, under different names.

Role	VM / NFV world	Container / cloud-native world	What it does
The network function	VNF	CNF	The 5G core, IMS, firewall or DNS function as software
The infrastructure that hosts it	NFVI	CaaS (Kubernetes platform)	Compute, storage, network and the virtualisation or container layer
The infrastructure manager	VIM (usually OpenStack)	Kubernetes control plane / cluster manager	Allocates resources to functions
The function lifecycle manager	VNFM	Kubernetes operators, Helm, vendor CNF managers	Deploys, scales, heals and upgrades a function
The service orchestrator	NFVO	Service orchestrators, intent-based or GitOps controllers	Composes functions into end-to-end services
Bare-metal provisioning	Ironic, vendor tools	Metal3, Cluster API, vendor ZTP tools	Turns a racked server into a ready node

3.7 What makes a platform “telco-grade”

A network function is not a web application. A user plane function (UPF) forwards tens or hundreds of gigabits per second of subscriber traffic with tight latency and jitter targets; a virtualised radio distributed unit (O-DU) processes radio signals under real-time deadlines measured in microseconds. A generic Kubernetes cluster, tuned for web services, cannot meet those targets. A set of techniques closes the gap.

• DPDK (Data Plane Development Kit). A set of libraries that lets an application process packets in user space, polling the network card directly instead of going through the kernel network stack. It is widely used in software UPFs and virtual routers, alongside other approaches such as eBPF/XDP fast paths and hardware offload to SmartNICs.
• SR-IOV (Single Root I/O Virtualisation). A feature of network cards that splits one physical port into many virtual functions, each attached directly to a VM or pod, bypassing the virtual switch. It gives near line-rate performance at the cost of tying the workload to specific hardware.
• NUMA awareness. In multi-socket servers, each processor has its own local memory and devices (a NUMA node). Placing a function’s cores, memory and network card on the same node avoids costly cross-socket traffic.
• CPU pinning and isolation. Dedicating specific cores to a function so that other workloads — and the operating system itself — do not interrupt it.
• Huge pages. Using large memory pages to reduce the overhead of address translation for packet-processing applications.
• PTP (Precision Time Protocol, IEEE 1588). Distributing time with sub-microsecond accuracy, required by radio functions and some transport features.
• Multus and secondary networks. Giving a pod several network interfaces — signalling, user plane, management — as network functions require, instead of the single interface of standard Kubernetes.
• Hardware acceleration. SmartNICs, DPUs and accelerator cards for functions such as forward error correction in vRAN or encryption.
• Real-time kernels and low-latency profiles. Operating system configurations that bound the time between an event and the response to it.

Not every function needs all of this. Control-plane functions such as AMF and SMF are closer to demanding enterprise applications: they need resilience, state management and controlled scaling more than raw packet performance. The UPF needs the full packet-processing toolkit. vRAN needs everything, plus accelerators and precise timing. OSS and BSS are essentially enterprise applications.

This is where the first and most underestimated source of lock-in appears. Every one of these techniques depends on a specific combination of network card, driver, firmware, kernel version, Kubernetes version and plug-in. A CNF tested and supported on one such combination is not automatically supported on another, even if both are “Kubernetes”. The phrase that summarises the problem: a CNF that runs on Kubernetes is not a CNF that runs on any Kubernetes. Section 7 develops the consequences.

3.8 Bare metal, GitOps and zero-touch provisioning

Cloud-native telco platforms increasingly run Kubernetes directly on physical servers, without a hypervisor underneath. Bare-metal Kubernetes removes a layer of overhead and licensing, which matters for packet-processing functions and at edge sites with only a few servers. It also means the platform must provision and manage the physical servers itself.

• Bare-metal provisioning. Tools such as OpenStack Ironic, Metal3 (which brings Ironic into Kubernetes) and Canonical MAAS discover servers, configure firmware and install the operating system automatically.
• Cluster API. A Kubernetes project that manages Kubernetes clusters themselves as declarative resources — creating, upgrading and deleting clusters the way Kubernetes manages pods.
• GitOps. The practice of storing the desired configuration of infrastructure and applications in a Git repository and letting controllers such as Argo CD or Flux reconcile the live system with it continuously. Every change becomes a reviewed commit with history. Reverting configuration is then straightforward, although a safe rollback of a stateful network function still has to be designed and tested.
• ZTP (Zero-Touch Provisioning). Bringing a new site into service — server, operating system, cluster, network functions — from configuration in Git, without on-site engineering beyond racking and cabling. It is a precondition for operating hundreds of edge sites.

3.9 Orchestration: ONAP, OSM, Nephio and O-RAN

Above the infrastructure, operators need to deploy and change network services that span many functions, vendors and sites. That is the orchestration layer, and it has its own set of frameworks.

• ETSI NFV-MANO — the reference architecture for lifecycle management, now being extended with cloud-native and declarative principles.
• ETSI OSM (Open Source MANO) — an open-source implementation of the NFV orchestrator and VNF manager roles.
• ONAP — the Linux Foundation automation platform born from AT&T’s ECOMP. Ambitious and comprehensive; its complexity limited adoption, and many operators use only selected components.
• Nephio — a Linux Foundation project launched in 2022 with seed code from Google Cloud, with its first release in August 2023, that applies Kubernetes-style declarative automation and GitOps to network functions and their infrastructure across many sites.
• O-RAN SMO and O-Cloud — in the O-RAN architecture, the Service Management and Orchestration framework manages the radio network and the cloud infrastructure that hosts virtualised RAN (the O-Cloud) through the O2 interface.
• Infrastructure as code — Ansible, Terraform and its open-source fork OpenTofu, used to automate configuration and resource creation.

Orchestration is a second, separate lock-in battle. An operator can choose a horizontal infrastructure and still depend on one vendor’s orchestrator to deploy, upgrade and recover its network functions. Section 7 covers that risk.

3.10 Industry frameworks: Anuket, CNCF telco work and Sylva

Several industry initiatives try to reduce the fragmentation of telco cloud platforms. The main ones differ in scope.

• Anuket — a Linux Foundation project created in January 2021 by merging OPNFV and the operator-led CNTT reference model work. It publishes reference models, architectures and conformance tests for VM-based and Kubernetes-based telco infrastructure.
• CNCF telecom work — groups and test suites aimed at defining cloud-native best practices for network functions.
• Sylva — a Linux Foundation Europe project launched in November 2022 by European operators and vendors to build a common, open telco cloud framework and a shared validation programme, to reduce the repeated testing of each network function on each operator’s platform. Shared validation lowers the cost of portability; it does not guarantee that a validated function runs on every compliant platform without further testing. Section 9 analyses its maturity.

4. The telco cloud stack in 2026, and who sells each layer

A complete telco cloud is not one product but a stack of layers, each of which can be bought separately or as part of a bundle. Describing it layer by layer is the only way to see where a supplier is offering value and where it is accumulating control.

4.1 Six technical layers and one transversal layer

Layer	What it solves	Typical technologies and suppliers
6. Network functions and services	5G core, IMS, voice, signalling, subscriber data, DNS, RAN, OSS	Ericsson, Nokia, Samsung, Mavenir, Oracle, Huawei, ZTE, specialised vendors
5. Service and function orchestration	Deployment, scaling, upgrades and configuration end to end	ETSI OSM, ONAP, Nephio, vendor orchestrators
4. Cloud-native platform	Container management, security, automation and lifecycle	Kubernetes, OpenShift, SUSE Rancher, Canonical Kubernetes, Wind River, vendor CaaS
3. Virtualised infrastructure	VM management and IaaS services	OpenStack, VMware, KubeVirt
2. Operating system and hypervisor	Control and abstraction of the servers	RHEL, Ubuntu, SUSE Linux, KVM, ESXi
1. Hardware and connectivity	Compute, storage, networking and acceleration	Dell, HPE, Lenovo, Supermicro, Intel, AMD, NVIDIA, NIC and switch vendors
Transversal: governance and assurance	Inventory, configuration, observability, security, quality and cost	GitOps, infrastructure as code, OpenTelemetry, Prometheus, OSS and assurance tools

The commercial battle has moved to layers 3 to 5. Hardware (layer 1) is largely commoditised and multi-sourced. Network functions (layer 6) remain a concentrated market, but operators have decades of experience negotiating with network vendors. The middle of the stack is new territory: it determines which functions can be deployed, how upgrades happen, how sites are automated and which tools see the data. Whoever supplies it becomes the operator’s most structural supplier.

4.2 The ecosystems competing for the middle of the stack

Seven groups of product suppliers compete, collaborate and overlap in the middle of the stack, and a less visible group — the integrators — often decides how their products are combined. Each has a distinct value proposition and a distinct form of dependency.

Red Hat (IBM): convergence of IT and network

Red Hat offers the broadest single platform for both IT and network workloads. Its portfolio covers RHEL, OpenShift, OpenShift Virtualization, OpenStack Services on OpenShift, Ansible automation and multi-cluster management. Its pitch is one supported base for enterprise applications, CNFs and VNFs, with an ecosystem of certified network functions. Nokia, since a 2023 partnership, uses Red Hat as its primary reference platform for developing, testing and delivering a range of cloud-native network functions, and Red Hat took over evolution and support for Nokia’s own container platform. Several large operators have chosen OpenShift as their common platform for IT and network (sections 8 and 9).

Strength: integration, enterprise support and a broad base of certified functions. Dependency: the deeper an operator uses Red Hat-specific operators, tooling and subscriptions, the more expensive it becomes to replace the platform — even though the underlying components are open source. OpenShift subscriptions are counted per core pair or per bare-metal node, depending on the model, so cost grows with capacity, not with revenue.

VMware (Broadcom): integrated virtualisation and telco cloud

VMware brought the dominant enterprise virtualisation platform into telco. Its Telco Cloud Platform, built on VMware Cloud Foundation, combines virtualisation, software-defined networking and storage, Kubernetes and ETSI-aligned orchestration for VNFs and CNFs; Broadcom still sells it, and previewed version 9 on VCF 9 in March 2026. Many operators run their IT estate, and some run network functions, on VMware.

Strength: operational maturity and integration of compute, network and storage. Dependency: once compute, networking (NSX), storage (vSAN) and management are all VMware, the platform is efficient but very hard to negotiate at renewal. Broadcom’s acquisition of VMware in November 2023, and the licensing changes that followed, turned that theoretical risk into a practical one (section 7.3).

SUSE: Kubernetes-centred, edge and Sylva

SUSE focuses on Kubernetes and distributed infrastructure. Its portfolio — Rancher Prime for multi-cluster management, the RKE2 distribution, SUSE Linux and its telco cloud offering, the evolution of SUSE Edge for Telco — emphasises GitOps, large-scale edge automation and modularity. SUSE is an active participant in Sylva, and Orange’s telco cloud uses SUSE components in a Sylva-aligned architecture.

Strength: modularity and alignment with open frameworks. Dependency: the commercial support relationship and the integration effort the operator takes on.

Canonical: the modular, Ubuntu-based option

Canonical combines Ubuntu, MAAS for bare metal, OpenStack, Kubernetes and Juju for automation. Its reference architecture lets an operator assemble the stack from open components with commercial support, rather than buy a single integrated product.

Strength: modularity and cost control. Dependency: lower on the supplier, higher on the operator’s own integration and operations capability — or on the integrator hired to provide it.

Wind River and StarlingX: the distributed edge

Wind River Cloud Platform, based on the open-source StarlingX project, targets geographically distributed infrastructure. It combines Kubernetes (and historically OpenStack) with low-latency and real-time features and the automation needed for thousands of small sites, which makes it a frequent choice for vRAN. Boost Mobile announced in December 2024 that it was moving its core-to-edge CaaS infrastructure from VMware to Wind River — one of the few public examples of an operator replacing a cloud platform in production.

Strength: far-edge and RAN focus. Dependency: a specialised platform and ecosystem.

The network vendors: function and platform together

Ericsson and other network vendors sell the platform as well as the functions. Ericsson’s Cloud Native Infrastructure Solution (CNIS) is a bare-metal Kubernetes platform pre-integrated with its network functions; Ericsson’s own figures illustrate how hard such numbers are to read: in March 2025 it wrote of CNIS deployed “across more than 400 data centers” and claimed a 15–20% TCO improvement for bare metal over virtualised infrastructure; in February 2026 it cited more than 120 commercial CNIS contracts, over 50 live customer deployments and certified components in more than 250 data centres. Both are vendor figures with different definitions, and neither should be used as a planning assumption. Huawei and ZTE offer similarly integrated stacks in the markets where they operate. Nokia, by contrast, has moved its platform strategy onto Red Hat.

Strength: one accountable supplier for function and platform. Dependency: vertical coupling, which removes much of the competition that disaggregation was supposed to create.

The hyperscalers: public cloud inside the operator network

AWS, Microsoft and Google now offer infrastructure that runs in the operator’s own premises but is managed through their clouds.

• AWS Outposts extends AWS infrastructure and services into the operator’s data centre. The local hardware runs workloads, but AWS documents the service link to the parent region as “a necessary connection” that “allows for the management of the Outposts”.
• Microsoft Azure Operator Nexus is a hybrid, carrier-grade platform for network functions, born from the network cloud Microsoft acquired from AT&T in 2021. Microsoft documents that “the service that manages the Azure Operator Nexus infrastructure is hosted in Azure”, reached over ExpressRoute.
• Google Distributed Cloud offers connected, air-gapped and software-only variants on operator or Google-supplied hardware; the degree of autonomy varies materially between them; the connected edge variant is “managed centrally through Google Cloud”.

Strength: cloud-scale engineering, automation and services, and a reduced operational burden for the operator. Dependency: on the hyperscaler’s APIs, management plane, services, policies and release cycles. The servers may sit in the operator’s building while the control of the platform does not.

Sylva: a framework, not a product

Sylva is different in nature from the other six. It is not a commercial platform but an open framework, a reference implementation and a validation programme, hosted by Linux Foundation Europe and backed by several of Europe’s largest operators and vendors. Its goal is to reduce the repeated validation of each network function on each operator’s platform, so that functions validated against shared requirements can move between compliant platforms with less additional testing. Section 9 analyses where it stands.

Integrators and managed-service operators: the often invisible layer

For a large operator, the integrator of the platform can matter as much as the supplier of the product. Three roles should be distinguished, because each introduces a different dependency.

• Product supplier. Develops and supports the software or hardware: Red Hat, Broadcom, SUSE, Canonical, Wind River, a network vendor or a hyperscaler.
• Infrastructure integrator. Designs, builds and validates the platform for the operator: global system integrators, the professional services arms of network vendors and specialised cloud-native firms. It typically writes the deployment pipelines, the configuration and the test suites.
• Managed-service operator. Runs the platform day to day under a service contract, sometimes the same company as the integrator.

Sometimes the three roles coincide; often they are three different companies. An operator can choose an open product and still depend on an integrator whose pipelines, tooling and people are the only ones that know how its platform was built. Section 7 returns to that point.

4.3 The ecosystems grouped by the decision they answer

The ecosystems above do not compete for exactly the same thing. Comparing OpenStack, OpenShift, Azure Operator Nexus and Sylva in one list is useful as a map but misleading as a product comparison. Grouping them by the decision they answer is clearer.

Group	Technologies and suppliers	Main decision
IaaS and virtualisation	OpenStack (several distributions), VMware, KubeVirt-based virtualisation	How VMs are run and managed
Kubernetes platforms	OpenShift, SUSE Rancher / RKE2, Canonical Kubernetes, Wind River, Ericsson CNIS and other vendor CaaS	How CNFs are run and operated
Managed hybrid cloud	Azure Operator Nexus, AWS Outposts, Google Distributed Cloud	How much of the management is delegated, and to whom
Standards and validation	ETSI NFV, CNCF, Anuket, Sylva	How compatibility and portability are verified

Within each group, the trade-offs differ. The matrix below is a qualitative assessment by TelcoCrux, not a benchmark result.

Option	Value proposition	Main limitation or trade-off
OpenStack + upstream Kubernetes	Flexibility and architectural control	High integration and operations effort
Red Hat OpenShift + RHOSO	IT/network convergence, enterprise support, certified ecosystem	Dependency on Red Hat versions, subscriptions and tooling
VMware Telco Cloud	Integration and continuity for VNF and CNF estates	Commercial and technical dependency on the full VMware stack
SUSE Rancher / RKE2	Distributed Kubernetes, modularity, Sylva alignment	Integration complexity; dependency on chosen support
Canonical OpenStack / Kubernetes	Modular open infrastructure at controlled cost	Requires strong in-house engineering and validation
Wind River / StarlingX	Far edge, RAN and multi-site automation	Specialised solution and ecosystem
Ericsson CNIS and other vendor CaaS	Tight integration with the vendor’s functions	Vertical coupling to one network vendor
Azure Operator Nexus / AWS Outposts / Google Distributed Cloud	Cloud-managed operations on operator premises	Dependency on the hyperscaler’s services and management plane, varying by offer and mode
Sylva	Common reference and multi-vendor validation	A framework, not a complete commercial product

The workload should drive the shortlist.

• Legacy VNFs: OpenStack, VMware, or virtualisation on Kubernetes once validated by the VNF vendor.
• Cloud-native 5G core: telco-grade Kubernetes — enterprise platforms or Sylva-validated distributions.
• Distributed RAN: bare-metal Kubernetes with real-time and timing support, meeting O-RAN O-Cloud requirements.
• OSS/BSS: enterprise Kubernetes, private or public cloud depending on latency, data and resilience requirements.
• Edge workloads: edge Kubernetes, managed offers or modular infrastructure, depending on the autonomy required.

5. What an operator’s network looks like today

The network of a large converged operator in 2026 is a stratified system. It contains equipment from the 1990s, VNFs from the 2010s, CNFs from the 2020s and the first converged platforms, all carrying live traffic. Understanding the telco cloud debate requires understanding what has to run on it.

5.1 The workloads that need a home

A mobile and fixed operator runs, at minimum, the following classes of workload. Each has different requirements, which is why a single answer rarely fits all of them.

• Radio access network (RAN). Mostly purpose-built baseband hardware, with virtualised and Open RAN deployments growing but still a minority.
• Fixed access and aggregation. Fibre access equipment and broadband network gateways (BNG), increasingly virtualised or disaggregated.
• IP transport. Still overwhelmingly on physical routers.
• Mobile packet core. The 4G EPC, typically as VNFs, and the 5G standalone core, typically as CNFs.
• Voice. Legacy circuit-switched platforms being retired, and IMS for VoLTE, VoWiFi and VoNR.
• Signalling. Diameter routing for 4G and the 5G signalling functions NRF, SCP and SEPP.
• Subscriber data. HLR, HSS, UDM and UDR, among the most critical systems in the network.
• Network services. DNS, AAA, policy servers and firewalls.
• IT, OSS and BSS. Billing, CRM, ordering, provisioning, inventory, assurance and data platforms.

5.2 How the infrastructure islands formed

In many large operators, those workloads run on several infrastructures that share little. The pattern is common across the industry.

• Vendor NFVI islands. An OpenStack-based NFVI per major network vendor, each hosting that vendor’s VNFs, with its own release cycle, tools and team.
• Vendor CaaS islands. The same pattern repeated for CNFs.
• An IT private cloud. Often VMware-based, hosting enterprise applications, OSS and BSS.
• Public cloud regions. For new IT workloads, analytics and AI, under a separate governance model.

Each island was a rational decision when it was taken. The vendor guaranteed performance and support for its function on its own platform; the IT team optimised for enterprise workloads; the cloud team optimised for speed. The sum is an estate with several upgrade cycles, skill sets, support contracts and security models, and low utilisation of each pool.

5.3 Four architectural responses

Operators are responding to the islands in different ways, and there is no single roadmap. Four models can be observed in public announcements across the industry; many operators combine more than one.

Model	What it means	Typical rationale	Main risk
Converged horizontal platform	One platform family for most IT and network workloads, VMs and containers	Simplification, shared skills, higher utilisation	Concentration in one platform supplier
Specialised platforms by domain	Different platforms for core, RAN, IT and edge, chosen per workload	Best fit for demanding workloads	Fragmented operations and governance
Vendor-integrated stacks	Network functions delivered with the vendor’s own platform	One accountable supplier, fast integration	Vertical coupling, little competition
Hybrid with public cloud	Private telco cloud combined with hyperscaler regions or on-premises hyperscaler offers	Speed, elasticity, access to cloud services	Dependency on external management planes and services

Convergence does not have to mean a single cluster. It can happen at the level of the management model, the automation tooling, the operating system or the platform family, while infrastructures remain separate for reasons of security, performance or availability. A converged operator may still run separate clusters for the user plane, the control plane, IT and edge sites — on the same technology and under the same governance.

Whatever the model, migrations of core, voice, signalling and subscriber-data workloads are multi-year programmes on critical systems. Two consequences follow. The platform chosen to host them will be in service for at least a decade. And a horizontal platform only delivers its value if the functions moved onto it are certified on it — which gives the platform supplier and the function vendors considerable leverage over the timetable. That leverage is the subject of section 7, after a short look at the edge.

6. The edge: where platform decisions are multiplied

Edge computing matters to this article for one reason: it multiplies whatever platform decision is taken in the core. A platform chosen for three central data centres is a significant commitment; the same platform deployed across tens or hundreds of remote sites becomes part of the physical network.

6.1 Five tiers, not one “edge”

“Edge” is used for several different tiers, and confusing them produces most of the inflated expectations. The useful definition is positional: the edge is any compute placed closer to the customer than the operator’s central data centres. Five tiers can be distinguished.

• Far edge: cell sites and hub sites. Thousands of locations with a few servers at most; the home of virtualised RAN distributed units (O-DU), which need real-time processing, precise timing and hardware acceleration.
• Near edge: central offices and aggregation sites. Tens to a few hundred locations per country, with power, space and fibre already in place; candidates for user-plane functions with local breakout, centralised RAN units, CDN caches, broadband gateways and multi-access edge computing (MEC) applications.
• Regional data centres. A handful to a few dozen sites hosting core control-plane functions, voice platforms and regional IT.
• Central data centres. Two to four large sites per country for OSS, BSS, data platforms and AI training.
• Public cloud regions. Shared hyperscaler capacity for IT, analytics and burst workloads.

Physics sets the boundaries. Light in optical fibre travels at roughly 200,000 km/s, about 1 millisecond of round-trip time per 100 km before processing or queuing. In most European countries, a regional data centre is already within 5–15 ms of most users. The workloads that genuinely need the near or far edge are those that need single-digit milliseconds, those that move very large volumes of local data, and those that must stay on a specific site for regulatory reasons.

6.2 Why operators build it, and why it rarely pays on its own

Operators build edge capacity mainly for their own network functions. User-plane functions placed closer to users, centralised and virtualised RAN, CDN caches and virtualised broadband gateways can reduce transport cost and latency. Sovereign and regulated workloads for public-sector and industrial customers are a second, emerging driver, supported in Europe by public programmes such as the Important Project of Common European Interest on cloud infrastructure and services (IPCEI-CIS), approved in December 2023 with up to EUR 1.2 billion of public aid. Low-latency services and AI inference for enterprises are the most marketed driver and the least proven commercially.

Enterprise edge demand has repeatedly disappointed. Dell’Oro said in May 2023 that the MEC market had “failed to materialize” and cut its five-year MEC investment forecast by about 39%; Omdia forecasts about USD 7 billion of telco edge infrastructure spend by 2032. The AI inference argument, amplified by vendor initiatives such as NVIDIA’s “AI grids”, has not yet produced public evidence of large edge revenues. The structural reasons are the same as a decade ago: few applications need single-digit latency, utilisation per site is low, operating effort grows with the number of sites rather than with capacity, and enterprise developers build on hyperscaler platforms.

Even the network-function case has to be proven site by site. Placing a user-plane function or a cache in a central office is justified only when the savings in transport, and the performance gained, exceed the cost of space, power, hardware, support, renewal and remote operations for that site. Many sites will pass that test; not all will. The TelcoCrux position is to build edge capacity where the operator’s own functions justify it, and to treat enterprise and sovereign workloads as incremental demand on that footprint rather than as the business case for it.

6.3 Why the edge is where lock-in becomes structural

Every dependency described in section 7 is multiplied at the edge. Three effects make it so.

• Replication. A platform deployed in two hundred sites, each with its own hardware and local functions, cannot be replaced in one planned programme; it is replaced site by site, over years.
• Remote management. Edge sites are operated remotely by definition. If the management plane belongs to a hyperscaler or a vendor cloud, the operator’s ability to recover, upgrade or reconfigure an edge site depends on that external plane being reachable and supported.
• Hardware coupling. Far-edge platforms depend on specific accelerators, timing cards and network interfaces; changing platform may mean changing hardware in hundreds of cabinets.

The edge platform should therefore be held to a higher standard of reversibility than the core. Zero-touch provisioning from operator-owned repositories, hardware profiles supported by more than one platform, and the ability to recover a site while an external cloud is unreachable are, at the edge, the conditions for keeping control.

7. The new lock-in: how an operator becomes captive of its platform

Vendor lock-in is not the same as using proprietary software. An open-source platform can create dependencies that are just as hard to reverse, and a proprietary one can be bought under terms that keep it replaceable. The useful definition is practical: an operator is locked in when it cannot replace a supplier while preserving its services, its operational capability and a reasonable share of its investment, within a timetable compatible with its availability targets.

Dependency and lock-in are not the same thing. Concentrating infrastructure on one supplier can be a rational economic decision, when it brings significant cost reductions, simpler operations and sufficient contractual guarantees. Lock-in begins when that dependency stops being reversible on reasonable terms: when the operator can no longer renegotiate, evolve or replace the platform without disproportionate cost or risk. The rest of this section is about that line.

7.1 Eight mechanisms of dependency

Lock-in in telco cloud is produced by eight mechanisms that operate together.

Mechanism	How it is produced	Consequence
1. Licensing	Subscriptions, bundles, capacity metrics and contract changes decided by the supplier	Loss of negotiating power at renewal
2. Certification of network functions	The CNF or VNF is validated and supported only on specific platforms and versions	Changing platform means re-certifying every function
3. Technical integration	Dependence on platform-specific APIs, CNI plug-ins, storage, operators and extensions	Complex, risky migration
4. Automation and tooling	Lifecycle pipelines built on the supplier’s operators, scripts and services	Processes must be rebuilt
5. Data and observability	Telemetry, alarms, history and topology held in the supplier’s tools and models	Loss of operational memory on exit
6. Engineering capability	Knowledge concentrated in the supplier’s or integrator’s specialists	Operational dependency
7. Contractual responsibility	Support and SLAs tied to specific product combinations	Introducing alternatives voids coverage
8. Exit cost	Migration, lab work, homologation, coexistence and service risk	Economically forced continuity

The mechanisms reinforce each other in a predictable chain. A CNF certified on one platform fixes the Kubernetes version; the Kubernetes version fixes the operating system, network plug-ins and supported hardware; the automation of operations is then built on that combination; the organisation learns to work that way; and the contract ties support to the whole. At the end of the chain, changing supplier is no longer a technology project. It is an organisational transformation with service risk, and the supplier knows it.

7.2 Who now holds the control points

The appliance era had one kind of structural supplier: the network equipment vendor. The telco cloud era has five, each controlling different layers of the stack.

IBM: the consolidation of open-source control points

IBM has assembled, through acquisitions, the most complete portfolio of open-source-based control points in the enterprise and operator stack.

• Operating system and container platform. Red Hat — RHEL, OpenShift, OpenStack Services on OpenShift, Ansible — acquired in 2019 for about USD 34 billion.
• Infrastructure as code. HashiCorp, maker of Terraform and Vault, acquired in February 2025 for USD 6.4 billion.
• Event streaming. Confluent, the main commercial company behind Apache Kafka, whose acquisition IBM completed in March 2026. Kafka itself remains an open Apache Software Foundation project: IBM owns the leading commercial distribution and cloud service, not the standard.
• Cost management. Apptio, the IT financial management and FinOps software company, acquired in 2023.

Two episodes show how open-source control points can be monetised. In June 2023, Red Hat restricted public access to RHEL source code to CentOS Stream, making it harder for third parties to build compatible rebuilds; AlmaLinux and Rocky Linux had to adapt. In August 2023, before its acquisition by IBM, HashiCorp moved Terraform from the open-source Mozilla Public License to the source-available Business Source License; the community responded by forking it as OpenTofu under the Linux Foundation.

The TelcoCrux reading is not that IBM’s products are closed; they are largely built on open source and are technically strong. It is that one company now supplies the operating system, the container platform, the virtualisation layer, the automation tools, the event backbone and the cost management of many operators. Each product is replaceable in isolation. Together, they form a stack whose combined exit cost is high, and whose licensing terms are set by one counterparty. An operator standardising on OpenShift for IT and network, Ansible for automation, Terraform for infrastructure and Kafka for its data layer should know that it is concentrating four strategic dependencies in one supplier.

Broadcom: dependency made visible

Broadcom’s acquisition of VMware is the clearest demonstration of commercial lock-in in the sector’s recent history. Broadcom closed the roughly USD 61 billion deal on 22 November 2023 and in December 2023 ended the sale of perpetual licences, consolidating a portfolio of more than 150 products into a few subscription bundles centred on VMware Cloud Foundation. Section 7.3 follows the consequences.

Oracle: signalling functions and licence metrics

Oracle’s position in operator networks is narrower than IBM’s or Broadcom’s, but it sits on critical functions. Oracle Communications supplies signalling and policy functions — Diameter signalling routers, policy servers and, in 5G, cloud-native NRF, SCP, SEPP and binding support functions — that many operators deploy in their core; Verizon, for example, lists Oracle among its 5G standalone core suppliers. These functions route every signalling message in the network. Replacing them is a delicate, multi-year migration.

Oracle also illustrates how licence metrics create dependency across layers. Two examples are well documented.

• Database licensing on virtualised infrastructure. Oracle’s partitioning policy treats most hypervisors, including VMware, as “soft partitioning” that cannot be used to limit the number of processors to be licensed. In practice, a database running in a VMware cluster can expose the operator to licensing every host on which it could run — a dependency that shapes how the platform underneath is designed. Oracle presents the document as guidance rather than as contract terms, so the actual exposure depends on each contract and on how the deployment is audited and negotiated; the risk is real enough that many organisations design dedicated clusters around it.
• Java licensing. In January 2023 Oracle moved Java SE to the Java SE Universal Subscription, priced per employee of the customer organisation rather than per processor or user of the software, according to its price list. For a large operator, the metric is decoupled from actual use.

The lesson from Oracle is that lock-in can be exercised through a metric, not only through technology. A licence calculated on employees, on all hosts in a cluster or on all cores in a platform makes the cost of a component depend on architecture decisions that have nothing to do with the value it provides.

The hyperscalers: dependency on the management plane

The hyperscalers introduce a form of dependency that did not exist before: the infrastructure is on the operator’s premises, but the management plane is not. Section 7.5 develops it.

The network vendors: vertical integration returns

The network equipment vendors, which NFV was supposed to make interchangeable, have rebuilt part of their vertical position through platforms. A 5G core sold with the vendor’s own Kubernetes platform, lifecycle manager and analytics is, functionally, an appliance again — one that runs on commodity servers. Ericsson’s CNIS, Huawei’s and ZTE’s integrated stacks and the vendor-specific orchestrators all follow that logic.

7.3 The VMware/Broadcom case: commercial dependency, demonstrated

The VMware case is useful because it is public, documented and still unfolding.

• Price. Customer and analyst figures vary widely with contract and product mix. European cloud providers’ association CISPE has cited increases of 800% to 1,500% reported by its members, and later “more than 1,000%”; analyst estimates for typical enterprise renewals have been lower, in multiples of two to five.
• AT&T. In August 2024 AT&T sued Broadcom in New York, saying it had been refused a contracted support renewal and faced a 1,050% price increase, for an estate of about 75,000 virtual machines on roughly 8,600 servers. The parties settled in November 2024 on confidential terms.
• T-Mobile US. T-Mobile sued Broadcom in August 2025 over support for VMware licences covering about 303,000 CPU cores, described by its counsel as the base of its internal network hosting around 1,000 applications. A New York court granted an injunction keeping support in place until August 2026, which an appellate court affirmed in April 2026, according to The Register. T-Mobile had chosen Red Hat OpenShift as its common telco cloud in February 2025.
• Service providers and Europe. In January 2026 Broadcom signalled the end of its VMware Cloud Service Provider programme in Europe for all but a selected group of partners. CISPE filed a complaint with the European Commission in March 2026, and on 10 July 2026 five associations — CISPE, Beltug, Cigref, VOICE and CIO Platform Nederland — asked the Commission for interim measures and a transition period of at least three years. Broadcom rejected the accusations. As of October 2026, no interim measures had been reported.

Two cautions keep the analysis honest. A change of licensing model does not by itself prove that every customer suffered the same increase; the impact depends on contract, products and installed base. And litigation does not establish wrongdoing until a court decides. What the case does demonstrate, beyond doubt, is the strategic point: an operator whose critical infrastructure depends on one platform has very few immediate options when that platform’s owner changes strategy. Large operators with thousands of servers on VMware have needed courts to buy time for migrations.

7.4 Certification: the hardest lock-in to break

Of the eight mechanisms, certification is probably the most underestimated and the most durable. Consider an operator with a commercial 5G core.

1. The AMF, SMF and UPF are certified by their vendor on a specific version of a specific Kubernetes platform.
2. The platform uses an SR-IOV, driver, kernel and network configuration validated jointly.
3. The operator decides to move to another Kubernetes distribution, for cost or strategic reasons.
4. The CNF vendor requires a new validation cycle and does not guarantee support until it is complete.
5. The migration requires new tests of performance, resilience, upgrades and coexistence with the old platform.

Even if the containers can technically be deployed on the new platform, the system is not authorised for commercial operation with the same support commitments. The CNF vendor controls the timetable of the operator’s platform migration. When the CNF vendor also has a strategic alliance with one platform supplier — as Nokia does with Red Hat — the certification path of least resistance points in one direction.

Defining standard interfaces does not solve this by itself. A July 2026 paper on Open RAN by researchers including the University of Surrey argues that the ecosystem is consolidating into “interoperability islands”: pre-validated multi-vendor clusters that risk becoming new forms of lock-in, and that the remedy is to move from writing standards to enforcing rigorous, transparent certification. The study concerns Open RAN, but the mechanism applies equally to telco cloud. This is why Sylva’s shared validation programme (section 9) matters more than its code.

7.5 The hyperscaler case: owning the servers is not controlling the cloud

Hyperscaler hybrid offerings are often presented as a way to keep infrastructure on premises while gaining cloud agility. The documentation is clearer than the marketing.

• AWS Outposts. AWS describes the service link to the parent region as necessary for managing the Outposts, requires redundant links of at least 500 Mbps per rack and no more than 175 ms of round-trip time, and does not allow the connectivity type to be changed after ordering.
• Azure Operator Nexus. The cluster manager and network fabric controller run in Azure, connected to the operator’s sites through ExpressRoute.
• Google Distributed Cloud. The connected variant is managed centrally through Google Cloud, with Google remotely monitoring and maintaining the software; the air-gapped variant is a separate product with different economics.

Losing an external management plane affects three different capabilities, and they should be assessed separately.

• Continuity: whether running network functions keep serving traffic. In most designs they do, at least for a time.
• Recovery: whether a failed node, cluster or function can be restored without the external plane.
• Change: whether new resources can be deployed, scaled, upgraded or reconfigured.

A platform can score well on the first and poorly on the other two. For a function that carries national voice or data traffic, losing recovery and change capability during a prolonged disconnection is a material risk. It is also distinct from two other questions that are often conflated with it: data residency (where data is stored and processed) and regulatory compliance (whether the arrangement meets national security and telecoms rules). A platform can keep data in-country and still depend operationally on a management plane elsewhere.

A second, less discussed risk is the hyperscaler’s own strategic commitment. Microsoft acquired AT&T’s network cloud platform and its engineering team in 2021 and built Azure Operator Nexus on it. In June 2024, it cut jobs across its Azure for Operators unit and halted previews of its Azure Operator 5G Core and Call Protection services. Nexus remains in service, but the episode shows that the telecom strategy of a hyperscaler is a business line that can be reprioritised — and that an operator built on it carries that risk.

7.6 The accountability paradox: more suppliers, less clear responsibility

Disaggregation promises independence, but it also fragments responsibility. Consider a user plane function that starts dropping packets after a platform update. The function vendor points to the network plug-in; the Kubernetes supplier points to the NIC driver; the hardware vendor cannot reproduce the problem; the integrator shows that the deployment followed the specification. The architecture is multi-vendor; operationally, four companies are explaining why none of them is at fault, and the operator is carrying the outage.

This is a large part of the appeal of vertical stacks, and it should be taken seriously. A horizontal architecture remains the better default, but only if it comes with end-to-end accountability: a contractual obligation for all suppliers to cooperate in joint troubleshooting, a single incident-resolution process across them, shared access to logs and telemetry, and clear rules on who leads a multi-vendor incident. Without that, disaggregation transfers integration risk to the operator without giving it the means to manage it.

7.7 Organisational lock-in: depending on others to change your own network

The last dependency rarely appears in product comparisons. If engineering, pipelines, testing, configuration, observability and upgrade procedures are entirely in the hands of a supplier or integrator — and integrators are often the least visible source of this dependency — the operator can lose the practical ability to evolve its own architecture. It may own the code repositories and the licences and still lack the people and knowledge to operate the system independently.

Technology sovereignty is not owning the software. It is retaining the ability to decide, modify, integrate and replace components without putting service continuity at risk. That ability is built over years and lost in a few contract cycles.

7.8 Orchestration and data: the second battlefield

The infrastructure is only part of the problem. An operator can choose a horizontal Kubernetes platform and still depend on a proprietary orchestrator to deploy, upgrade and recover its network functions. It can multi-source its platforms and still have its topology, configuration history and telemetry locked in one supplier’s assurance tools.

The 2026 ETSI architecture points in the right direction here. Its Telco Cloud Connectivity Graph models the connections between applications and components across domains — the same dependency model that operations and assurance need to answer the questions a modern NOC asks: which commercial service uses this function, which cluster runs it, which platform version and kernel it depends on, and which infrastructure change could explain a degradation. If that model, and the data behind it, lives only in the platform supplier’s tool, changing platform also means rebuilding the operating model. Keeping it in operator-owned, open formats is one of the cheapest forms of insurance available.

8. United States: four operators, four approaches to telco cloud

8.1 The market behind the announcements

Before looking at individual operators, it is worth calibrating the scale of the market. Telco cloud has been forecast generously and has grown modestly.

• Spend. Analysys Mason estimates network cloud infrastructure spending at USD 16.9 billion in 2025, rising to USD 21.5 billion in 2031 — about 4% a year — after revising down its previous forecast of USD 25 billion for 2030.
• Forecast error. ABI Research now projects telco cloud revenue of USD 16.9 billion by 2029; in 2020 it had expected USD 29.3 billion by 2025.
• Different perimeters. The two firms measure different scopes — ABI combines packet core software and NFVI hardware, Analysys Mason uses its own network cloud categories — so the figures show direction and forecast error, not one market measured twice.
• The 5G core cycle. Dell’Oro reported mobile core network revenue up 15% in 2025, the fastest growth since 2014, with 5G core passing half of the total for the first time; in July 2026 it warned that memory shortages and higher server prices were leading some operators to delay core transformation.
• Standalone adoption. According to Ookla data for the fourth quarter of 2025, 5G standalone accounted for 31.6% of 5G samples in the United States but only 2.8% in Europe. These are shares of Speedtest samples — an indicator of deployment and device usage, not of subscribers or traffic.

The gap between the US and Europe in standalone adoption matters for this article. The 5G standalone core is the workload that forces a cloud-native platform decision. US operators made that decision earlier; most European operators are making it now, with the benefit of watching what happened.

8.2 AT&T: from building a cloud to renting one

AT&T was the most ambitious operator of the NFV era. Its Domain 2.0 programme set the target of virtualising 75% of its network by 2020, it built its own network cloud on OpenStack and Kubernetes (with the open-source Airship project for lifecycle management), and it open-sourced its orchestrator as the seed of ONAP.

In June 2021 it reversed course. AT&T agreed to move its 5G core onto Microsoft’s Azure for Operators, transferring its Network Cloud platform, which had run its 5G core since 2018, and offering its engineering team jobs at Microsoft. The platform became Azure Operator Nexus, whose reference deployment is AT&T’s 5G near-edge network functions.

The lesson is double-edged. AT&T concluded that building and maintaining a carrier cloud platform was not where it could differentiate, and transferred the cost and engineering to a company with far greater cloud scale. In exchange, a hyperscaler now operates the management plane of its core, and that hyperscaler cut back its telecom unit three years later. AT&T’s separate dispute with Broadcom over its VMware estate in 2024 shows that the same operator carried a second large platform dependency in IT.

8.3 Verizon: an in-house platform with commercial building blocks

Verizon chose to build its own Verizon Cloud Platform from 2016 and run its 5G standalone core on it. Commercial traffic began flowing over the standalone core in October 2022, with core functions from several vendors — Ericsson, Nokia, Oracle and Casa among them. According to Red Hat’s case study, the core incorporates OpenShift, and the RAN uses single-node OpenShift on bare metal at thousands of edge locations for centralised units, while its virtualised distributed units from Samsung run on Wind River.

Verizon’s model is the closest of the three to the horizontal ideal. The operator owns the platform architecture, multi-sources functions and uses commercial distributions as components rather than as the architecture. The trade-off is a large, permanent investment in platform engineering — the cost AT&T chose not to carry.

8.4 T-Mobile US: consolidating on one commercial platform

T-Mobile announced in February 2025 that it had selected Red Hat OpenShift Platform Plus as its common telco cloud from the core to the far edge. In parallel, it has been in litigation with Broadcom over support for an IT estate of about 303,000 VMware cores (section 7.3).

The reading is that T-Mobile is reducing platform diversity by concentrating on one commercial supplier. That simplifies operations and certification, and Red Hat’s open-source base is a material difference from VMware’s proprietary stack. It also concentrates a decade of renewals in one counterparty. The VMware dispute does not prove that the OpenShift decision was a reaction to Broadcom, and it should not be read that way; it does show what concentration on one platform can cost when commercial conditions change.

8.5 DISH, Boost and EchoStar: the cloud-native network that lost its radio

DISH built the first large greenfield 5G network designed entirely in the cloud. In April 2021 it announced that AWS would host its Open RAN and 5G core across Outposts, Local Zones and regions, with a Nokia core and VMware as the container platform from 2020. In December 2024, its Boost Mobile unit replaced VMware with Wind River as the CaaS layer — which Wind River called the largest CaaS vendor changeover on an O-RAN network, and which industry analysts linked to Broadcom’s pricing.

The story then took a turn no architecture diagram anticipated. EchoStar sold spectrum to AT&T for about USD 23 billion, a deal closed in July 2026, and other spectrum to SpaceX. According to its 2026 quarterly filing, it continues to operate its 5G core while using AT&T’s network services, and its own radio network is being decommissioned.

Two lessons follow. First, a CaaS platform can be replaced in production, and Boost proved it — on a network designed from day one with automation and a single platform team. Brownfield operators should not assume the same speed. Second, the most cloud-native network in the United States was undone by its business and regulatory situation — spectrum economics, and the Federal Communications Commission’s scrutiny of its spectrum obligations described in EchoStar’s filings — not by its technology. Infrastructure choices matter less than the business model they serve.

8.6 What the US cases show

Operator	Model	Main dependency	Reversibility signal
AT&T	Delegated to a hyperscaler (core)	Azure management plane and Microsoft’s telecom commitment	Low: platform and team transferred
Verizon	Operator-built horizontal platform with commercial components	In-house engineering capacity	Higher: multi-vendor functions and platforms
T-Mobile US	Consolidation on one enterprise platform	Red Hat subscriptions and ecosystem	Medium: open-source base, single counterparty
DISH / Boost	Public cloud plus specialised CaaS	AWS for infrastructure and management	Demonstrated: CaaS replaced in production

9. Europe: openness as policy, diversity in practice

European operators have made the most explicit commitment to open, multi-vendor telco cloud, through Sylva and EU policy. Their actual deployments are more diverse than that commitment suggests — sometimes within the same group.

9.1 Deutsche Telekom: building the platform in the open

Deutsche Telekom built its own Kubernetes platform for the 5G standalone core, telephony and other CNFs. Originally called Das SCHIFF and now T-CaaS, it runs vanilla Kubernetes and open-source components on bare metal as a common platform for its European national companies, with lifecycle managed through GitOps and Cluster API since 2021. Its engineers have described publicly how they route to each host with BGP-EVPN using the open-source FRRouting stack, configured through Kubernetes resources by an open-source network operator that the company publishes.

DT is the European operator that has gone furthest in keeping platform engineering in-house and in open source. The cost is a large, specialised engineering organisation; the benefit is that no single platform supplier controls its core. It is also a founding member of Sylva.

9.2 Orange: Sylva in production, Red Hat in parts

Orange is the clearest example of Sylva in production. Its Orange Telco Cloud is a private cloud built on the Sylva framework with Cluster API and Rancher Prime, according to SUSE; Orange reported in 2026 that its cloud deployments run on several hundred live Kubernetes clusters on SUSE RKE2 across more than a dozen Orange entities, with more than 50% fewer servers and 30% lower operating costs than the legacy platforms they replaced — Orange’s own figures. Its multi-cloud 5G standalone network, Pikeo, is at the centre of recent Sylva work.

In parallel, Orange’s international carrier business chose a different platform. Orange International Networks announced in March 2025 a shared telco cloud on Red Hat OpenShift, including OpenShift Virtualization for existing VNFs, and Ansible Automation Platform, after virtualising more than 30 functions from 12 vendors over eight years. The two decisions are not contradictory; they illustrate that even a group committed to openness chooses different platforms for different domains.

9.3 Vodafone: VMware heritage, Open RAN on Wind River, hyperscalers for IT

Vodafone adopted VMware’s Telco Cloud Platform across its European markets in the NFV era. More recently, its Open RAN deployments have run on a different stack: in the UK, Samsung RAN software on Dell servers with Wind River as the container platform, and from October 2025 Samsung as primary Open RAN partner for Germany and other European markets, again on Wind River. For IT and AI, Vodafone signed ten-year agreements with Microsoft in January 2024, including moving its data centres to Azure, and with Google in October 2024. Outside Europe, Vodafone Oman reported in March 2026 that more than 60% of its production runs on OpenShift on bare metal.

Vodafone’s estate therefore spans VMware, Wind River, Red Hat and two hyperscalers. Diversity of that kind protects against any single supplier but raises the cost of common automation and governance — the problem that horizontal standards such as Sylva try to address.

9.4 Other European patterns

• Network vendor verticals. BT runs Ericsson’s container-based 5G core on its network cloud; Bouygues Telecom selected Ericsson’s dual-mode 5G standalone core in 2022; Iliad extended its Nokia cloud-native core and IMS agreement for France and Italy in December 2024, deployed “in multi-cloud environments”.
• Hybrid with hyperscalers. Swisscom has worked with Ericsson and AWS on a 5G core spanning its private cloud, AWS Outposts and the AWS Zurich region.
• OpenStack NFV. Proximus runs NFV on Red Hat OpenStack and Ceph and reported 20% lower costs in 2021.
• Greenfield risk. 1&1 in Germany built an Open RAN network with Rakuten Symphony as general contractor. A software upgrade in May 2024 triggered an outage that 1&1 attributed to central components that were not sufficiently dimensioned, slowing the migration of its customers; it completed migrating about 12 million customers in November 2025 and is disputing compensation with the contractor. The case is a reminder that a delegated, integrated cloud network concentrates operational risk in the integrator.

9.5 Sylva: how far shared validation has come

Sylva’s maturity can now be measured. The project reported in May 2026 22 validated workloads from 15 vendors and 8 operational validation platforms, with two more coming. The validation cycle covers the RKE2, Canonical Kubernetes and OKD distributions on bare metal, OpenStack and OpenNebula infrastructure. Sylva 1.7, released in 2026, supports Kubernetes 1.34 and 1.35 and adds, among other things, a technology preview of nested KubeVirt clusters.

Model	How a CNF reaches production	Cost structure
Traditional	Each CNF validated separately on each operator’s platform and version	Validation repeated per vendor × platform × operator
Sylva target	CNF validated once against shared requirements and tests, then deployed on any compliant platform	Validation shared; operator-specific testing reduced, not eliminated

The TelcoCrux assessment of Sylva has three parts.

• It addresses the right problem. Sylva does not try to replace Linux, Kubernetes or OpenStack; it targets fragmentation of configurations and the repetition of integration tests across vendors — the certification lock-in of section 7.4, which no operator can solve alone.
• It is not a product. Its own documentation is explicit that it provides a framework, a reference implementation and validation tools from which supported solutions are built. An operator still needs a distribution, support and integration.
• Its success depends on purchasing, not on code. The participants include large commercial vendors with legitimate incentives to differentiate. Sylva will matter to the extent that operators write Sylva compliance — and support on more than one compliant platform — into their tenders and contracts.

9.6 The European policy layer

The EU has started to treat telco cloud as a sovereignty question. The European Alliance for Industrial Data, Edge and Cloud published in February 2025 a Telco Cloud Reference Architecture with the explicit aim of reducing vendor lock-in, adopted as a baseline by IPCEI-CIS. The proposed Digital Networks Act of January 2026 frames digital networks as increasingly “cloud- and AI-based”, and the Cloud and AI Development Act proposed in June 2026 targets at least tripling EU data-centre capacity and introduces auditable cloud sovereignty levels. The competition complaints against Broadcom show European customers using antitrust as a lock-in remedy.

Policy can create conditions; it cannot make purchasing decisions. The most effective European instrument against lock-in remains the tender documents of its largest operators.

10. How to keep dependencies reversible

Every serious option on the market creates dependencies. The goal is not to avoid them, which is impossible, but to keep them visible, priced and reversible. That requires decisions in four areas: architecture, purchasing, economics and organisation.

10.1 Choose the architecture before the product

The most robust decision is to define first the architecture that preserves the operator’s ability to decide, and only then select the products that best meet it. Six principles should guide it.

• Horizontal by default. Separate network functions from infrastructure wherever technically and economically viable. Document and justify every vertical exception in writing, with its exit path.
• Kubernetes as the base for new CNFs, not as an end in itself. The core of a cloud-native platform that includes telco capabilities, security, support and automation.
• OpenStack or equivalent virtualisation where it still adds value. Avoid indiscriminate migration of stable VNFs; decide by support, cost, risk and operational viability.
• Multi-vendor proven in the lab, not declared on paper. Compatibility claims count only when deployment, upgrade, recovery and operation of the functions on an alternative platform have been demonstrated.
• Lifecycle, data and observability decoupled from the platform. Configuration, change history, service dependencies and telemetry kept in operator-owned repositories and open formats.
• In-house platform engineering. Keep architects, integration, automation, testing and reliability specialists. Outsourcing execution must not mean outsourcing critical knowledge.

10.2 Three target scenarios

Scenario	When it makes sense	Trade-off
Standardised enterprise platform	Many IT and network workloads, strong need to simplify and reduce diversity	Concentration in one commercial supplier
Open modular infrastructure	Operator with strong engineering and a clear wish for technological control	Greater own effort and integration responsibility
Federated hybrid model	Diverse workloads, geographies and autonomy needs	Requires mature cross-platform governance and automation

For a large operator with several generations of network, IT, B2B, core, IMS and RAN, the federated hybrid model is usually the most sensible long-term target. That does not mean multiplying platforms arbitrarily. Standardisation should happen in the interfaces, requirements, data and operating model — not necessarily in the use of a single product for every workload. A large operator can run one enterprise platform for most of the core and IT, a specialised far-edge platform for vRAN and a hyperscaler for analytics, provided all three are governed by the same automation, inventory, security and observability model, and each can be replaced on its own timetable.

10.3 Write reversibility into the contract

Most lock-in is decided at signature, not at renewal. Eleven contract terms do more for an operator’s autonomy than any architecture diagram.

1. Price protection. Caps on renewal increases and protection against unilateral changes of licence metric, bundle or product packaging during the contract and for at least one renewal.
2. Metric neutrality. Licence metrics tied to the value delivered, not to employees, unrelated hosts or capacity the software does not use.
3. Multi-platform support for network functions. CNF vendors commit to support on at least two compliant platforms — Sylva-validated where possible — with defined timetables for new versions.
4. Certification timetables. Maximum delays for certifying the function on new platform versions, with remedies if they are missed.
5. Support continuity. Guaranteed support terms for the full planned life of the deployment, surviving a change of ownership of the supplier.
6. Exit assistance. A defined, priced obligation to support migration to another supplier, including coexistence periods.
7. Data and configuration portability. Telemetry, topology, configuration and change history exportable in documented, open formats at any time, at no extra cost.
8. Automation ownership. Pipelines, playbooks, operators and test suites built for the operator belong to the operator and are delivered in its repositories.
9. Management-plane survivability. For hybrid offerings, a documented and tested mode in which critical functions can be operated, scaled and recovered while the external management plane is unreachable.
10. Knowledge transfer. Measurable obligations to train and certify operator staff, so that operations do not depend on the supplier’s specialists.
11. Multi-vendor accountability. An obligation for all suppliers of a horizontal platform to take part in joint troubleshooting under a single incident-resolution process, with shared access to logs and telemetry.

10.4 Measure the economics properly

Commercial comparisons usually focus on licence price or cost per core. For an operator, the relevant cost must be analysed over several years and include engineering effort and the consequences of a possible replacement. A five-year total cost of ownership should add up six components.

• Infrastructure and energy.
• Licences and support.
• Engineering and integration.
• Operations and automation.
• Certification and upgrades.
• Migrations and coexistence.

Risks of major incidents and of contractual exit should be assessed separately, because they are neither recurring nor certain. Two additional metrics capture what TCO does not.

• Exit cost. The sum of migration, validation, coexistence and re-engineering costs required to replace the supplier.
• Time to autonomy. The time needed to restore the ability to operate and evolve the infrastructure without the supplier being replaced.

The second metric matters more than the first for critical functions. An operator might afford the cost of migrating and still lack a timetable that allows it to replace the platform without compromising service — which is exactly the position in which large US operators needed courts to secure continued VMware support. An infrastructure with an attractive five-year TCO can be a weak strategic decision if its exit cost and time to autonomy are out of proportion.

10.5 Diagnose the current position

A simple diagnostic gives a first, honest view of how reversible an operator’s dependencies are. Each dimension is scored from 0 (critical dependency) to 4 (proven autonomy), per platform and per critical function. It is an internal assessment tool, not a benchmark of suppliers; scoring brands without knowing contracts, deployments and configurations would fake a precision that does not exist.

Dimension	Question	0 means	4 means
Workload portability	Can the function run and be supported on an alternative platform?	Supported on one platform only	Supported and tested on two or more
Management-plane independence	Can critical services be operated, recovered and upgraded if the supplier’s plane fails or disappears?	No operations possible	Full operations, tested
Verified interoperability	Are there cross-vendor deployment and upgrade tests?	None	Automated and repeated each release
Data and observability	Are telemetry, history, topology and configuration exportable?	Locked in the tool	Operator-owned, open formats
Contract freedom	Are price, metrics and support terms capped?	Unilateral changes possible	Capped and protected
In-house capability	Can operator teams run the system without supplier staff?	Fully dependent	Fully autonomous
Exit cost	Is there a funded, tested migration plan?	None	Budgeted, rehearsed, compatible with availability targets

10.6 What each type of operator should do now

• Large incumbents. Treat the platform decision for the 5G core and the edge as a ten-year strategic commitment, decided at board level with exit cost and time to autonomy on the table. Use purchasing power to make multi-platform CNF support and Sylva compliance contractual. Keep a platform engineering team large enough to run an alternative.
• Merged or carved-out operators. Use the integration or separation programme to design for reversibility, not only for speed. Every transitional dependency — on a former parent, on a single vendor chosen for integration speed — should have an end date and an exit plan.
• Challengers and low-cost operators. Accept integrated or managed platforms where they reduce cost, but negotiate price caps, metric protection and exit assistance harder than incumbents do; a sudden renewal increase hurts a lean cost base most.
• Operators planning edge deployments. Build the edge for your own network functions first; insist on zero-touch provisioning from operator-owned repositories, hardware profiles supported by more than one platform and a management plane that survives loss of connectivity.
• All operators. Run the autonomy diagnostic on every critical platform this year, and start with the dimensions that cost least to fix: data portability, automation ownership and contract terms at the next renewal.

11. Conclusions

NFV kept its technical promise and broke its commercial one. Network functions now run as software on commodity servers, and cloud-native platforms can host virtual machines, containers, IT and network workloads on one infrastructure. The dependency on suppliers did not disappear; it moved from the box to the platform, the certification of functions on that platform, the automation and data around it and, for hybrid offerings, a management plane outside the operator’s walls.

The new control points are held by a small number of companies. IBM, through Red Hat and its acquisitions, supplies much of the open-source-based stack; Broadcom has shown what happens when the owner of a dominant platform changes strategy; Oracle shows how licence metrics can create dependency across layers; the hyperscalers offer cloud capabilities at the price of their management planes; and the network vendors have rebuilt vertical integration through their own platforms. None of them is an adversary. All of them are counterparties whose incentives differ from the operator’s.

Operators have responded in very different ways. AT&T delegated its core platform to a hyperscaler; Verizon and Deutsche Telekom kept platform engineering in-house; T-Mobile consolidated on one enterprise platform; Orange runs Sylva in production while parts of the group choose other platforms; Boost proved that a platform can be replaced in production.

The edge raises the stakes. Whatever is decided for three central data centres is multiplied by the number of edge sites, and becomes part of the physical network. The edge should be built for the operator’s own functions first, with reversibility held to a higher standard than in the core.

The decisive question is no longer which platform performs best. It is which architecture allows an operator to evolve its network over the next ten years without any supplier being able to dictate unilaterally its costs, its upgrade cycles or its technology choices. The answer is not a product. It is a set of principles applied consistently: horizontal by default, multi-vendor proven in the lab, data and automation owned by the operator, contracts that price exit at signature and enough in-house engineering to make all of it credible.

Software left the box a decade ago. The operators that keep control of their networks in the next decade will be those that make sure their ability to decide follows it.

---

At TelcoCrux, we help operators make telco cloud and edge decisions that stay reversible: assessing platform options for the 5G core, IT and edge, running autonomy diagnostics on existing dependencies, quantifying exit cost and time to autonomy, and writing the contract terms that keep suppliers competing after signature. If you are about to commit to a platform, or renegotiating one, and want an independent read first, let’s talk.