Guy Daniels, TelecomTV (00:24):
Hello, you are watching the Cloud Native Telco Summit part of our year-Round DSP Leaders coverage, and it's time now for our live q and A show. I'm Guy Daniels and this is the second of three q and a programs. We have a final show at the same time tomorrow. If you are a new viewer and joining us for the first time, then let me tell you about the format. This is your chance to ask questions on cloud native and how it impacts telcos. The question form is right there on the webpage and your questions come straight through to me here in the studio. As part of today's summit, we featured a panel discussion that's sought to identify the new roles required by telcos and what key skills are needed. Now the panel has been available to watch on demand all day, but if you have not yet seen it, don't worry because we will be broadcasting it immediately after this live show ends.

(01:28):
So don't go away. Keep your browser tabs open. Meanwhile, send us your questions. We have already received some, but we have plenty of time for more. As I say, just use that q and a form on the website and don't wait too long. Send them as soon as you can. Well, I'm delighted to say that joining me live on the program today are Diego Lopez, who is senior technology expert at Telefonica and an Etsi fellow, Greg Dalle, director of product Management service providers with F5 Ranny Haiby, CTO of Networking Edge and access for the Linux Foundation. And Francis Haysom, principal analyst with Appldore Research. Hello everyone. It's good to see you all again. Thanks so much for returning for this live show. Let's get straight into our first audience question, and let me read this one out to you. If Telco software engineers need to be multidisciplinary, will this mean smaller teams but with more experienced and higher paid members or do telcos risk stretching themselves and their resources to thinly Francis? We've heard about the need to have employees in the cloud native space who can do a lot of different tasks and different sectors, different domains, multidisciplinary as the viewer said there. What are your thoughts on this one?

Francis Haysom, Appledore Research (03:00):
I think it's important actually to step one step back from this question, which is the first thing that's going to drive a lot of these decisions is what is the telco or what is the vendor that's supplying the telco trying to achieve using cloud native techniques or integrating with non-cloud native networks, for example. And a lot of these decisions as to the skillset, the type of behavior, whether you need lots of what I would term low skill or a fewer number of higher skills is going to be driven by the actual requirement that you're actually trying to deliver. Now that's not to say multidisciplinary is often quite a good approach and a lot of cloud native, agile software delivery is using multidisciplinary approaches in order that you can have small, tight teams that can work in tight timescales, but that isn't always the best way to deliver some parts of a network or applications. Some parts need a lot more manpower. Behind them are larger scale solutions. So you're going to need a mix of ways of delivering a mix of skills depending on the exact requirement for what you're actually trying to deliver.

Guy Daniels, TelecomTV (04:25):
Thanks so much, Francis. So yeah, it very much depends on what it is you want to do and what your objectives are like a lot of things we talk about here on the cloud native Turco summit, thanks very much for that. Well, if there's no other responses to that question, we should perhaps move on to our next viewer question. And let me read out our second one for today. The question asks, is cloud native truly the best approach for all telecom's use cases? Now, are there scenarios where traditional infrastructure might still be more suitable? Greg, are you able to help our view on this one starters off on the conversation?

Greg Dalle, F5 (05:10):
Yeah, that's a great question because you might think that there will be only cloud native going forward. What we are observing instead is there are parts of the network or use cases where the traditional infrastructure might stay, especially in the area where a heavy data plane needs to be used, think fixed broadband, or even some UPS gilan services where the economics might lean towards a more integrated traditional type of approach rather than cloud native. What we are doing as a vendor is, if I take the example of GI LAN or N six LAN services, so firewall, calculating that, et cetera, we give the options to service providers to decide what is the format they want to use, right? So they can use containers and cloud native functions or they can use virtual machines or they can use appliances that are optimized for performance and we support the three things, but we're giving different experience to service providers.

(06:20):
So for example, if you want cloud native, you're going to use artifact repository as your way to get the software and integrate it with your pipelines. While if you want a virtual machine, you might just go to your F five support website and download the table. Or the way we do telemetry is going to be different for cloud native products versus traditional approaches. The way we do installation with helm charts or operator framework for cloud native products is going to be different from traditional products. So I think there are different options out there and cloud native and traditional approach are going to coexist. Even for one similar use cases, you could have a mix. So standardization enables control user plane separation, and you could have the control plane and live in a completely cloud native environment versus the user plane being in more traditional equipments. And that's enabled by the standards at 3G PPP for 5G or for broadband forum for fixed broadband. So I think there will be a coexistence, at least for a long time. We do see in cloudnative some performance optimization based on specific hardware, smart mix, dpu, et cetera, that might bridge a bit the gap with dedicated purpose built appliances. But yeah, I do think that this is a great question and we'll see a mix of scenarios.

Guy Daniels, TelecomTV (07:58):
Great. Thanks for your insights there Greg. A mix of scenarios. Well, we're going to get responses from all of you on this one. Diego, I'm going to come across to you next. What are your thoughts about whether or not cloud native is the best approach for all solutions?

Diego Lopez, Telefonica (08:13):
I just wanted to add a reflection on something that well, we are currently working, it's about the use of quantum technologies for enhanced the security or some other aspects in our networks, like for example, load balancing and the case that is something that is relying so much on physical properties as the quantum connections at the end. A part of it, probably what Greg was mentioning about the control playing or whatever is ancillary to what you're trying to do can be virtualized, be part of the cloud, be cloud native. So I believe that we are going to stay well basically forever with a mix with the proper mix of what we can achieve with the law of physics and we can achieve in the virtual world and trying to find the proper balance would be probably the real art of making the network cloud native.

Guy Daniels, TelecomTV (09:11):
That's interesting. Thanks so much Diego for that and trying to get that right balance point. Francis, we'll come to you in a moment, but Ranny let me come across to you now for your thoughts.

Ranny Haiby, Linux Foundation (09:21):
Yeah, so I think what we're seeing in our open source communities and what they're focused on is indeed this challenge of having some assets that are physical. I mean it's not a transitive state or anything. We'll always have parts of the telco network that don't make sense to cloudify, like think about the RF antenna. We can never put that in a cloud. So the unique, I would say expertise and challenges that are required for cloud native transformation in the telco world is are indeed, many of them are focused around this, I would say seamless integration of having part of your assets work in a cloud native way and very agile and software controlled, but interfacing with those physical, more static assets and providing a surveys that makes the best of both approaches. So my point is that having some non cloudified assets will be the norm moving forward, not an exception of course where it makes sense. I think large percentage of network assets can and should be cloudified, but we'll always have these physical things and the ities connecting those two seamlessly and providing a service.

Guy Daniels, TelecomTV (10:37):
Yeah, absolutely. Thank you very much. How do you interface and connect these two disparate areas? Thank you for that, Francis. Let's come across to you for your thoughts.

Francis Haysom, Appledore Research (10:48):
Yeah, I think building on what Randy sort of said, there's always a requirement for what you do in hardware and needs to deliver and Diego's comment on physics, sometimes hardware is your only way in which deliver. I think one of the challenges here is that again, we're kind of giving ourselves a layer cake of cloud native on virtualization, et cetera. So building on top of hardware, the reality is actually we really only have two things, software and hardware and the choices we're making in going to a cloud native architecture are choices of architecture and abstraction and delivery methodology that benefits certain types of applications, may not benefit other types of software applications. There are many things that are actually possibly still better delivered on a virtualized infrastructure. There are things that will be better delivered on bare metal, et cetera. And we need to consider that.

(11:51):
And I come back to my earlier is slightly honed, it's about what we are trying to do, putting the core routers in the center of the network, you really need to be focused on silicon and throughput. If you are looking for much more flexibility, the ability to scale cloud native is the way to go where you don't quite know what the performance needs to be or what the scale needs to be. So I think we're going to need a whole series of software and hardware combinations going forward in the network. There is no single magic wand.

Guy Daniels, TelecomTV (12:29):
No, absolutely. Thank you very much Francis and thanks everyone for providing clarity there. It was a great question from our audience and I'm pleased we covered it comprehensively there talking to great questions. We've got another good question in here from one of our viewers. Let me read this one out to you. What is the relationship between cloud native and APIs? There's been a lot of news recently about telco APIs. Are they dependent on cloud native? Well yes, there has been a lot of news recently. I think only this week or last week the Kamara news came out. Ranny, I think you're the best person to start us off on this round. So what are your thoughts? Are APIs dependent on cloud native?

Ranny Haiby, Linux Foundation (13:15):
Yeah, so indeed Kamara made an announcement and there was an announcement about the joint venture for exposing telco APIs this week. So a lot of activities and we see a lot of this activity in our open source community. So I would say on the surface of it, if you think about APIs and cloud native, they don't seem related on the surface because you may be able to expose some APIs from your network regardless of how it's architected. But if you take a closer look at what these APIs are and some of them are all about allocation of dynamic resources upon requests, that is initiated by API requests. So unless your network is architected in a way that can respond to that then that it's dynamic and that is software controlled and automated and can allocate resources or move resources or set up services, then these APIs will simply not work.

(14:09):
I mean you cannot provide an API that say provides quality of on demand, but if increasing the quality requires a technician to go to the cell site and plug in a new board, then it's not going to work. So as operators are thinking about implementation of these APIs and providing services to application developers, a lot of it is around the dynamic nature of services and features that are provided by the network to those applications and those cannot be achieved by a high degree of automation and agility, which kind of translates one-to-one to choosing a cloud native approach that will enable all of that.

Guy Daniels, TelecomTV (14:56):
Great. Thanks very much Ranny. As you say the link, it might not be immediately obvious between the two. Greg, let's come across to you next for your thoughts on this relationship.

Greg Dalle, F5 (15:08):
Yeah, look, I think they are somewhat independent, but you need to think about them at the same time because they both try to fulfill a common goal, which is to transform the network more in a platform compared to what we have today. And so when you build your strategy and your design, et cetera, you should think about those two things at the same time. And I think we maybe don't talk about it enough, but it's not just in the telco space. There is a shift in general in it to go from application centric to API centric, we have a survey at F five with enterprises once a year we publish it, it's called the state of application reports. And this year in our survey we found out that 41% of the enterprises we surveyed had more APIs were managing more APIs than they were managing applications. And so it's a big shift in terms of approach. And so all the strategy and design has to be done in conscious that there are APIs. And those APIs by the way, need to be secured. I mean the API security is becoming a huge, huge topic.

Guy Daniels, TelecomTV (16:32):
Yeah, great. Thank you. Thanks for that information Greg. Interesting stats there as well. Must look further into that. Francis, what about you? Is there an association between these two areas

Francis Haysom, Appledore Research (16:44):
Directly? Actually no. You can put an API on front of anything, any piece of software and deliver it. I think again comes back to the requirements. What is it you're trying to achieve? There are some api and if I loosely use the Kamara example, there are APIs within Kamara which are not inherently needing to scale or unknown scale or unknown demand. They are delivered by the network as it is at the moment. Things like location, location APIs, there are other APIs which are much more about network slicing, dynamic bandwidth on demand where we frankly don't understand what the capacity that we're going to do, the type of demand that we're going to do, the type of services that might start to use that one. And cloud native is really one of the fundamental things that allows us to do is to go into an opportunity with a view that I can scale it to whatever I need it to within certain limitations. So cloud is really, really important for things where we want to create those higher value dynamic on demands, on demand services for other things that are pretty static part of the network already we could use cloud native, there may be some benefits there, but again you can simply put the APIs in front of what is there already.

Guy Daniels, TelecomTV (18:10):
Great. Thanks very much Francis for those comments. And Diego, let's come across to you as well.

Diego Lopez, Telefonica (18:16):
Let me close with a reflection of one of the points that Greg made on security because one of the main issues that we have when you open the network to third parties as we are doing right now with the availability of APIs is how do you the operation of the network and how do you guarantee the isolation of the different connections that are shared in the network a certain moment? And this is extremely critical that you provide proper isolation and ways of cutting the different segments, avoiding to expose too much and to make that much whatever is beyond below the APIs to make too much accessible in case of a problem or any security issue. And precisely having these APIs built according to the principles of microservices and independent pieces that are running their own task helps a lot huling in improving this isolation properties.

Guy Daniels, TelecomTV (19:36):
Yeah, good points. Thank you very much for making those Diego. Thank you. Thanks everyone for those comments about the relationship with APIs and cloud native. Well, before we continue with our viewer questions, it's time to check in on our audience poll for the cloud native Telco summit. As always, we ask our viewers a related question and give a selection of multiple choice answer options. And the question we are asking this week is cloud native can deliver substantial benefits to telcos, but what are the main challenges to its adoption? And in real time here over on my right you can see the votes as they come in. Not a lot of overall change from yesterday, although we have had a lot of additional responses. But leading the way maturity of cloud native software from vendors, that is something that we do address tomorrow on the summit on day three of the summit.

(20:37):
And it's also nice to see that currently in last place difficulties in recruiting or hiring talent, which is very pertinent to today's theme on the summit. Now if you've yet to vote, then please do so. There's loads of time. We'll take a final look at the voting during tomorrow's live q and a show before we move on to next questions because we have a bit of time I was thinking whether or not we're just comment on some of those findings. And Francis, I know you've been saying on this show on our previous panel about it depends what you need, it depends what you've got to think very clearly what your objectives and outcomes are. But have you got any initial thoughts on the polling so far?

Francis Haysom, Appledore Research (21:22):
Yeah, I think the maturity of the cloud native solutions I think is a very interesting one. We are doing some work with customer laws that is very much saying that the situation when they are testing the applications is very much one of about 50% of them are beginning to become what I assume horizontally scaled cloud native applications, but the majority of the rest of 'em are still a kind of evolution of the virtualized and even the physical network boxes that have come before that one. And one of the problems I think that comes from that is there's lots of opportunities from cloud native, the agility, the scale, et cetera. But if you fundamentally just introducing containerization for example as a technology on which to host your existing very much transferred physical network function, et cetera, you haven't actually changed a lot. You're still probably tied very much to a specific box rather than the whole of the cloud. And you are introducing layers of complexity and abstraction which are in fact actually between the function and the software. So you've introduced complexity and not necessarily got all of the capability there. So I can totally understand why that's a key issue for suppliers. And I guess the second thing is really that's the major businesses, the telco, the network function. If we're not getting that right, that's the thing that we do need to get right.

Guy Daniels, TelecomTV (22:57):
Yeah, absolutely. Thank you Francis. Well this is a snapshot poll of our audience, all registered TelecomTV community members, but it has stimulated some responses and I think we're going to hear from all of you now. So Diego, I'm going to come across to you first for some comments about the findings so far.

Diego Lopez, Telefonica (23:15):
Just a comment about the other of the problems. You mentioned that the main concern is about the maturity of the software and that the ability of recruiting new talent is probably the last one, but it's quite curious because when the second or about to be the second has to do with organization changes and retraining that at the end, if you think about it, it's like well, finding the talent is not so complicated. Maybe among other, because the people that are now applying the jam, people that are now applying for the positions in telcos are let's say themselves cloud native. They have been trained in using Kubernetes containers and this kind of stuff well in a natural way because it's part of what we do in the labs when they're studying. But there is a problem in matching them with the existing teams and in matching them with the current structure. And I believe that there is probably is the real challenge. I tend to agree very much in that it's not. The point is about how we reshape our organizations that are very much focused, have been focused for a long, long time, let's say in the physical way of providing natural services into something that is different, basically has different challenges and requires a different organization.

Guy Daniels, TelecomTV (24:43):
Absolutely. Thank you Diego. And we did cover this area and talked about it during our panel, which you can see on demand and I'm going to talk to ran in a second, but Greg, I'll come to you next because on our earlier panel you were saying about the ability to find young people with say Kubernetes skills is a lot easier these days. The situation seems to be improving. What are your thoughts on the finding so far?

Greg Dalle, F5 (25:08):
Yeah, actually this is what caught my eye in this results is this difference between hiring seems to be not so much of a problem, but retraining and upskilling existing telco employees is the big challenge. It's really interesting to see this major discrepancy between those two items. And I think indeed it does confirm that service providers have found ways to reach out to these young graduates and to find the right talents. And I think there are various initiatives like organizing hackathons with colleges to get those relationships even before the students graduate, et cetera. So there are some techniques, et cetera that have helped solve the hiring challenge. So it's interesting to see that confirmed through the survey results. And then the upskilling is yes, it's challenging because obviously you need to learn a lot of new technology and it's a fundamental change and so it's going to take longer to happen. So yeah, interesting to see the survey confirming this.

Guy Daniels, TelecomTV (26:31):
Yeah, it's good point Greg, because the percentages for the upskilling and retraining, we're currently standing at twice that of hiring the new talent. We'll see how that goes over next 24 hours or so. Ranny, I want to come across to you as well, what are your thoughts on the survey so far?

Ranny Haiby, Linux Foundation (26:49):
Yeah, so I want to address two of the things that came on top. One is the retraining of the workforce. So this is again something the open source community has sent and realized a while ago, and there are many resources available from the cloud native computing foundation on education training. Some of them are even free of charge training, but there are many good resources there for retraining the workforce and educating. So a lot of good stuff there. On the issue of maturity, first of all, I'm not surprised that it came on top and what I suspect is that it's not just a simple question of mature immature, but it's more about having difficulties defining what is a cloud native network function. So I know that some vendors tend to say, oh, we run Kubernetes so we're cloud native, but what telcos expect are something completely different and a different approach to how you deploy and manage your network function.

(27:52):
So I think a lot of this sense of immaturity comes from this lack of clear definition of what is a cloud native network function. And this again is something that as a neutral platform and neutral organization, we are working with many of our members and the communities to create a better definition of what is a cloud native network function through our cloud native telco initiative where we work on agreed upon best practices for network functions but also test tools that help determine the matureness or cloud nativeness of network function. So yeah, I think that is a hot topic and the sooner we address that the better it'll be for both sides, for the vendors, system integrators and the telcos.

Guy Daniels, TelecomTV (28:41):
Yeah, great. And doing good work there as well on this very subject. Thanks everybody for those comments. So if you disagree with any of the findings in that poll and you haven't voted, then the answer is obvious. Go and vote now, have your say and make a difference in our final poll results. We still have time for more of your questions. This whole program is about answering your questions. Here's our next viewer question and let me read this one out. The rate of innovation and development of cloud native tools such as Kubernetes is so much faster than standards-based telecoms solutions. How is it possible to align work on these two activities? Interesting question, Diego, are we able to come across to you and get your initial thoughts on this?

Diego Lopez, Telefonica (29:33):
Well, I will start by challenging the base assumption that the rate innovation is faster. What is maybe the rate of a new versioning of a new version of the software for sure might be faster than the rate on which whatever technology is used. And I have a clear example. I was looking at this question thinking about it, I have a clear example. For example, we have been for a long time involved in an open source effort that is called OSM open source manual that is trying to provide orchestration first for the let's say traditional NFV approach and right now is evolving into something or has evolved and is evolving along the cloud native lines. OSM, which is a pure telco and is very much focused on telco use cases, is delivering a new version every six months and or less in some cases and is keeping pace with how Kubernetes and all the like is evolving.

(30:47):
The point is that when you have our semi production, then when you go to production maybe that you have to be more cautious in the process of incorporating a new version, a new version of the functions That's probably, I'm not going to keep pace with Kubernetes or cannot keep pace if just think about it with you radio technologies or whatever. There are things that are available technologically available that are not suitable for market or are not suitable simply because of economical reasons of the cost of deployment. So in summary, what I would say is that let's say the perceived conservatism of the telecom environment has to do much more with the install base that is huge and with the procedures that you have to follow to guarantee that there is a universal service that is one of the basic requirements which telcos have. So a boot contest that probably in the future if as we become more cloud native, probably we'll be more agile with respect to the software updates, with the service evolution, et cetera. But still we are the nature, the betting nature of the goods that we are providing to the public well requires that we are a little bit more careful about what we do than can be what you can see coming from the technology developers including ourselves and think about that, the pace at which for example, mobile manufacturers are innovating their versions. You have an iPhone every year or even more doesn't make you to buy a new phone every year. At least I don't and I guess that the average people don't either.

Guy Daniels, TelecomTV (32:44):
I wish I could Diego, I think I'm with you on that one, but as you say there in your answer, I think maybe the issue is perception, maybe this innovation disparity is more one of perception. Francis, let's come across to you. What do you think are you seeing the cloud native world innovating faster and being more prolific than regular telecoms, if you can call it that?

Francis Haysom, Appledore Research (33:06):
I think it's important to actually separate two things here. One is what is I think a hard, fundamentally a telco hardware standard function and a lot of what we do today in telco, it really comes from a history where we will take the generations of mobile networks for example, for me to commit to building hardware that will work with other people's hardware ahead of time. I need very well-defined standards. I need to know that the interface is going to work because I'm going to literally et etch it into silicon or into fiber optics, et cetera. The software delivery process is very, it's soft. You can quite literally code anything again given the laws of laws of physics. So a lot more of the interfaces of software quite often across the industry are much more evolved or are defacto standards rather than they are dejo standards.

(34:09):
And we need to understand that one. It doesn't mean that we don't want very strong integration standards in software where those things need to work, but we also need to balance that against the needs to do innovation or to do things quickly. I think the best example I can come up with this is in the open ran environment, Rakuten actually delivered a fronthaul interface between its radios and its base band using effectively a software hack effectively to knock gear. It was able to do that one, it only became a standard afterwards in terms of joining the open round community. So it wanted an interface, it wanted to be ahead of that interface and do things quickly. We also need to look at software more generally. We don't ask AWS to align with a software standard in terms of its APIs. We just use the APIs because they have become that facto standard.

(35:15):
So again, I may be standing like a repeated record here. A lot of these things are to do with what is the problem we're trying to solve, where do we want that agility, where do we want people to innovate on either side of an interface? You're more likely to get defacto standards where you need to have very clear boundaries, you need interfaces that are going to work and work over time, then you need that much more rigid standards process. And I think it's understanding them and where the boundaries are between them is the way in which we get these things to work together.

Guy Daniels, TelecomTV (35:48):
Okay, thanks very much indeed, Francis. And let's go across to Greg as well. What your thoughts on this perception of the differences in rate of innovation and how is it possible to align work on those two activities?

Greg Dalle, F5 (36:01):
Yeah, I think the broader question is for telcos, how do you balance working with open source projects and standouts and both are super important. I think 10 plus years ago when with NV in particular and other initiatives, what we've seen is telcos rebalancing their investment and their budgets away from some of the standout organizations. And I think the reality is you need to be active in both and follow what's going on in both open source projects and standout organizations. And one thing that I think is critical is a lot of those open source projects are not telco specific. They're used by other big end users, but if telcos want those projects to work for them, they also need to have a voice there. So let me give you a couple of examples. There is a project gateway, a p, which is a project in Kubernetes to do L four L seven routing. Well if you want this project to have telco use case, then you need to go and contribute there. If you are using Istio, which is an open source service mesh and you are having your network functions or your microservices communicate over these service meshes and we know that network functions are kind of unique applications, then you need to go and attend and let's say influence the priorities and the developments so that the telco use cases are taken care of in those open source projects

Guy Daniels, TelecomTV (37:57):
You need to take part. Absolutely Greg, and that's perfect timing for me to go over to ran as well for his thoughts on this question. Ranny, what would you say?

Ranny Haiby, Linux Foundation (38:07):
Yeah, I think the challenge of balancing the slow pace of telecom standards and the fast pace of open source is something that we've witnessed for about a decade now and I think there are many lessons learned, good ones and bad ones around how to do it properly. I think we have some success stories with open source projects that manage to bridge the gap between the cloud native world and the telco world example nephew that demonstrates how you can use properly cloud native techniques to deploy things like a three GPP 5G service. So I think that, and to touch upon what Greg said, I think it involved a lot of involvement from both sides. I mean we are seeing people from the standards world come to the open source communities and provide their expertise and make sure that things are developed in a way that is serving or addressing the needs of the telco industry and vice versa. We see people who are active in the open source world participate in standard definition and bring their knowledge and sometimes kind of codify in standard what was first developed in the open source world. So I think the main thing, the lesson learned is that the more individuals that have their feet in both worlds, the better things work and the better they are aligned.

Guy Daniels, TelecomTV (39:38):
Great, thanks very much Ranny. Thank you all for your responses there. Just getting another question in as we speak, but here's one we've got in about 30 minutes ago or so. Let me read this one out our next question. We all agree that security mustn't be an afterthought, but how can we integrate security into the entire cloud native development lifecycle without stifling innovation security question there. Francis, are you able to start us off?

Francis Haysom, Appledore Research (40:08):
Yeah, certainly. I think a very interesting, I think we need to be a little bit cautious about where were we before this one, A lot of where telco was is it had a kind of walled garden security. It could be on its own and to some extent it was kind of isolated from people really having the mass market to wish to specifically go into the specifics of a particular telco vendor for example. That world has gone really and in many senses the issues in a cloud native software are equally applicable in some of the more proprietary software that are being delivered today. They're still reliant on the open source initiatives and many of the open source software inherently software can be flaky, can be buggy, can have issues, can have vulnerabilities that is built in most things today, not just in terms of exposed cloud native.

(41:08):
The second thing I would say is that actually many of the best practices of security or DevSecOps are actually the ones you also want in terms of innovation. Faster time to deliver, faster, time to test, faster time to implement and implement in the network are very much characteristics of what you need to do in terms of a zero date and zero trust networks where you need to react very quickly and be able to deploy patches or solutions to security vulnerabilities quickly. Those are exactly the same behaviors that allow you to think about innovating and introducing new technology, new applications, new functions into the network as well. So I think here we need to be really careful the behaviors you want for a cloud native network are very much in line with the same ones that you want for secure networks.

Guy Daniels, TelecomTV (42:05):
No, great, thank you very much Francis. We'll come to Greg in a moment, but Diego, let me come across to you for your thoughts on the security question here.

Diego Lopez, Telefonica (42:13):
Basically I think that Francis made a very good point about the fact that the security issues are naturally being transferred from the physical approach to the cloud native approach. The difference is that probably he was more careful when talking about it and saying the wall garden normally I tend to say that the traditional security that we tell because have applied are about the big guy with the big gun at the door where we have the equipment. This is no longer valid. We had to rely on software security, but on the other hand we have much better tools and my experience working with as we developed cloud native services and we play with the security of cloud native services is that we have much more powerful tools for enforcing security on the one hand and basically for evaluating that security and the impact of the security mechanisms in the performance of those services.

(43:23):
As we try to apply then anti any problem or if what we're trying is to evaluate how a particular security mitigation technique will affect real service because in many cases when you have a security issue, the problem is not only what the security the attack is causing to your service, but this is well the required mitigations that require measures that you have to apply may impact the general service mechanisms and with virtualized cloud native services testing this in advance, getting some idea of what will be impact is feasible is something that we are now doing in twin environments of the network and this is something that is helping us very much in making more secure and better response in the case that there are any of security problem.

Guy Daniels, TelecomTV (44:33):
Good to hear. Thank you very much Diego and Greg, let's come across to you for your thoughts on this.

Greg Dalle, F5 (44:37):
Yeah, when I was listening to the question, it's reminded me of a point we made during the panel, which is in this cloud native environments, more and more telco employees will have to be multidisciplinary, right? They might have their core role which is, I don't know, network engineer or operations, et cetera, but they need to develop secondary expertise like being able to understand the economical aspects, the impacts of making certain decisions for example, or being able to develop a pipeline even if they are a network engineer. And so I think security is going to be one of those, call it the secondary area of responsibility that many roles in the telcos are going to have attached to. So that means for example, if you are a planning engineer, well you will have to worry about is a packet coming from, I don't know, a charging function supposed to be able to go to the radio network or if I get a random packet that exit the cluster, am I able to identify what was the source network function from this application? So I think everybody will have somewhat to understand the security concerns and factoring in their own role what they need to do to keep this environment secured.

Guy Daniels, TelecomTV (46:09):
Yeah, thank you very much Greg, for those points. I think we have time for probably one more question and we've just got a question in literally two or three minutes ago, this question came in from a European telco, so I'm quite keen to introduce it to our discussion now. It's a tricky little question though, so let me read this out to you and see if we can approach it. The question asks, would the regulations ever evolve to support a fully cloud native telco which allows operators to select vendors and solutions openly? For example, the sovereignty regulations limit how operators can innovate on cloud platforms to use this means there are limited to certain vendor solutions which may not be fully cloud native. Quite a lengthy question there, but coming down, and I guess this is particularly a European focus here with cloud sovereignty issues in there, but it's the allowing telcos to openly choose which vendors to work with. And if they're not, then maybe some vendors, let's be honest, are not fully cloud native and so therefore their choices could be restricted. Do we have any views on this one specific on nonspecific? Francis, thanks so much. Let's come across to you.

Francis Haysom, Appledore Research (47:38):
I think, and this was raised at the great telco debate in December. I think it's really important to distinguish between what is cloud native and what is different versions of the cloud infrastructure that you put your cloud native application on. I think if we're clear about that one, I think some of the questions about regulation come out of it, which is if I have a cloud native application and I have the ability to host it on a sovereign cloud in my area and I know a whole variety of solutions that are looking to give sovereign cloud specifically for telco, then if I've got the right cloud native application, then there is certainty in that. There is that ability to deliver as cloud native on that one, on a hybrid cloud, maybe on a sovereign public cloud or even a private cloud infrastructure within the turco.

(48:38):
All of that can be cloud native. The second issue in terms of the cloud native is that I think, and again it needs to be extracted, A cloud native application is made up of lots of moving parts. There's a supply chain issue in that one, we're consuming lots of open source, very, very strong open source in terms of those cloud native applications. But again, they themselves come with supply chain vulnerabilities and potentially where did that open source come from? So there's a lot of traceability and supply chain issues that need to be addressed. But again, they are addressable and there are vendors that are looking at the traceability of supply chains in terms of the cloud native technology that's either coming from a vendor or it's coming from the telco actually assembling that themselves. So I think those are the two things that allow us actually to deliver cloud native that in no way ties you to a specific cloud that shouldn't tie you to a specific cloud native application or a set of vendors as long as you're qualifying where the source of that software is coming from or where that cloud on which you're deploying it, he's actually hosted and who owns it.

Guy Daniels, TelecomTV (50:00):
Great. Thanks very much for that overview Francis. Great. And we're going to get comments from all of you on this. Our final question for today, so Ranny, I'm going to come across to you first and I'll go to Diego and Greg, but Ranny, let's see what you say first.

Ranny Haiby, Linux Foundation (50:13):
Yeah, so the question of whether you can innovate in cloud infrastructure while still compliant with the strict requirements of the EU kind of trigger the creation of the silver project open source project about two years ago. And this is exactly what this project is doing. And I think the proof is in the fact that they managed to release a few releases already and prove how you can take all the goodies from the cloud native world and cloud native infrastructure and deploy them for telco environment in a way that is compliant with the strictest of EU regulations and the dynamic regulations. So yeah, I think there's a lot of room to innovate and take the best of the cloud native world and apply to telco while still complying with EU regulations and other regulations across the world.

Guy Daniels, TelecomTV (51:03):
Yeah, thank you very much. Good to point out the server project there, Diego. Let's hear from you next please.

Diego Lopez, Telefonica (51:09):
Well basically if you want, it's a little bit, if you want to play football with are use in your hands, then you're playing rugby, not football, that this is about that. We have to assume that the telco business is being regulated and it's going to continue to be regulated in the future and we had to leave and to play with that rules. And in particular, if you think about it, for example, these sovereignty issues, well are not the heaviest regulations that we had to deal with. And I don't believe that this will be, they both impact, really impact innovation of the capacity of providing infrastructures and services that are flexible enough to innovate true. And I do believe that we have to, the regulation should be lighter in many, many, many areas. But in particular this one is, I would say that is, I would say it should be one of our list concerns at least in the sector.

Guy Daniels, TelecomTV (52:18):
Good to hear. Thank you very much Diego. And we'll finish off with Greg. Greg, what are your thoughts?

Greg Dalle, F5 (52:23):
Yeah, I think Diego would've said, actually there are three things for sure in life it's death, taxis and telco regulation. And so I don't think we can, it's not going to disappear. If people complain that telco standards are hard to move, then regulation is probably times 10. So it's a fact of life, we have to deal with it. And I assume the question was very specifically on the fact that in Europe and some Asian countries, the regulation makes that you cannot use let's say American clouds for example, public clouds vendors and your constraint in terms of location of the data, in terms of location of some of the, let's say the command centers or the control plane management planes, et cetera.

(53:22):
And also there are some reliability. So it's not just the data sovereignty, but there are also reliability requirement that make that the cloud has to be in country. So I think this is a fact, the public cloud vendors or providers are trying to adapt. So I think there will be ways where some of these providers will be able to still meet regulation and being country, but I really see that more as an opportunity actually for service providers to be involved in building those sovereign clouds and then go and provide those services to enterprises. So yes, it's a constraint, but I do think at the end of the day it's also a great opportunity to be a player in this rather than just consuming the cloud.

Guy Daniels, TelecomTV (54:21):
There you go. It's an opportunity. We do like to end on a positive note there. Thank you very much, Greg. We are out of time now though. Thank you to all of you who joined us for this live program. Do you remember to send in your questions for tomorrow's final live q and a show? As soon as you can. Don't leave it right to the end, otherwise we might not get to it. And please take part in the poll. There is still time for you to have your say. You can find the full agenda for day three of the summit on the telecom TV website. We have a panel discussion for you that investigates the growth of cloud native and the impact it is having on telcos. And we look ahead to future developments. Plus we take a deep dive into the fabulous world of containerized applications, cloud native functions and associated workloads. And remember, you can watch both of these programs on demand from tomorrow morning. And for those viewers watching us live, we are going to broadcast today's panel discussion immediately after this program. So please stay with us. I'll be back tomorrow with our third and final live q and A show, same time, same place. Until then, thank you for watching and goodbye.