 Welcome to our panel House of Card or Telco 5G and this is Kandan Khadribel from Google and we have three panelists joining today, Sana from Telus and Daniel from Bel, Canada and KJ from AT&T and we're going to talk today about why cloud native approach is very important in terms of Telco 5G deployment. As you know that 4G primarily used the virtual network functions and the private cloud to support those virtual network function. There are multiple changes and the paradigm shift is happening with respect to 5G. That's one is from the virtual network function into the container network function deployment and also transition from private cloud to public cloud and also the adoption of the open RAM and the Telcos also wants like a multi vendor solution in order to support 5G at the scale and these all need to be bring together to support the full end to an automation of the 5G and there are challenges today with respect to how the cloud native has been applied and the deployed with respect to 5G and the open source community has done a great job in supporting the container network function with respect to Kubernetes but there are still gaps that need to be addressed with respect to the open source community and in this panel we're going to talk about what is already out there, what is the gaps and things that the open source community and the standard bodies has to support it. So with that let's start with a question to Sana, why do you think cloud native principles are very important with respect to the 5G deployment? Kandan I think it's an important subject to touch and I think I first tried to ask ourselves a very fundamental question like being service providers, why did we even want that shift to happen from the virtual network functions to cloud native network functions? I think we were not happy or satisfied with the degree of fragility or the optimization or efficiency or automation that we leveraged from the virtual network functions. So I think we wanted to improve one step further. We wanted to get to better optimizes, optimized capacity, increased portability, consistent simplified operational models across all of our workloads. These were our hopes and dreams but when the transformation started happening and they started receiving the cloud native functions, these are in fact packages containers but they are not yet following all the cloud native principles today. So our first expectation that we would be able to put them on any cloud and they're truly cloud native but today they are coming with their customized requirements and each CNF has its own requirement from the infrastructure. Now each cloud native function that we are receiving has a different type of footprint which is coming from its legacy monolithic solution. Similarly you see that there is a different deployment model for each one of these. There is very complex proprietary configuration models that exist for deployment of these network functions. So we are losing that dream of consistent simplified operational models. Like we are making a shift in technology to get to the stage where there are packages containers but they are not yet finding all the benefits of agility and automation. Another quick note that I wanted to make for automation. I think a big driver behind doing all of this was our time to market a very simplified, easier, faster, better automation which we are still not seeing and a big reason for that again is not complying with all the cloud native principles which is like a checklist of 12 factors which we see that is not completely met today in our network functions. Automation today is done as like a wrapper around the big monolithic network functions rather than something which is built into the DNA of the function itself. Truly means that we are not following the 12 factor principles and management and configurations and deployment is all happening in extremely customized way for each type of CNF which is not what we are expecting and I think we need to continue discussing through this panel of a solution to the problem that exists and we can discuss that further. So great point Sanath. So your point is that primarily the Kubernetes actually automates the compute, storage and the network but there's still gaps in terms of how the network function need to be automated on top of the cloud infrastructure and I think it is a great point. So with that Daniel, what's your thought in terms of the cloud principle and how do you think that applies to the 5G? I think the notion Sanath really explained it really well around the fact that the packaging we saw from a PNF to a VNF and now CNFs in the first iterations of CNF hasn't changed that sign that you're now pulling a Docker file versus an ISO or just getting a bin from a vendor on a router. So I think this needs to evolve and the other thing that I think is important as we see the growth of the cloud service community is what impact it has on our networking infrastructures. I'm just thinking about the old management and service assurance like we used to use in the networks and now we're seeing well why don't we leverage for example a tooling that comes from CNCF like Prometheus directly on those boxes rather than having another layer of systems to try to do data collection. Those are things that as we look at cloud-native principles and we think about the CNF to me I think about the CNF on a 5G service but I'm moving more towards any network function even physical network functions can leverage a cloud-native principle in some parts of their design. I think as well as we live the burden of trying to go from a PNF which was close to go to a VNF where the burden of all those the ecosystem that is required to make evolve took time. So as we thought that VNF at CNF would go fast when it started and we'd be able to deploy in a few years we ended up like a decade later almost and still not the full promise because it took time for all the infrastructure to adapt. At the same time we see the growth of cloud capabilities and the evolution that goes in blazing speeds and this is where I think you would like to have your network evolve as fast and be able to adapt as fast as the cloud is evolving to leverage the immense learning that you get out of it. I have a particular pet peeve that I would like to be able to gremlin my 5G network rather than build a network which is around all ways of doing service assurance and resiliency. Why get my 5G core be as resilient as a Netflix system for example in the cloud would be that thing that every other would like because in the end your service is really more resilient and effective than having to over consume resources just in case some failure happens. I think this is one of the things operators would really try towards the evolve their services. The development and also leveraging the scale and the capabilities of cloud for service assurance and resiliency. Great point, Daniel. I think the scale in order to adapt the scale, the cloud native approach need to be applied to not only for the cloud infrastructure but also the workload which are network functions that need to change and adapt into the cloud native principles and I think it's a really great point. So with that KJ, what's your thoughts in terms of the cloud native principle and how do you think that it applies to the 5G? I think Sana and Daniel did a great job at covering the key points. I would go a little bit further. I also approach this from the point of view of the radio access network which again brings its own unique set of challenges given the extremely high level of distribution that it involves often the minimum being a few thousand sites to hundreds of thousands of locations for a large nationwide network operator and it's really useful to ask what are cloud native principles as it applies to networks of the scale and people talk about microservices and other things for cloud native principles but really what drives this is the need for automation the need for automation to help scale these networks to deploy faster to make changes faster to result problems faster and designing for that automation be it whether it's in the infrastructure deployment itself with zero touch provisioning automated software deployment pipeline with CI CD standardized fault and performance telemetry scaling of those network elements so that dynamic capacity or fault tolerance can be accomplished I think these are all design goals that are shared between what network designers have always wanted and what cloud native offers so I'd say design for automation is a key aspect of cloud native that really needs to be embraced by the 5G networks and aspects like stateful and stateless are effectively in support of that goal if you have stateless functions it helps you with automation it helps you with not having to have those bespoke models of making sure those state is maintained so I'd say start with automation the other aspect I would say which is relevant for cloud native principles is decoupling of the from hardware specific configurations as much as possible this is easier said than done this is still a very performance centric and intensive part of the stack but even here I think you know tools that say the cloud community has developed in terms of managing accelerators having standardized interfaces for those I think can really help pave the way for there to be true mixing and matching and operators really need this because there is an area where we do have a complex ecosystem and a supply chain where software is coming from multiple parties and without some kind of standardized cloud native approach you run the risk of sure people will give you containers but then you end up having to build a bespoke kind of collection of software to manage those depending upon which source they come from you haven't really made that much progress so I think having standardized cloud native principles really will help ease scalability of these kind of networks Thank you Gej, I think it's a great point that the container network function does exist for 5G but the real gap is like in a standard way of deploying that in a cloud native way especially a configuration management and automation that takes from top to bottom the service layer and the line layers like a ran and core you touched on and as well as the infrastructure because most of the time this network functions typically uses the custom configuration that are different for each network function even though they called us like a ran and core but each network function needs a different from the cloud and I think that's a great point that you touched on so with that I would ask one more question here which is there are CNF based deployment and we are saying that there is not a standard and I would like to hear the pain points that you know without the standard what are the pain points that primarily you guys see when you are deploying the 5G network or testing it in the lab so I would start with Daniel to watch your thoughts on this The problem I think is going to be some funny but I think the problem is a bit of the commercialization of the monetization of a CNF when you start to have open interfaces and more like a committee or open ways of doing the automation like using mechanisms like operators or CRTs or whatever we can think from the committee it's a different aspect from a VNF vendor or a CNF vendor that has his own tool set who wants to leverage that tool set so right now the trouble we have is we run our CNF they can run on a cloud native platform with a flavor of committees with the right extensions for operators but then you realize a lot of the wrapping around is done by the vendors to try to adapt to it rather than shield it or wrap it around their aura of automation to try to fit the old model of automation compared to try and leverage the mechanism that already exists so that's a challenge that's just thinking about automation the second thing is how to abstract the cloud platform the committee's infrastructure or any other separate augmented tools from the workload so actually I was at the CNF working group a few weeks ago and I said that right now we're testing the platform more than we're testing the workload so we're trying to figure out is a platform confirmant to run a specific 5G workload while in reality we should see is the 5G workload able to run on the platform and this is the approach that we see right now so for any operator right now in the world is we're trying to adapt to any CNF vendor with the way they are deployed and their tooling and the augmentations they do to operate the life cycle and automation versus well I have a common ground of a platform which is based on standard communities offerings and APIs and any other sigs that exist and can it run on it by default so this is the challenge I think industry wide every operator is dealing with right now Thank you Daniel it's a great point that the vendors does actually lock with their proprietary tool set even though it is a CNF and there is a lack of standard in the industry in terms of defining this container for function in a cloud native way using the Kubernetes methodology of CRDs and operators and I think it's really a great point so with that Sana what's your thoughts on this Daniel I think we are touching on some real interesting points here and there between KJ and Daniel and what you're bringing up right now so I think to address the pain points of deployment in the 5G I start with it all goes back to not following the cloud native principle so I want to bring up another interesting element that I have seen in this evolution which is not really happening the footprints are still very very large and the resiliency models are still based on the server type architecture like n plus 1 to n to n plus 1 things like that that was the server mindset now when you're moving into a cloud and you're defining everything in the containers it's all software centric word the reliability model has to change and why this is important because when you get the workload you need to deploy a very large footprint that large footprint requires much harder automation in all the proprietary methodologies coming from these vendors because it's not simple to decode their large configurations and their topologies in the container world so when you look at their large size I'm just trying to answer the question like where is the problem they are justifying the vendors providing these other functions that we are looking for the 5 9 reliability model that is why they're still large footprints which is of course very very operationally inefficient in smart cloud like at the same time the reliability model in the servers and now we're moving into the cloud and the containerized world has to change from not ever failing to fail fast and recover faster which refers to the degree of agility that you can have a thin lightweight cnf you have the ability as we talked about in the beginning of session the analytics are completely controlled by Kubernetes where it can scale, heal, manage the workloads it can help you recover faster and you can still get the same degree of reliability the other big problem falls around our degree of trust on the system that we are using we are probably just packaging our cnf containers but we are not leveraging the inherent characteristics of Kubernetes to actually heal, scale thin lightweight applications and get that degree of flexibility portability into our network functions I think the biggest pain point, one of the biggest pain points is this which actually brings their challenges in terms of automation you have a struggle with all these vendors with the large sized applications to deploy them, test them incrementally as we are doing in our DevOps team structure you know that the transformation happened in many different verticals across service providers not just technology but the culture, mindset, skill set everything is constantly changing and that one element is not helping us test iteratively and continuously work on improving our agility and portability the other big things I think we touched on again and again extreme customizations required by each cnf the way it's packaged and the way it expects everything around it to change like we Daniel also mentioned these cnfs are not expecting to conform to a cloud and exploit the capabilities of that cloud they're all coming in with their own baggage their own tooling their own analytics their own automation templates their own configuration models we need to treat them like cattle not pets and today they're very much behaving as cattle with this results in an increased complexity a very large operational overhead and I think these are all the kind of pain points that I can bring to the table and of course them anymore it is a great point Sanna I think you touched this pet versus cattle and this is an important mantra with respect to the cloud and that approach you know like really treating every workload as a as a cattle I think it's very important in terms of deploying this into the cloud and the network function vendors adopting that into the nature of the cloud is very important and also you touched the point that it is way of actually doing the whole automation I think it is very important point to note so with that if you talked about the challenges with respect to how the China network function is deployed into the network as of today and the need for cloud native automation not only on the infrastructure layer but from the top to bottom that's what primarily discussed about and also the challenges with respect to the multiple tooling and issues with the network functions are not truly cloud native so with that I would like to understand your perspective of you know like what do you like to see in the open source community and the standards and especially from vendors like what's your perspective on that so with that KJ what's your thoughts on yeah I think this is a really important question and I think that if you look at say the open source community Kubernetes and so on you look at standards like 3dpponn and so on they're kind of each doing a great job in their own silos but where I think the gap is in these two so far I think communities to really be working together and I think it's pretty critical because when you get into areas like network deployments for using cloud technology you're really getting into a situation where you have a mix of open source and close source you know for the most part network functions are very close source a lot of cloud technology especially Kubernetes and the infrastructure surrounding it is open source so it's really critical one one community cannot ignore the other and I think where for example we need some some improvements on both sides I think you know let me just start with things like Kubernetes I think the Kubernetes infrastructure to handle accelerators and other hardware variations there are some areas that could be improved there on the standard side I think we need also more participation from folks who are conversant and steeped in open source to be able to drive open use of open source more in the standards right and a perfect example I'll give you is say with Kubernetes there is already a lot of good tooling and technology to pull things like performance faults to do automation and so on but until the close source software that runs on it the workloads they don't agree on how those mechanisms are to be used you're still going to see this wide range of different implementations that use the core building blocks in different ways so I think you know in almost ironically I would say that there is a need for open source people to come into standards and influence standards in a way that they leverage open source building blocks more than they do today it's a great statement KJ I think I think the important message to note here from your points is that there are efforts with open source and standards and I think it is all not connected to bring together the holistic automation that are needed to make this cloud native approach possible with respect to 5G or even beyond 5G and I think it is a great point so without Daniel what's your thoughts on this I think KJ touched a great point so there's two levels of it so you need kind of an open source or community driven approach to cloud native automation and tooling from telemetry analytics close-up automation including how you define the infrastructure the workflow that needs to be deployed and the day 2 running config you need to find a way to make it more cloud agnostic or efficient in that way but that also relies on some things in the underlying frameworks to be consumable this way for example I think KJ talked about accelerators but it goes beyond like use of specialized accelerators you go to level of how we do network segmentation in communities how do we increase network profiling in communities those kind of things also needs to go and work together the challenge we have is to make those automation work in a better way using declarative models and the way we do cloud native automation and the new principles operators CRTs and others is how to consume it in the cloud and make the cloud not go overboard I'm always afraid of asking the cloud ecosystem to adapt to networking the networking ecosystem and change its ways for example we didn't think about this like PNF used to run with five nicks to do so those segmentations what we did we go to see communities and let's bring multiple interfaces because we don't want to change the way that the application is done so I think it's KJ was really right is you need to have an adaptation and everybody bring water to their glass of wine so that the cloud systems are able to adapt and be able to represent the requirements for telco needs also the VNF and the CNF and the way the vendors create the developers create those applications also change the mindset and adapt towards different ways of doing things in the cloud way of how to plug those systems together Thank you Daniel I think it's a great point Sana what's your thoughts on this where does the open source has to change in your perspective Kandan I believe great points by KJ and Daniel and what I would love to add is that I'm a huge fan of open source and really in this ecosystem and this evolution open source is the heart of everything like standards public cloud, private cloud, service providers that's what brings all of us together now what is it that we can do in the open source to talk about all the challenges that KJ and Daniel mentioned I think a big need for that is how do we standardize the deployment of these network functions in one consistent model like how do we get rid of all these vendors proprietary ways of their analytics, their tooling their configurations, how do we unify that there is a big need for that maybe open source is the best place to start and then we push those to the standards to basically bring it all together being service providers we need to prioritize that because this will help us realize our big goals and dreams of proprietary what is really ironic to me at the moment is that I've been working in the automation orchestration for the last five years and I know where the existing state of this is no matter how much we work it is still not faster, simpler, efficient it is not standard space to date we do this but we do more effort in automation than we leverage the benefits out of automation so Daniel mentioned something like declarative models I think we're losing that fundamental principle where we are not abstracting the complexities away from this underlining structure and at the same time we're talking about network sizing and all those more sophisticated fancier ways of automation on the top we need to address the fundamental problems at the root of this to extend the simplicity, the efficiency that would enable us to realize the much bigger dreams of our software-defined services and network sizing and all that that needs to be addressed and that needs to be taken care of at the open source level a standardized way of deploying these network functions a way for us to check mark all the 12 factors of the cloud-native principles in different ways configurations and how do we do that being service providers I think what do we do in open source and together with standards that actually solve this fundamental problem for all of us Thank you Sana and I think the panelist has shared their thought process around the gaps and what already exists and what are the changes that they allowed to see in the open source and standard community as well as from network function vendors adapting into the cloud-native approach and I think it's very clear that there are efforts on individual communities and standard bodies but there need to be a cohesive effort where this whole automation into an automation is exercised and in terms of Kubernetes it's a well proven technology for cloud-native approach of implementation extending that Kubernetes methodology in terms of not only for deployment of the container network function but also for into an automation would definitely bring harmony and full automation across all the layers infrastructure, the network function and the service layer and I think it is a great point and I think the community should come together and make that happen and thank you for joining our panel today and it is a great discussion and all panelists thanks for joining with us today Thank you Thank you