We covered Service Meshes and Isitio in a few blogs late last year – https://www.vamsitalkstech.com/cloud/service-mesh-technology-circa-2020/.
Given that 5G (both core and radio) will be developed on cloud-native functions, the common denominator to both Service Mesh and 5G technology are microservices-based architecture.
The Service Based Architecture (SBA) as discussed in the last post – https://www.vamsitalkstech.com/5g/5g-core-5gc-platform-architecture/ – envisions the creation of 5G control plane components as microservices as opposed to the monolithic 4G design. The 4G architecture has a point-to-point network design. In the SBA, except for a few legacy interfaces such as N2 and N4, almost every interface uses a HTTP/2 protocol. NFVs deployed on 4G platforms typically run on one or more VMs deployed on commodity hardware. 5G functions on the other hand will run as Containers thus achieving higher scalability at better hardware usage profiles.
A few blogs ago, we highlighted some of the traditional issues in enterprise applications that emerge from adopting Service Meshes too early (https://www.vamsitalkstech.com/cloud/is-istio-production-ready-when-is-a-service-mesh-overkill/) . At this point, these organizational & technical challenges may not exist in 5G services. Having said that, even telcos (or lines of business within them) need to be at a point of cloud maturity before going down the service mesh route. The 5G SBA model envisions various NFs as loosely coupled and modular, thus forming a mesh like structure thus helping in adding new features across various NFs, without adding additional developer or operator burden.
So let us identify the few key areas in which Service Meshes can enable 5G Architectures –
- Core SBA functions including the NRF, NSSF, NEF etc concern themselves with routing decisions. They all can leverage a Service Mesh like technology to provide smarter routing and signaling capabilities
- Service Meshes also can decouple network connectivity functionality from the core microservices that makes up the CNFs (Cloud Native Function) in the SBA. These additional capabilities include Service Discovery, Load balancing etc which are typically delegated to a load balancer layer in a cloud native architecture. The immense scale of 5G business services (https://www.vamsitalkstech.com/cloud/the-three-key-use-case-areas-for-5g/) is what necessitates the need for a Mesh management entity to manage the interactions between these functions written as microservices.
- Trust Management and Security – CNFs that will make up various 5G functions break up larger functionality into modular components. This naturally increases the surface area for attacks. Service Meshes support Mutual Transport Layer Security (mTLS) for end-to-end authentication, Zero Trust, network policies and transport security for service to service communication.
- We have discussed the need for CNFs to co-exist with 4G VNFs. Prior to 5G rollouts which are just beginning (& with the 5G NSA (Non-Standalone) option), telco and edge cloud workloads will be deployed using a combination of virtual machines (VMs) and containers. Service Mesh can be useful to manage communication between VNFs and CNFs.
- Using Service Meshes rolling out new applications (RAN, Edge/user applications, Core updates) in the telco cloud becomes as seamless as possible – https://www.vamsitalkstech.com/architecture/a-devops-pattern-for-developing-edge-computing-applications/. Canary deployments, A/B testing can all be done leveraging the mesh as opposed to handling them in application or infrastructure code.
- Dynamic Network Slicing is really what makes 5G such a business-oriented capability. Most Service Meshes use sidecar proxies, which makes it easy to monitor service performance whether those are CNFs or legacy VNFs.
- Monitoring, Debugging and Traceability – Observability will be a Day one capability when large clusters of telco networks are deployed from monitoring, troubleshooting, and issue traceability standpoint.
The Service Communication Proxy (SCP)
The 3GPP has proposed an optional and incremental component called the Service Communication Proxy (SCP) as part of the 5GC we discussed in a post a couple of weeks ago. The SCP works with the NRF to perform network topology simplification by signaling, routing, load balancing, and load management using message prioritization.
Conclusion
The goals of the 3GPP are to standardize core functions in the SBA to be microservice and cloud-native. When the Telco cloud becomes ‘Cloud-Native’ and Stateless. or Services differ from traditional applications as they are ‘Stateless’ i.e. state is not stored as part of the function or app. and it is implemented as microservices that are: Scalable Composable Reusable Technology and language-independent API accessible Given all of these factors, Service Mesh technology will be critical importance to achieving high-performance 5G services. The next blogpost will cover the 3GPP’s Service Communication Proxy (SCP) as a way of achieving Mesh like capability.