Telecommunications network functions used to be appliances: purpose-built boxes doing one job, bought from a small number of suppliers. Network functions virtualization turned them into software, and 5G core architecture went further and turned them into containerised services on a Kubernetes platform.
The infrastructure underneath is recognisably the same hardware you would buy for anything else. The requirements are not.
What is different about these workloads
Packet processing at line rate. A user plane function moves packets, and the default network path through a general-purpose operating system is not fast enough. This is why techniques that are exotic in enterprise virtualization are standard here: kernel bypass with user-space drivers, single-root virtualization of network adapters, hardware offload to smart adapters.
The consequence for infrastructure design: specific network adapter models, specific driver versions, and passthrough configurations that constrain what else you can do with the host.
Deterministic latency. Not average latency, worst case. Control plane signalling and user plane forwarding both have timing requirements, and a hypervisor scheduler that occasionally delays a thread by milliseconds is a failure.
This means CPU pinning, isolated cores, NUMA-aware placement, huge pages, and a tuned kernel. It also means giving up a lot of the consolidation that makes enterprise virtualization economic. A node running a user plane function is not sharing its pinned cores with anything.
Timing and synchronisation. Radio access networks need accurate time distributed across sites. Precision time protocol becomes infrastructure, with hardware timestamping in the network path. This is unfamiliar territory for an enterprise team and it is not optional.
Carrier-grade availability expectations. Targets expressed with more nines than enterprise applications, applied to a platform, with in-service upgrade requirements.
Central, edge, and far edge
The architecture distributes functions across tiers, and each is a different infrastructure problem.
The central site is a conventional data centre. The regional edge is a smaller facility with real constraints on space and power. The far edge — cell sites, cabinets — is a handful of servers in an environment with no operations staff, possibly extreme temperatures, and intermittent connectivity.
The far edge is where enterprise assumptions break most completely. Remote lifecycle management, zero-touch provisioning, and the ability to recover a site without sending a person are not nice to have; they determine whether the deployment is operable at all.
What this means if you are an enterprise person walking into it
Much of your knowledge transfers: capacity, storage, failure domains, Kubernetes operations, automation discipline. The platform is a platform.
What does not transfer is the assumption that the hypervisor or container runtime is transparent. Here it is in the datapath, it has to be tuned, and the tuning is specific enough that hardware compatibility lists matter more than in any enterprise design.
The other thing that does not transfer is the consolidation instinct. Overcommitting these workloads is not a tradeoff between cost and performance, it is a correctness problem.
The honest summary
This is general-purpose infrastructure operated under constraints that look more like industrial control than like enterprise IT. The kit is familiar, the discipline is not, and the projects that struggle are usually the ones where somebody assumed the two were the same because the servers looked the same.