 Hello and good morning. I'm so happy to be here and to see you all at this cloud native telco day. Yeah, it's fantastic to be here in this lovely city, Valencia. I hope we will have an amazing day sharing experience and things we want to work on in our telco community. I would like to thank for the opportunity to be here and share our thoughts and learnings. I'm looking forward for further discussion during today. And yeah, I'm happy to take all your questions. I'm very excited to tell you more about our cloud native journey with the 5G Core and our learnings at Swisscom. So this talk will be useful for you if you are interested to hear about our experience and learnings from our cloud native telco journey of an ambitious team building a 5G-40 Converged Core at Swisscom. So unfortunately, Ruben is not able to join today. He is moving from Swisscom to AWS to pursue a new opportunity. But nevertheless, we prepared this presentation together. He gave me a lot of thoughts, ideas, helped me to get to the essence, what to present here. So I need to say a big thank you for you, Ruben, to help me to stay here today. And yeah, it was a pleasure to work with you. So now a little bit more about myself and my background. My name is Joshua Hiller. Yeah, I'm so to say a newbie in public speaking. But I work now science a while with cloud technology as well as cloud native technologies. So I started over 15 years ago at Swisscom as a system engineer or network engineer and recently moved to Australia to work for Telstra. But because of COVID, I came back or had a travel restriction we had in Australia. And now I'm working at Swisscom again as a product owner for the 5G subscriber management. I as well have a very strong passion about agile and lean way of building services. And yeah, during my time at Telstra, I really could experience in the daily work how agile and also using scrum could really improve our daily work and be able to be more innovative as well. Yeah, have more fun at work in the end. So yeah, who we are. So Swisscom is the major telecommunication provider in Switzerland and has one of the, let's say, best network worldwide. At Swisscom, we really engage in ambitious technology and cultural transformation towards cloud native readiness. In the end, we believe that it is essential component to keep thriving in this increasingly competitive environment. So at mobile networks, our group, we develop and operate this new 5G 4G converged core. We have been closely working with our network function vendor Ericsson in a agile setup. So we have people from Ericsson in our DevOps team, and we closely work together with them to build and deploy and operate our 5G core in the end. So we realized very early that it's not only a technology shift, it also is a transformation on skills, culture, and how we collaborate with each other. So there is this new technology paradigms where we need really a different mindset, culture, and skills. So on the technology challenge, there is really the skill gaps we see in the telco ecosystem. So there, yeah, we need new skills which are more software engineering to help to build these cloud native workloads in the end. So there we have this transformation journey where we embrace on the change. So we want to learn to forge new paths, to be more innovative in the end, to learn to permanently evolve our status quo, and learn to continuously improve ourselves. So these are three key pillars for our cultural transformation at Swisscom. Now, a little bit more about what I want to tell you today. So first, we start with our cloud native readiness with this cultural and technology transformation. Then a little bit about this rich CNCF ecosystem we can leverage in the telco space and as well the huge opportunity to really automate all our services in the end. And then our cloud native journey. So there I will tell you a bit about our hands-on experience and as well then on the third point, discovery and learnings. So there it's really about our findings which we mainly can put into four pillars. So one is about decoupling of network function, infrastructure or CAS. Then the other thing is about the configuration management where we see a lack of maturity in the moment as well more on the architecture standardization aspect as well then on the service observability. And last we have some call for improvements. I would like then to give some suggestion on where we need to work as a telco industry to make our end-to-end services really cloud native capable. So what we do, so I would like to tell you some more details about what we do at Swisscom. As mentioned, we engage in ambitious technology and cultural transformation towards a cloud native readiness. To be successful in this, we started to build a new domain. We call this mobile cloud native services where we brought together software engineer, telco engineer, cloud engineers. We even found new teams to build a service management tool which I will come on later and really have from a design view to an operating view to a life cycle view all the people in one domain to make this successful. Then yeah, we started to integrate this 5G network where we deployed this to our NFVI cloud for now. But on the other hand just half a year ago we started our public cloud journey. So we work now closely with AWS where we collaborate to bring our 5G core to the AWS regions in the end where soon they will also open a region in Switzerland. As well then as said before we started with two new teams building in-house a service management framework or tool. So there we at Swisscom really see that it's key for an operator or a telco to have this capability to design end-to-end services. So not only like the 5G core itself but really end-to-end that you can then operate network slices at a scale. And then also what we started is to go in a GitOps journey. So we already had the Etsy monostack to deploy network functions but we see that this was not so cloud native at the beginning so we started to build our own GitOps pipeline in the end to be able to deploy and lifecycle the 5G, 4G converged core. Now some more details on the Etsy mano. So I created as well some hashtags. I would very appreciate if you could maybe tell me your thoughts about this and yeah. Also if you have any questions around this so we have SEMA here which is our service management tool which is based on Etsy or we can design an ASTs so network service definition templates which then can talk to an NFVO in the middle. But on the other hand this SEMA is as well able to push all the YAMLs dot value or the stuff you need to be able to configure to the GitOps pipeline or to Git in the end. And here we also then have for the CNF lifecycle management we have the VNFM which then do the deployment towards the cars. And as well we are working on an automation on the Etsy gateway. But this here is like just half of the full picture because what's missing here is the whole end to end configuration management which where I will shed some lights on later. And then we have our GitOps pipeline. So here on the left side we get the software from our vendors into our artifactory. Then we have our overarching Jenkins pipeline where we have different sub pipelines to source software to get notification and trigger other pipelines. Then we have a configuration pipeline for the application configurations. We have an element manager pipeline and as well some test pipelines. And all this is based on the source of truth we have in Git. So everything which we configure or want to add to our environment we define in Git and then we use for the deployment of the containers we use flux to deploy like an AMF in this case. So it takes the config from Git then goes to the artifactory take the Docker image and the help charts and deploy the network functions. And then after this it's able to trigger the configuration pipeline which then use Ansible as well. Ansible is asking Git for all the day too or the application configuration and then push this configuration over NetConf to the CN apps in the end. So today the CN apps we have they are mainly using NetConf and there we see some other things I want to talk later about. And also here I created the hashtag on Twitter. So I'm curious to hear your ideas, questions about this. So yeah, during our journey we explored different things. We had a lot of learnings. So here we could group this we can group this like in four different pillars. So first is the we still see a lot of vertical integration with the appliance towards CAS and even underlying infrastructure which is mainly also due to telcospecific protocols and requirements in the end. Then yeah, missing configuration management capability for really the end-to-end automation. I will go deeper in the next slides. Then from the architecture side there we still see that from the standardization point there is still like a very monolithic view on software. And then another big topic is the whole end-to-end observability. I also would like to tell you more from our experience so far. So first on the independence between network functions and CAS infrastructure even pass. So their application were still not really decoupled to some extent. So we see that with them there's still like a vertical integration towards Kubernetes. So it's in our view not fully cloud native where you just deploy, kill, deploy, kill containers and even like have immutable containers or microservice in the end. It also, we saw that we often use this CRDs which in the end had dependencies and you could to some extent not deploy just any network function in the same Kubernetes cluster. And there also we see still like tight integration of different microservices. So this means that you could deploy a network function but then you would need to add some day one configuration that other pods or microservices will start. And this is something we really should avoid in a cloud native environment. Then also scaling especially on the user plane function is still very limited. It's mainly due to specific Telco protocols we need. So there we see that we still need to do upfront the very specific like low level design to be able then to at least to scale to the resources we define upfront. Then also something which is interesting is really this layer two segmentation. We in the Telco industry use a lot of VPNs to separate different networks. And now if you go towards public cloud, yeah they mainly offer you one VPN in the end which then you need to build a lot of overlay separation which makes the whole networking very complex. And still like the if you use your NFEI and then on top you have your CAS. It's still not very smooth all the upgrades. So sometimes we saw that we kill the network functions and we had to redeploy everything from scratch. Then more on the configuration management. So that's something which is very interesting. So we mostly discuss about deploying all the CNFs but then it's like building a house but in the end it's not finished. So all the interior is still missing like kitchen stairs, electricity which is like the day one configuration or the application configuration. So we have models to deploy a 5G core so the containers everything but then to configure there is a model still missing where you could go an abstraction layer on top in the end. So there we see that every network function like UPF, PCF they have their own business logic with their own details, their own like failover scenarios and this is just making us a lot of headaches in the end. Then there is still this yeah, NetConf versus the cloud native way of using like config maps. So you have like one central point you configure your network function versus more than immutable capability where you add the configuration of the application already during the deployment. So NetConf in the end is great but on the other hand you have very tight integration and it makes yeah, it's not very useful in case that you just can start, kill, start, kill any services. Then there is still the complexity of the networking so we didn't take this too serious at the beginning but now we try really to deploy this 5G cores in public cloud and there they don't offer all this telcos specific capability. So there we need to find solution to make this possible and really the last point don't try to automate Excel. Really focus on building configuration as a code so to be able to have on top then some abstraction model that because if you need you can build like one network slice but if you then want to build 20 network slice you just cannot automatically generate your day one configuration for this what we see till now. And then more from the architecture or standards. So we say that the standards today they are not really cloud native so they get in the way of decoupling so there is still the trap of monolithic applications where we as telcos think really yeah there are all the boxes like UPF, AMF and and and and you have your standardized interface but in the end this don't help us to really build like more distributed systems just a lot of microservice in the end building your end-to-end service and yeah there we really should go more towards a microservice design instead of a large service design as we have today with the SBA in case and then on top we have this complex failover scenarios from all the different network functions but there we think we really should leverage more than native capability of some like service mesh to build this failover scenarios between microservice instead to build a layer on top very specific to telco environments and then the whole observability so we are very happy to see with cloud native network functions that observability to some extent observability is already built in so it's very easy to retrieve metrics locks traces but still if you want them to get the end-to-end view it's still very hard to get this together so you cannot simply automate this so there we need rather maybe models to help us to be able to stick together the different network functions and then as well do this in the observability view and on the other hand we also especially in our case so that we have already quite a lot of tools in the observability space like the standard PEM FM tapping functionality for the traces which in the end not really go very smooth hand-in-hand with all the new technologies like Prometia, it's open telemetry and Jacker, Loki and all these tools so there we need to find the right solution and also because of the very specific telco protocols like the troubleshooting especially in distributed system it's not just straight forward so for some protocols you cannot just use Jacker for distributed tracing in the end so here would be our call for improvement so really the main point is reduced network function complexity we see more and more bigger network functions which including tons of microservices but in the end that just go in a direction that we treat as a CNF still like a pet so we try to troubleshoot here, here and instead of just deploy and if it's not working kill it, deploy it again so this mindset need to more and more evolve in the end so really avoid vertical integration and yeah sometimes we really need to redesign network function from scratch really with the cloud native principles in mind and then on the configuration management yeah we need somehow an abstraction or a model to be able to configure up to or many different network slices end to end so this capability is missing so there we think really it's a declarative and intent based automation for the configuration management is really the way to go and then on end to end service automation we really see the need as a operator that we want to run over 5G core workloads on any cloud and this is not yet really working what we see we still need months or even years to implement the 5G core we not can just hit the button and then it's deployed when we can do this then we already spend like half a year to make everything working and really also something where I saw now a new project which could help there it's really like a service API or like de facto standards to make the end to end automation working so with this I would end so that's our conclusions so I'm very happy that we started early at Swisscom we really put automation as a key so when we started to build this cloud native environment we said we want to start automate everything from day one and we really invested the time to understand the technology regarding end to end service orchestration or service management sorry we don't see this mature enough today so there we still see the need for improvements and we need service management in the end to run network slicing at scale and one key point is as well better adoption of cloud native principles to improve our life cycle management and the automation and in the end you really can simplify all this I told you now in one simple sentence so telco workload should not be special so it should be like any other standard IT workload in the end and I'm very happy that just a few weeks ago they announced this Niveo project which really I think like took into account a lot of topics we were I was talking today so I'm looking really forward to see this evolving and yeah that's it for my side thank you very much for listening to me it was a pleasure to be here and I would love to take any questions hello it's Paweł Pawlak f5 so you mentioned about the vertical stack so do you have any takeaways to how to move away from it any suggestions or lessons learned or ideas yeah what we see is still that we have this telco specific protocols like GTP which don't allow for netting and there also we think we need to look into like software solutions which will help us to to provide their more flexibility that you don't have there this vertical integration in the end and also like today we still need to use like Azure IOV for the hardware acceleration for the throughput I think if there we maybe could we do something with EPPF to make this much more flexible I see like AWS are offering solutions where they claim to almost achieve line rate so I think there it's really on the on some network blockings for Kubernetes which could help us to avoid this vertical integration okay thank you and one more question if you don't mind so do you need CNFs for 4G yes we are using it so we build a 5G, 4G converged core so we have CNFs which are including microservice doing the 4G as well the 5G part in the same yeah CNF in the end so have different interfaces and maybe even this is maybe suboptimal for running like really independent services in the end I personally also see like we have this very narrow way of defining CNFs like UPF PCF and all this but in the end if you watch the whole cluster it's more just like 100, 200,000 microservices in a cluster providing you a service and we do a lot of on top specific stuff to still be able to fulfill all the standards but I'm not sure if if we could maybe start to think a little bit different and more just let the microservices directly talk to each other of overall service mesh, GPRC and whatever is possible thank you thank you for your presentation I just wanted to know when did you start the journey for the 5G core transformation and is this the adoption? I would say we started two years ago where we like build it a first team looking into like mainly the 5G assay core so we started to build this from our network vendor the first they were like they just started to deliver this 5G core function as containerized workloads in the end so that was about two years ago but I need to say so today we don't have a productive system we are still working on because we said from beginning we want to use this change to cloud native network function to also automate everything and yeah we are heavily investing in automating the whole life cycle of this network functions in the end okay and did you start the same work for the radio access network? no not now it's really focused on the the 5G core or let's say 5G 4G converged core and really doing this together also with this thinking about we want to build end-to-end service where we build this service management framework on top in the end okay thank you how many people are working on this project? together we are now with service management and orchestration maybe a little bit more than 40, 50 software cloud and network engineers thank you thanks again for the presentation, great I have a question regarding around the whole relationship with the major telco vendors like Ericsson because you guys are built completely on them and get a lot of their early features early but then at the same time if you're creating this orchestration layer and being first to it and that's somewhat challenging let's say the telco ISV how are you managing that relationship? how are you bringing them to the table and saying hey we're going to run this in Kubernetes we're going to do this and this and then they're stepping back saying oh we don't support that yet you know so it would be great if you could like unpack a bit of that yeah very good question I guess we were very lucky that our vendor was one of the earliest to deliver their 5G assay network function as a containerized workload so we could start very early to learn what this means to deploy a network function into a Kubernetes cluster and they are yeah like using microservices but yeah it's a and because we are working very closely with our network function vendor so we have DevOps team where we have our network function vendor as well in the team so they are as well DevOps engineer so we get very close on also talking about improvements what's not working as we expected but it's still it takes a long time because there are in my view still many objectives in the way yeah to really get cloud native workload in the end okay thanks and do you see this work being able to kind of create some critical mass by maybe open sourcing some of this so that it you know challenges the ecosystem of it yeah I'm I'm I'm personally looking really forward for this Niveo project in the end because there I see it addresses all the gaps or a lot of the gaps we see during the last two years and I'm very keen yeah to talk more about this and I think that can be a right way to go to really improve network functions towards cloud native readiness thank you very much indeed you mentioned agile you mentioned DevOps and things like that and you've shown a few diagrams can you perhaps speak to your experience that you had with moving what you've built here in fact into day two into operations I think many of us still have nox and socks and you have like isolated DevOps people how did you change all of that when you brought your technology to to that arena yeah yeah honestly I have to say we are not yet in operation but still the way we want to go is really that we have the DevOps team really or like Sec DevOps team really managing everything so we are also questioning existing processes example yeah today there we use like net cool for all the the more the observe operation part of managing the different incidents and everything and there we now like started to use like pagerdue your ops genie which is much more built for DevOps team but then we still need to see how we integrate to the existing process for level 2 support and everything so there we are still in ongoing process I would say okay so perhaps next year you'll give us a talk on how that went yes yeah definitely okay so the last question a great presentation thanks a lot thank you I was thinking you are early starters are realized which is I mean impressive and I see you're facing a lot of challenges that other operators may not yet because they're still waiting a bit the landscape you have a lot of dependencies as well with suppliers vendors telco protocols and so on so the question is where do you see what is your goal your vision and have you quantified that when I reach my end goal but I have sold off my challenges the network looks like something right yeah you quantify the benefits like okay I did it I fully automated I see your challenges what is the finally the was it worth it finally what was the the benefit so the final goal would be really that we can use our service management infrastructure or tools framework really to deploy our workload we need to to provide telecommunication service over any infrastructure so we want to be able to design in the service management and then what is available where we get the best resources or whatever to be able to deploy it and as well to life cycle it so the whole CICD or also continuous testing is is a big thing in in this so in the able ads it's the automation is key if you want to operate hundred of network slices thank you okay thank you for all the questions and I'm looking forward to listen to all the following presentations thank you very much