Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Enabling E2E Observability via Open Source in 5G Telco CNFs - Tamas Zsiros & Henrik Saavedra Persson

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Enabling E2E Observability via Open Source in 5G Telco CNFs - Tamas Zsiros & Henrik Saavedra Persson, Ericsson

Ericsson is building CNFs for 5G being deployed in live operation throughout the world. One of the earliest challenges to answer when developing for a Kubernetes evnironment was how to enable observability (monitoring, logging and tracing) as well as configuration management for cloud native applications that need to interact with a multitude of management and visualization systems, some of which were created for the cloud (e.g. ONAP), and some which has long been established in telecom service providers' environments. To answer the challenge Ericsson has built a platform using open source projects straight from the CNCF Landscape. This session will show the motivations behind this undertaking, walk you throuh the architecture of the platform and discuss the benefits and challenges of using open source and cloud native for 5G networks.

https://sched.co/Zepo

A

Hello: everyone, my name is thomas jirosh and I'm here today with henrik savadra person uh and together we are going to talk to you about uh how do we enable and to end of severability why open source in 5g taco, cnfs cnfs? If you haven't heard the term before stands for cloud native network functions.

A

So let's dive right into it um a bit of a bit about the journey uh we are from ericsson and- and we have a very extensive experience in building platforms of the monolithic type that sort of makes software and hardware work as efficiently together as possible. So we we used in the past and we're still using hardware acceleration a6 custom, oss, kernel modules. You know you name it. We have it and we build software and hardware together to make it work as efficiently as possible.

A

However, there are quite many use cases uh where we have sort of moved away from that paradigm, moved away from uh the monolithic way of building things uh where we sort of run hardware and software together when we started using extensively software in the cloud native computing foundation, mostly in the landscape and mostly open source projects, um and and since we wanted to enable software development in a really cloud native way.

A

Inside of ericsson, we have decided to build a framework out of some of the selected software that we take from open source projects and enable them uh within eric's song to be used for techo purposes. For very, very you know, demanding use cases and applications. uh Of course, all the software that we take. uh We don't fork it. We don't modify it if we have to modify it. We work together with the community and and and contribute back to changes and sort of implement an upstream first strategy.

A

So we try to help the community as much as we can. Wherever uh there are, you know things lacking in other areas. We just take the software and make sure that they can fulfill the very strict requirements that their co-applications are sometimes put against. So what are these use cases and what are these demanding use cases and applications?

A

Well, let's see for 5g. uh If we look at the 5g uh core part, uh there is the user plan for mobile broadband. For example. Mobile broadband is basically all of the network traffic that goes through mobile phones. So all the streaming um all the videos, uh your emails, your your you know when you're working from home, uh potentially all that traffic goes through these network functions, so they of course, have very, very, very strict requirements on availability uh or on on service continuity, but also on network throughput.

A

uh Otherwise they wouldn't be able to handle. You know the network traffic for a whole country or for a complete region when it comes to mobile broadband, but I can also mention another application where we, where we create a management application that takes care of the management of the complete radio network, which typically consists of thousands, if not tens of thousands of of network elements that all needs to be configured and managed from the software perspective and, of course, monitored and and have checked uh continuously within the network, to keep that network operational.

A

That again generates a lot of traffic going towards the management nodes and those management nodes, of course, have to use the same software because the software lives in the core. I can mention radio equipment some of the radio logic. Now we are moving on to this platform. This framework that we have created out of cncf software, uh private networks have edge applications and so on. So it's it's very diverse, set of different applications, all with mostly very demanding uh requirements on the platform and and everything else around it.

A

uh We have recently started using this platform for the 6g test pad, but that is, of course, just a test pad, so what we are concentrating most on is 5g.

A

Then, of course, everything that we do cloud natively on top of this framework needs to fit in existing environments, existing uh terraco operators, uh real working and paradigm, and and and- and so um since- these are very complex applications made out of many many network elements, uh it's necessary to have some sort of management framework that keeps everything together, and this is where another linux foundation project uh the open network application platform projects comes into the picture, because that project uh implements a very capable management system that can sort of take care of the management of the cloud difference, infrastructure, but also the applications and the transport, and that helps us to sort of fit our cloud native applications into a traditional telecom environment.

A

What is the exact nature of the challenge? Well, let me show you uh a typical telecom operator buys software from many vendors and, if you look at the complete stack, that is true for for the different layers of the stack. So I try to show you in this picture the fundamental difference between a typical cloud native stack that you know a non-tech or player might do versus what the telecom operators needs to deal with.

A

So in in a typical cloud native stack, and let me try to draw here a developer uh picks some sort of cloud infrastructure buys capacity from a cloud infrastructure and then uh takes their own choice of kubernetes distribution.

A

uh Chooses some of the platform services, maybe builds that builds a platform out of those creates the business logic and then, if necessary, if the application's complexity really warrants, it uh creates management services. But everything is in one hand everything that is blue is coming from one player and the cloud info is coming from someone else in the telecom world. The telecom operator wants to go out and buy software from many vendors, so they might pick cloud infrastructure from one vendor or they might build their own cloud infrastructure.

A

Quite typically, telecom operators have a private cloud and either they build it themselves or ask a vendor for one. uh There is a kubernetes distribution and usually the kubernetes distribution comes with certain services uh and in a good case, uh all that and the business logic might be coming from one single vendor. So everything that is blue here is coming from, let's say from nokia or ericsson or whoever else uh then very typical- that the oss the management system and and the bss, the business management system is coming from another vendor.

A

So it's a it's an orange vendor and a light blue blender. This is sort of the best case scenario. The worst case scenario could look like cloudy fro from someone kubernetes with some services from someone else, then some business logic from another vendor or multiple vendors, together with some of some services from the cncf landscape and then, of course, oss and bss and separately.

A

All these needs to work together without extensive integration projects, uh because that would be just not cost efficient and what we have been relying on so far for for many many years is, of course, standardization uh and we participate in standardization and the operators participate in standardization. We together created things like 3gbp, where we agree on the interfaces. So, even if the operator gets software from many different vendors, it should work well together when it's integrated together, uh then of course uh standardization can be a slow thing and and can be accomplished.

A

Something and and technology moves ahead at a very fast pace. So what we have been trying to do as much as possible is to try to to refer to industry standards and and in many many many ways- industry standards, the standards these days are dictated by open source projects. So I'll come back to this point, but here it is super important to have things like the cncf landscape, to have the cloud native compute foundation and have own up that sort of creates a common denominator across the industry.

A

So how does this stack? Look like I mentioned the application development framework here you see the input for that is the cncf landscape, and you know these logos should be very, very familiar to you, so I will not go through these in detail. The idea is that all of these highly demanding applications can be built. On top of this framework, not just network functions which are standardized by 3gpp, but also any sort of application entire co-application can be built.

A

On top of this, this framework, then, inside the framework, we are sort of grouping things into different different groups. We have things that that take care of life cycle management. We have, of course, databases which are super important, since quite many of the telecom applications are very very stateful and then those states needs to be stored somewhere in in a cloud-friendly way. So what we do we take on databases into the framework and we ensure that we can lifecycle, manage those databases using, for example, kubernetes operators, configuration management, performance management and forward management.

A

These are very traditional, typical, theracore things. I need to be able to configure my network, so I I can set up the necessary interfaces and timers and behavior of the network. Performance management is basically monitoring. Looking at all the kpis and making sure my system is operating perfectly and fourth management is when things go wrong. I want exact indications about what has what went wrong and I need to see you know these.

A

In priority order in my management system, so I I or the ones who is managing the system can make the right actions hendrick will talk a little bit about how do we enable these things uh inside our framework, but it's very important to mention that that that, even though we have to extend here what is available in the landscape, it's important to have the interfaces going up from these cm pm and fm functions. Those are industry standard.

A

So above this we can have any kubernetes, of course, because the software here in in in the cncf landscape works mostly on any kubernetes, and our intention is to not to create a tie in between the framework and the kubernetes distributions.

A

It should be freely selectable by the telecom operator and, of course, underneath any hardware can live on top of it is the management system. The open network automation platform provides us the industry standard for the interfaces here for the cm pm and fm, but it it provides us much much more than just that. It provides us a technology source to build our management systems and, of course, we do many contributions back to you on up to make sure that that uh sort of we progress in lockstep with the open source community.

A

uh It gives us a reference architecture uh which makes sure that whatever management system we create will be compatible with any extensions others might be doing in this. Space interfaces and models are super important when it comes to the cm, the pm and the fm, because this ensures that any applications that we create using the application development framework will work with the third-party oss.

A

As long as that, third-party voices also follows the owner project and, of course, it's a standardized automation platform for making sure that all the life cycle management tasks that we need to do with our cloud native applications can be done efficiently.

A

So this is how basically uh the cncf itself and the landscape, and the software itself gives us the modularity uh towards the cloud infrastructure, but also the owner projects provides us the modularity on the northbound interface for the management interfaces.

A

uh Then I let henrik to go a little bit into detail of of what are the additional complexities uh and and how do we make sure that we we sort of fulfill all the requirements using the right level of abstraction.

B

So, as thomas already mentioned, my name is henrik's a better person and I'll give you a little more details into the complexity and abstraction that we need to address within the telecom domain as such.

B

So the first one, if we look into what we really provide like any other telecom vendors, is that we develop network functions or an nf, which is also called, which is typically uh so that's that software we really develop. But what really happens after that is that we hand that, over to the telecom operators that operate these network functions, so there's a clear software handover here, not even talking about different organization, but really completely different companies that develop and operate this.

B

So that's, of course, creates a completely different challenge in the whole devops flow as such, and that needs to be breached in some way.

B

If we look at into one specific network function, then it can typically be up to different 100 different microservices types and that it's really exists or creates a network function as such and if you go to the next level, uh looking at more like a network telecom network as such, it contains several different network functions and, of course, many instances of each network functions within that network and such if you look at what already existed before.

B

We went going cloud native and even 5g. There is an organization 3gpp that is standalizing the telecom domain, so there exists a lot of different standards already and, of course, those still needs to be fulfilled and customers are expecting that they are still fulfilled, going forward. The same organization, of course also how how to uh do the 5d as such, then, as thomas already mentioned, we have onap that creates expectation on how the different cnfs should be managed, and that comes in different areas.

B

One area is configuration management so by using netconfiang, but also how different data is exposed towards the management system.

B

So this, of course, this database can be performance, management, data, fault management, data or logs or trades as such, and if you really look at then a network function with this up to maybe 100 different microservices types, it can easily become extremely complex and costly to configure, manage them on individual microservices level and, of course, that puts also a lot of internal architecture, focus and details on how you need to configure these kind of things and then keep in mind that the one who actually operates didn't develop them.

B

So they typically don't have that kind of maybe deep knowledge into the architecture and such. So. What really the operator is looking for is a focus on how to manage, configure different advanced functions that they bought or want to actually run as part of the network. So an aggregated gpu from the network function. Point of view really helps to abstract this and give a meaning to to the operator that really need to operate the network functions.

B

Then, of course, looking looking into the cloud native landscape and cncf, we see, of course, that there is a lot of value in the kind of observability capabilities that is created within that ecosystem. But of course we don't see that this existing 3dp standards would just go away and this transformation would happen overnight.

B

So we really see that existing standards and the cloud native de facto standards that are happening right now will have to then will coexist for a long time. So this is really kind of the landscape that we need to be able to operate in and provide value both to our existing customers.

B

That you know still are maybe in them not fully going cloud native, yet so still more relying on existing standards, but also also, of course, we're able to provide all the kind of needed, and we see them the value that cloud native can bring and to give some two examples in this, uh I will first dig into the performance management where we say that we we would use one same core but allow it to be exposed in different ways and and this one core is really parameters that we use as the core infrastructure to provide performance management so like in any cloud native application.

B

Prometheus is continuously scraping, metrics from the different microservices that belongs into that network function and then, of course, depending on the different needs we have.

B

We can expose these metrics in different ways and what we, how we do, that is typically by developing different individual exposure services as we call them and- and these services typically are consuming, provided apis from prometheus and then providing an external data format that is needed for a different type of standards we need to to align to so, for example, in the own up case, there is a vase exposure service going back a little bit. Further.

B

3Dpp has already defined a standard since since long time ago, when it comes to performance management and the xml format that those files needs to have so that's another service, and and we can expose some data complying to that standards as well.

B

But then, of course, at the same time, we want to be able to provide it more in a pure cloud-native approach as well, so it's still possible to actually use grafana or similar tools to consume the metric directly from prometheus, and so this is a good example where we really try to bridge the existing standards, but also at the same time, we see how we can get the value from what really cloud native and provides as such, and this also enables us to provide different scope of the metric consumption.

B

We're typically, maybe one up and 3dpp has also the view of a bigger network and the telecom network view as such, whereas grafana also allows us to really drill down into mid individual microservices to really understand how how they're, performing or or if we can, you know if there's any kind of performance or errors that we need to address in some way.

B

If we look into that, then the the second area uh configuration management, where we also then try to to bridge this kind of different, uh more cloud native and the standard uh expectation from from the telecom domain and such so. What we've done in this area is to really clear us clear separation between the internal and external configuration model, whereas the internal model really focus. On the microservices point of view.

B

You know what that microservice is providing and, and configuration makes sense from from that point of view, uh whereas you can see, the external model is more driven from from potentially different standards yang, and these kind of things and and typically netconfian is what's expected from onapen and other existing telecom management systems.

B

I would say, and then, at the same time we have done a decentralized approach uh to to allow this kind of internal configuration to be as simple as possible uh for the individual microservices and and really allow the microservices to own its own configuration.

B

So, as you can see in a picture depending on the need, it might be as simple as some helm parameters when you're deploying that service, that is, is the way to configure it or you know a little bit more complex, maybe going for a config map or similar, but we we also see that there are some cases where those maybe are not enough. So really.

B

Microservice brings in uh its own configuration database to be able to handle, maybe a different type of configuration and maybe also the amount of configuration it needs to handle as such, but what's really really needed at the end. From from a telecom point of view, is this kind of system aggregated configuration point and that's really what the net config exposure can bring you.

B

So that's and, of course, when you need to configure onenote function, that really brings different services together and that's also, then, of course, uh the api or the configuration module there is, is more centric around the network function resource model compared to my the individual microservices resource model as such, and in many cases this could also mean that to configure a network function, you have to, of course configure magnitude of different microservices internally and which is really then handled by this exposure service here, and it could also in some cases, need a mean that you have to push the same configuration to several of different microservices because they have the same need, but once again to allow the microservices to individually own the configuration this is handled by the the netconf, so the exposure service.

B

So it's really pushed down to the individual's microservices.

B

So, to sum up, um what we see is that there is tremendous value in the whole cncfx system, even for telecom, and of course, that's really what we want to make sure that we can uh make use of and then breaching these different standards uh and then at the same time, also bring the whole cloud native um capabilities into our customers.

B

And what we have done within ericsson is to build this modular pulse or or framework, as we would like to call it that can really bring value to 5g and and of course, also to all other applications or network functions that we we are also moving towards cloud native as such.

B

But as you saw, I mean the management complexities is is extreme, and but here we see that onap is really helping to drive simplicity alignment as such, but we also see that open source helps to standalize. You know creating these defective interfaces that enables this modularity and, as you can see in the in the examples that allows us to to explore, support existing and new needs with this kind of independent different exposure services.

B

So with that, I'd like to thank everyone for for listening and that's all for us.