As mobile operators continue to extol the theoretical expectations of new services and revenue streams that 5G is supposed to herald, they’re faced with a much more concrete reality on the network side: How should 5G network architectures be built to deliver upon all of those promises?
5G network architecture requires several new considerations: the ability to scale and deploy functions quickly; the need for orchestration that delivers automated lifecycle management; and service composition that supports microservices, with the ability to manage discrete functions in independent units.
On the surface, cloud-native architectures provide the solution, as their goal is containerization, dynamic orchestration and microservices. In this changing environment, operators have to consider cost. Operators already have invested millions to upgrade infrastructure, making it prohibitively expensive to redesign, code and test a new network architecture. To circumvent those costs, many operators are considering a hybrid approach to cloud-native architectures.
VMs vs. containers
Any discussion about the viability of cloud-native architectures has to start with the implications for virtual network functions (VNFs), which operators have been deploying for several years to replace hardware-based appliances. Operators deploy network functions virtualization (NFV) in one of three ways: on virtual machines (VMs) with hypervisors; in containers; or using a hybrid approach.
There are two types of containers. Operating system (OS) containers simulate an OS-based environment and are suited to running multiple related applications. By contrast, application containers are modeled around a single process within the container. The application container model is followed by Docker.
Another important distinction is that VMs have their own operating system (OS), while containers share an OS. As such, containers are more efficient because they don’t require multiple operating systems per host. However, VMs offer more OS flexibility, because the application software can be packaged with the OS.
Currently, there is more support for open orchestration and tools in a container environment, whereas there are more vendor-specific tools within a VM environment. Consideration also should be given to the fact that Kubernetes is a well-established container orchestration tool, and its equivalent isn’t available in the VM space, because there are multiple, competing vendors. The result is that building a more complex service chain with multiple services currently is better suited to a container environment, which has more standard tools to do so more quickly.
However, containers present several challenges for telecom-grade environments. The first challenge is that sharing of the OS creates the potential for applications and their containers to interfere with each other or create resource contention. For mobile operators in particular, this approach creates difficulties in both the control and data planes for a 5G environment, where latency, efficiency, security and a high level of distribution are needed.
Another challenge to using containers in telco environment is that much of the technology related to container networking isn’t yet suited to telco environments. As a result, the VM world is somewhat ahead with networking facilities. Work currently is being done to close that process gap.
A final complication is that container environments require orchestrational microservices. A microservices architecture develops a single application as a suite of small services, each of which run their own process and communicate with lightweight mechanisms. These services are built around business capabilities and independently deployed by fully automated machinery, and they’re designed as an extension of the service-oriented architecture (SOA) approach.
Pros and cons of microservicing
However, it’s important for operators to consider whether they need – or even want – a microservices architecture, which requires a high degree of orchestration. Moreover, it begs the question: Will vendors ever really adopt this disruptive strategy for service decomposition and replacement, especially given that it often depends upon open interfaces?
Only those mobile operators that need to build, deploy and scale frequently and rapidly should incorporate a microservices architecture. Functions designed from the beginning as a microservice may have the innovation needed for the new telecom service environment. Determining the best approach depends upon technical and innovation choices, as well as understanding the implications on different system paths.
It’s also important to account for the amount of time and investment it will take to decompose existing applications to fit into containers. Finally, consideration must be given to whether decomposing into a microservice can actually be counterproductive. Because microservicing supports cloud-native architecture, it can create problems with latency, which is the death knell for 5G applications and services.
While mobile operators stand to benefit tremendously from fully deployed 5G networks, the reality is that there are a number of foundational issues that must be addressed to ensure those networks provide the speed, latency and reliability that 5G applications demand. As is generally true in technology, a hybrid approach to developing those networks is likely the best pragmatic path forward for operators.
