I recently attended a session that focused on how to provide cloud native hardware and software in a telecoms environment today. In other words: How can network operators deploy hardware and software in their data centers to build Kubnernetes clusters, huge storage capacities and ultra fast networking that are the basis today for all kinds of (5G) telecom workloads? Such workloads are for example the 5G core network functions, think 3GPP AMF (Access Management Function), SMF (Session Management Function), UPF (User Plane Function), but also the the subscriber database, legacy workloads such as a virtual EPC (LTE core network), IMS functions for voice calls, etc. etc.
The theory is easy: Roll-in some hardware, put Kubernetes on it and then deploy 3GPP software components into them. After all, the idea is that Kubernetes is Kubernetes, and workloads running in the cluster are shielded form the hardware setup below.
In reality, however, it’s not quite that straight forward…
Reality bends theory quite a bit because telecom workloads have real time requirements, require super high availability and redundancy, there are safety aspects that need to be taken care of, and especially the ‘user plane’ requires ultra high throughput network interfaces. In theory, a clear cut can be made between ‘everything Kubernetes and below’ on the one hand and the workloads running in the clusters on the other hand. In practice, this is not quite the case, because the Kubernetes setup, storage and network hardware need to be optimized for these requirements. A Kubernetes cluster on a Raspberry Pi and an SD card for storage just won’t do it for a nationwide network to make an extreme, and yes, quite silly example.
Who takes care of Kubernetes and Everything Below?
So who takes care of the complexity of Kubernetes and everything below? Currently, there are three approaches:
1. The network operator takes care of everything, i.e. they buy the hardware and create a Kubernetes framework that is adapted to their needs. Sounds simple, but it is a lot of work. I have seen attempts that several network operators want to work together on such a framework, which would put the work for this on several shoulders.
2. Use someone else’s shoulders, i.e. let someone else deal with Kubernetes and below. That would be the Hyperscalers, a.k.a. Amazon, Google, Microsoft, Oracle. Some of them offer customized telecom hardware, storage and Kubernetes configuration in their own data centers. The problem here: The infrastructure is no longer under the control of the telecom operator. When the hyperscaler has a problem, the core network goes away and in the worst case, the country goes offline without the network operator being able to do anything but wait for the hyperscaler to react. In addition, when every millisecond of latency counts, telecom operators can’t put their core networks in a data center far away. Hyperscalers of course have data centers in many places, so that is often not an issue.
3. If latency is an issue, some hyperscalers offer the possibility to ship their hardware and software to a network operator and host it in their data center. One hyperscaler calls it ‘Outposts’. The network operator then provides power, cooling and network connectivity. All the rest remains under control of the hyperscaler. This solves the latency issue but as in case two, the network operator is not in control of the hardware and software on the Kubernetes layer and below. So if something goes wrong at the hyperscaler, you are again back to ‘sit and wait’.
Obviously, different people prefer different options and the story which option will be the most popular one going forward is not written yet.