 Hello everyone, welcome to the lightning talk on service mesh patterns from a telecom perspective. My name is Sudip Bhattra and I work as a cloud architect for Ericsson, the company that builds telecom networks for the telco operators across the globe. OK, so let's get started. We all love our phone. However, a lot goes behind the seed that enables us to network, text, browse and be connected or work or to our loved ones. So let's take a look at a high level view of the basic telecommunication network. In this diagram, we can see the user equipment. Which is our favorite handset connecting to the access network. Over the air interface, then our data, which is basically the voice, video, text, chat or the browsing data gets carried over the transport network or the backhaul to the core network. Much of the action happens here in terms of connecting us to another person or device and also connecting us to the internet. Cloud native transformation is happening now across the telecommunication network. So let's see how initially the telecommunication network was built using physical network functions or PNF, which were deployed manually on proprietary hardware and software in most of the cases. Then we got OpenStack and the PNFs were transformed into virtual network functions or VNF posted on the infrastructure as a solution platform. Powered by OpenStack. Now the VNFs are being transformed to cloud native functions taking advantage of Kubernetes and cloud native technologies like service mesh. Also the orchestration layer is transforming from the ability to orchestrate the virtual machines to orchestrating the containers as well. In the next slide, we will see how the CNFs are used in a typical 5G core network. So this is a typical solution of Ericsson 5G core network, which is built upon many cloud native functions. In this diagram, we can see the 5G core is broken into the data layer, the control plane and the user plane. The data layer stores the subscriber data. The control plane in the middle that manages the traffic and signaling. It includes functions like DNS, load balancing, network slides, selection functions, et cetera. The user plane is where the user traffic flows. Each of these blue boxes could be considered as a CNF fulfilling a specific function in the 5G core network. There are a couple of ways the telco operators ask for the CNF deployment depending on their needs. The simplest case could be all CNF from a single vendor on a single Kubernetes cluster or it could be all CNFs from different vendors. It could also be CNF from different vendors on separate dedicated Kubernetes cluster. So in the next slide, we will see how the service mesh comes into the picture. Operators want to leverage the benefits of service mesh like Istio for security, observability, traffic management and policies when they deploy their CNFs and they want service mesh to be deployed according to their use cases. So let's start with the four patterns, which can be adopted according to the unique requirement of an operator. So the first pattern, in this we have a single Kubernetes cluster, all CNF shown as service A in workspace one namespace and service B in the workspace two namespace are from a single vendor. Essentially we have a single service mesh to manage the CNF in its own namespaces. Please assume that CNF is made up of multiple service or Kubernetes pod and objects, but for simplicity, we only see replica of two services. Then we have a single ingress and aggress gateway for both work load. Now in the next pattern, we have a single Kubernetes cluster and CNF from different vendors, but we have a single service mesh to manage each CNF in its own separate namespace. Also, we have separate ingress and aggress gateway for each vendor, providing separate data plan traffic flow within the same Kubernetes cluster. In this pattern, we have again a single Kubernetes cluster, but CNFs from different vendor and we have dedicated service mesh for each vendor and its CNF in its own namespace within the single Kubernetes cluster. Also in this case, we can see that the ingress and aggress gateway are separate for each of the CNF. Finally, we have multiple Kubernetes cluster from multiple vendors. Each vendor deploys its CNF in its dedicated Kubernetes cluster and we have a dedicated service mesh for each vendor. And also we have separate ingress gateway and aggress gateway for each vendor. So we have separate control traffic and data traffic for each CNF. That's all I have in this session. Thank you for listening. Please reach out to me for any query.