The essential components of a cloud-native strategy
By Guy Daniels
Sep 17, 2024
To embed our video on your website copy and paste the code below:
<iframe src="https://www.youtube.com/embed/iFR77I9CgnQ?modestbranding=1&rel=0" width="970" height="546" frameborder="0" scrolling="auto" allowfullscreen></iframe>
Guy Daniels, TelecomTV (00:24):
Hello, you are watching the Cloud Native Telco Summit part of our year-Round DSP Leaders Coverage. I'm Guy Daniels and today's discussion looks at the essential components of a cloud native strategy. What are the benefits and challenges of adopting a cloud native approach and how should telcos develop and nurture a successful cloud native environment? And i'm delighted to say joining me on the program are: Kai Steuernagel, VP Cloud Technology, Group Technology, at Deutsche Telekom; Beth Cohen, SDN Network Product Strategy at Verizon Business Group; Sidd Chenumolu, Head of Product Management, Software-Defined Edge Division, VMware by Broadcom; Michele D’Agostino, Director of Product Management at Wind River; And Joan Triay, Manager and Network Architect at DOCOMO Euro-Labs, and Rapporteur for the ETSI ISG NFV.
(02:12):
Great. Well thanks very much everyone. Good to have you on this first panel of the summit. Well, after all these years there's still confusion over cloud native and what it means. It comes up year after year. We still hear that it's getting mixed up with cloud hosting and public cloud. Anything with the word cloud in seems to muddy the waters here. So do we have a clear definition of the cloud native telco and if so, what is it and perhaps what is it not? Beth, would you like to try and clear this up for us first and we'll go around our other guests as well?
Beth Cohen, Verizon (02:51):
So I think we have a definition, however, do we have a common definition? I'd say the answer is no, but the definition that I think makes the most sense is applications that are designed and optimized to work in the cloud. Now that can be containerized applications, it can also be virtual machine applications, so VMs or containerized applications such as applications based on using Kubernetes. But we also have serverless applications and we have other types of cloud native that really I think fit that definition. So what's primary to me is that the application was built and designed from the ground up to work in a virtual environment, whatever that virtual environment be may be.
Guy Daniels, TelecomTV (03:54):
Yeah, thanks very much. Beth, that last point there is good to reiterate. Kai, what about you? Do you think we have a common definition or is there an acceptable definition of what we mean when we talk cloud native?
Kai Steuernagel, Deutsche Telekom (04:08):
I think there is a definition of cloud native and I see maybe a little bit different. So I would distinguish between what is cloud native and we hear the term of CNF cloud native network functions quite a lot and sometimes it's misunderstood as containerized network functions, which is for me not the same. A cloud native application in the cloud native function is really built in mind to be running on a cloud infrastructure, which has all the benefits of the cloud infrastructure to scale automatically with the load and so on, which requires to be stateless to be event driven rather than stateful and kind of monolithic just containerized software environment. But this is not unique to the telco market. This is kind of also what happened years ago in the IT industry. The same also there once it was running on Kubernetes, we called it cloud native, which is not, there are some directives to make it. So it's important that we will reflect that we want to use the cloud in the way the cloud is intended to be used and not running it in different way on some computers.
Guy Daniels, TelecomTV (05:33):
Great. Thanks very much. Kai. It's important that we cover this ambiguity and everyone knows what we're talking about. Michele, let's come to you next. What do you see as the definition or what constitutes cloud native for you?
Michele D’Agostino, Wind River (05:49):
So for me, cloud native is a strategy to develop and deploy applications in the cloud environment. So in a traditional development you get this big application which is difficult to scale and maintain in a cloud native telco approach. On the other hand, you divide the functionality into microservices and containers, but if I wanted to put together a framework to define a cloud native telecom infrastructure, then it would be based on I would say four general principles. And Kay mentioned some of them. So of course it has to be based on microservices and container orchestration. It needs to support dynamic scaling based on demand. It needs to have automation and resiliency in case there are failures which need to be handled gracefully. And it should also include analytics tools based on A ML AI and ML in order to provide closed loop optimization, for example, for energy efficiency and sustainability in general, which is a key aspect for the Wind River cloud solution.
(06:48):
But if I want to add in addition to this four general principles, two that are very unique to telecoms, I would say that they fall into two categories. One is within the technology domain. So basically these cloud native deployments need to be designed to support 5G with the native integration of accelerators, for example in Intel rapid processors, but it should also support a geo distributed cloud for tens of thousands of nodes so that you can scale the network and you can ensure ultra load agency and high availability. And then there is another aspect which is acid to telecom, which is what I call the operational domain. So basically you need to be able to provide a service provider with a highly automated tool set including automated software upgrades and zero touch deployment, which is critical to scale the type of networks that we have within telecom.
Guy Daniels, TelecomTV (07:49):
Great. Well we're covering a lot of ground here and this is very good. Joan, let's come across to you next though. I know we've had this conversation before, but how do you see it now? How do you see cloud native?
Joan Triay, DOCOMO Euro-Labs (08:01):
Well, I can say what I not see cloud native, and I think it has already been answered by answered by others, but definitely to me, cloud native is not about the specific technologies, it's not about the specific solutions. And even if it might sound not very popular, I would even, as others have said as well, it's not even about containers. So we cannot be claimed that something cannot be cloud native just because it's not being deployed or operated with containers. For me, one of the aspects that I think it's quite challenging for the industry is indeed that it's very difficult to define it precisely, and I doubt that we will ever achieve that. One of the challenges here is that actually the world is becoming also kind of a marketing buzzword. So there are so many different opinionated perspective when we use the word cloud native.
(09:00):
But as I said, I think the important aspect and factories try not to couple the concept and the principles to specific technologies. Since technologies are evolving what might be now, right now the best orchestration system that we can apply does not mean that it might be the case also in the future in five years. And one final remark that I want to also express is that to me, cloud native, it's just also the consequence of all the concepts and visions that were initially driven by the creation of the N concepts as well. So there's no too much difference in between the two, so to speak.
Guy Daniels, TelecomTV (09:49):
Thanks very much for that. Sidd, did you want to come in here on this one as well?
Sidd Chenumolu, VMware by Broadcom (09:54):
Yeah, probably. I mean it's interesting while I hear everyone speak about it. So obviously it's clear that we don't have a common definition, but the intent is quite clear, everyone agrees to what it should be and what it means. So from my perspective, I've simply say cloud native is an ability that gives to service providers to deploy their applications using open APIs at the simplest form. But just to also augment one of the previous speaker point is there is a difference between the cloud native for enterprise or what is the cloud native for telco? I think just want to call it the difference that there is an expectation on the telco side to meet performance of the application that is on power with a custom silicon driven application hardware. When you look from that perspective, it's essential that we have a curated stack that can meet the performance needs of the application. And this is especially true for high performance workloads like DU at UPF, where you need to have access to the infrastructure, the compute directly with the specific network network APIs and things like that. So there is cloud native and there is cloud native for telco. I think that's slight difference, but again, I said the intent as to where the industry wants to go is clear. We may just not agree verbatim on the exact definition.
Guy Daniels, TelecomTV (11:24):
Yeah, I think you are absolutely right, certainly from what we hear, that is absolutely true. Before we go onto our next question, I just want to quickly come back to Beth though.
Beth Cohen, Verizon (11:31):
Yeah, I heard a number of people say, and I think it's important for us to not let the cloud service providers hijack the definition because I've seen that over and over again. Telco cloud is different and we need to keep that in mind, but I think a lot of service providers do tend to spread their definition of cloud cloud native is the right definition, but I don't think that's true. I think there's a number, as we've all talked about, there's a number of definitions and they're all right.
Guy Daniels, TelecomTV (12:13):
So what are the benefits of cloud native to telcos and what are some of the main challenges? Sidd, can we hear your views first?
Sidd Chenumolu, VMware by Broadcom (12:23):
Yeah, I think so. Number one benefit I would say is from the cost perspective, there's an expectation that the overall cost structure of the operations is going to be less by adopting a cloud native principles and its architecture. The ability for a service provider to do lifecycle management in an automated manner, both at the platform and applications is definitely a huge cost saving. But to augment that, I would say if you have no custom tooling, that's a cost saving tool because with the cloud native, you can adopt the best tool sets out there and there's no, what do you call one-offs. The third I would say is the packaging of the applications on the infrastructure where you can get hardware efficiencies. So there's a cost benefits, but equally important is the service benefit. Now, I know for a while as an industry, we have been talking about curated connectivity for enterprises based on demand basis, whether it is through network slicing or APIs.
(13:33):
Now again, if you take a step back, these APIs are at the exposure level, but for an orchestration system to allow these APIs to offer a service, the orchestration system needs to manage the underlying infrastructure and the application, whether it's about the scaling or configuration and cloud native deployment allows them to do it in automated manner and fast. So there is a benefit from the cost and services both. But again, there are challenges as you said. So number one is that right now we are looking at a spread of deployment, whether it's pet set, whether it's A VNF or CNF microservices or cloud native, there are quite a few out there. So there needs to be convergence of those and how to manage them. But more importantly, I think we need testing. We need testing at scale for both platform and application in order to introduce new services, not only for performance and conformance, but also for negative operational scenarios that I have seen.
(14:35):
That's one area that has been neglected quite a bit. And the last, I would say in terms of not as much of a challenge but more of a mindset change. The cloud native tool sets are not managed by standards and telcos are used to looking everything from a standards perspective, CNCF, which is more of an industry body that looks at the developer ecosystem and what is the uptake of different tools they manage those tool sets used for cloud native, I think. So there is bit of a mindset shift that not everything needs to be standardized and we may want to go with the tool sets that broader industry and get the benefit of it.
Guy Daniels, TelecomTV (15:17):
Yeah, thank you very much Sidd. We've got a few responses to get through for this question, but Kai, let me come across to you for your perspectives from Deutsche Telecom on this one.
Kai Steuernagel, Deutsche Telekom (15:26):
The key benefits of going for cloud nativeness for us is really to be able eventually at that time then to scale our network functions up and down with the load. So the app isn't so hard, the down is difficult part, and why would we do that? So while you're in the public cloud, you're concerned about costs of the service, we are concerned about cost and in general the energy consumption. And so we need to come up with a way to scale kind of the network loads so that in off peak times we are able to use less energy and turn finally than even service off in the environment to get there. But that's not the extent to that. That is just kind of the easiest or kind of the low hanging food we are after. The other things are we can easily update the service.
(16:33):
So with the concept of microservices and cloud native, each service and microservice can be updated independently without impact to the others, which brings a huge benefit to the operations of the networks. And so we can finally also come to some sort of DevOps approach, changing our operations way, how we operate these networks is essential to that. So we also have to do some homework. This is a challenge, but these are the benefits of that. And at the end, if we go the full length of that, at the moment we are struggling with updating to new network generations. So in the mobile network we have updated from 4G to 5G, and now we are bringing in six G in 2030 and there might be 70 G already in the mines and eight G and whatever. But these generation shifts are unnecessary if we are in the cloud actually.
(17:36):
So it was necessary in two G and 3G and 4G because we bought in new appliances and different hardware, but now we can run it essentially on the same hardware. The lifecycle management of the Harper is independent of the network generation. And so when we have an iterative approach to update the service and features of the networks, then we can spare new technologies like six G and so on. Maybe we need it for marketing reason to have something shown on the mobile phone, but that should be extent from the network technology once in the cloud. It's not necessary all generations any longer.
Guy Daniels, TelecomTV (18:22):
Yeah, I think your comment today will resonate with a lot of telcos, a lot of our viewers. We certainly get feedback thinking along the exact same lines there, this is great. Joan, let's come across to you next for comments on the benefits and perhaps the challenges of cloud native for telcos.
Joan Triay, DOCOMO Euro-Labs (18:39):
Yeah, thank you. So yeah, I agree with many of the benefits that have been highlighted. I'm not sure if it has been forgotten, but I would say that I would also highlight one about the automation. It's quite essential or quite visible that cognitive can be a real true enabler for introduce more automation in our networks. But if I focus more on the points of challenges, I would like to highlight maybe four that come to my mind. One is about how Cloudnative is actually changing our shape of the current status of the telco operators that need to provide long-term support for services. Introduction of cloud native with a much shorter time to market, faster upgrades and so on can actually create quite an important challenge to the operator on trying to adapt its kind of operations to this new form. So I see that quite a big challenge and something that can actually make difficult for the operator to adapt to this new environment.
(19:49):
So more efforts on trying to improve the ecosystem on how to understand the needs for operators for providing support is very much appreciated. One other challenge that I see, and it's a little bit related also to the concept of the definition of cloud native, it's about not being coupled to specific technologies. So there is quite danger situation that by adopting specific solutions or technologies, the operators might also get coupled locked into a certain ecosystem which would probably and of course not be a good endpoint. And finally the one that I would like to highlight is it's also a little bit related to the kind of operations that we're doing as an operator. One of the key aspects of Cloud Nativeness is also about the introduction of more declarative driven management, which is quite good and it's very important. However, we need to really understand whether all our kind of operations that we perform on our networks can really be translated or can really be performing at the ative manner.
(21:11):
And I don't really have a good answer for that, but some of the examples that come to my mind, how do you perform troubleshooting or how you perform root cause analysis and so on that in the past we had our own procedures, our own workflows to perform that when we transition to the dec quality way of work can create some big trouble for the operator. So in a sense, I would say that if we can all together work on trying to cope with these challenges, you will make also the concept and cognitive much more appealing for the operators.
Guy Daniels, TelecomTV (21:52):
Thanks Joan. All good points there. Thank you very much. Michele. Let's come across to you next for comments.
Michele D’Agostino, Wind River (21:58):
Yeah, so I just wanted to make a comment. So I've seen that the benefits and challenges have been extensively covered already, and I would definitely agree in terms of challenges that security of course is a challenge, but also performance, especially in a telco cloud network where basically the network has to match the KPIs of the traditional run. But I just wanted to add an additional benefit of cloud run technologies, which is the fact that with this you get an easy version control in terms of software configuration management. So basically you can upgrade only the layers or components that you want to upgrade. So for example, in a CAS stack, you have the infrastructure, you have the host, you have the cas platform, you have the Kubernetes layer, and with cloud native approaches you can update all these components independently. And I think that's another key advantage benefit which was not mentioned before.
Guy Daniels, TelecomTV (23:02):
Great, thank you very much for that. Let's go across to Beth as well to round out this set of answers, Beth.
Beth Cohen, Verizon (23:10):
There are challenges and advantages both and many of them have been already mentioned, but I think another consideration is that cloud native is actually a more complex environment. There's a lot more interactions than the traditional proprietary box or hardware-based environment. So where we're disaggregating the hardware from the software, the advantage of course is as Joan mentioned, that you can upgrade the software without upgrading the hardware. So you're separating those functions and obviously you can use APIs and you can use other mechanisms, but you do lose efficiency in some ways. You gain efficiency because obviously you're using the hardware more efficiently. Although I would argue that telco workloads tend to be pretty steady, so that elasticity that web workloads take advantage of is less important for telcos. But we also lose efficiency in that when we do need to do a hardware upgrade. It's extremely expensive and extremely painful. So as I said, as we've all said, there's trade-offs.
Guy Daniels, TelecomTV (24:38):
So we've talked about the benefits and challenges, but how does a telco actually develop and grow a cloud native environment? And also how does it ensure it is a success? What are some of the main components and tasks required? Michele, let's start with you.
Michele D’Agostino, Wind River (24:56):
Thank you. That's a great question. So first of all, you need to have a solution that is architected to deliver operations at scale across the whole life cycle. That means day one, day zero, day one, and day two operations. And you need to be able to perform all these operations on tens of thousands of knots within a single maintenance window. So in general, rather than building a technology which is only targeted to IT or enterprise, you have to be focused on requirements which are specific for the telco market. And for 5G, for me that means three things at high level. First of all, ultra low latency and then operational characteristics such as zero touch deployment and zero touch upgrades. And then of course carrier grade, which is required to deliver the high level of scalability, residency and redundancy, which is required in telecom Telecom. So for example, we need to be able to provide the famous five nine availability in order to ensure that the network is always available.
(25:58):
And then there is another very important piece in my opinion, which is the fact that to be successful, you also have to constantly innovate all the components of the telco cloud ecosystem, including for example, the cost layer by for example, augmenting the kubernetes capabilities for example. You have to be made sure that additional security is added because of the sensitive nature of telco workloads or need to add more observability. And I'll give you two great examples of this type of innovation which contributed for Wind River, for the Wind River class platform to be ranked number one in a recent study that a BI research published where basically they looked at all the 5G cost platforms and they ranked all of them. And of course I'm very proud and excited about the result. But what we have done as two examples of innovation is that we have number one developed an innovative solution for reliability which provides self feeling.
(27:03):
And that's very critical, especially in a distributed network where you have thousands of edge sites. And then another great example of innovation is in the area of total cost of ownership. And as all the people know on this panel, I'm sure this has been a recurring argument used by cloud native or in general open run detractors. So what we've done in this space is we have developed a very resource efficient solution so that the whole cloud platform can fit into one core. And with this innovation, not only we deliver for the cost of ownership and reduce the footprint, which is what operators want, but in addition to that, we make available the course for other services and other workloads which the customer can run for revenue generating services or even to run new network elements which have recently been visualized. For example, the sell side router.
Guy Daniels, TelecomTV (28:06):
Thanks very much, Michele. Let's go across to Sidd now to bring Sidd into the conversation At this point, there's a lot of elements required to make cloud native success in telcos. What do you think are the main components and maybe some of the tasks that are required to do so?
Sidd Chenumolu, VMware by Broadcom (28:23):
Yeah, I think in the previous question what Joan and Beth covered, I think those are some of the areas we should address here. Also, I think Beth covered like this is complex, right? As that deploying a cloud native applications and platform are complex. Got it. Then also Joan covered about long-term support for solutions, and I think he said something about troubleshooting that we need proper information and how to troubleshoot in cloud native environment. So those are the key things. I mean the reality is that today in the network for most service providers, majority of the deployments are vfs. There are few CNFs and there are far fewer ones that are actually microservices or cloud native based. So from a service provider point of view is looking at a gamut of deployment types and to the points that Joan mentioned, that you need a solution that is automation driven and also coupled with assurance in a single management plane that can manage all this vnf, CNFs, cloud native applications in a unified manner such that when an operator decides to migrate from one type to the other, there is minimal to no service impact. I think that is the key. Similarly, day zero deployment is half the battle in my opinion, the day two where we continue to get the benefit of cloud native is by not falling into the original trap of having long maintenance windows. I think I would rather see people putting more effort into no impact upgrades such as inline upgrades or cannery upgrades and not so much doing a long maintenance window. I think that's where we'd see most benefit ability to introduce new applications and services at a faster rate.
Guy Daniels, TelecomTV (30:14):
Thanks, Sidd. Interesting focus on day two there. That's great. And let's come across to Joan now because you referenced some of his earlier comments. So let's hear from Joan now about some of the main components and tasks required to make this a success.
Joan Triay, DOCOMO Euro-Labs (30:27):
Yeah, one component is more organic sessional, it's more about the company. So if the companies are not transformed to embrace the concepts and the principles of cloud native, it's going to be very difficult to make it a success for a TechCom operator. And that implies changes in the organizations like creation of dedicated teams. For example, in our case, we are turning into a cloud-centric and service provisioning organization where there are dedicated teams that perform all these set up for the whole network, not just only for a dedicated domain in the network. As a mobile operator, we need to provide end-to-end and covering different areas from access to core. And it is quite essential that the organizations in itself are also adapted to make it a success story. And from a system perspective, I would say it is very important that it's created in a way that the operator, I mean I'm speaking on behalf of an operator, it has visibility of that platform and that infrastructure.
(31:49):
Ideally it should be a unified and common infrastructure and platform that can cover all network domains so that we can really streamline the generation of new services in a common manner, whatever they need to be deployed. And that is just only the underlay for the success. But if we are not able to actually connect that underlay platform to our OSS systems or our orchestration systems, it's always going to be a break point. And for that, one of the ways to make it a success I believe, is to put more efforts on actually making all those enablers in our platforms be with the standardization by reusing open source solutions and so on that enable all the hooks so that our network reconciliation that is performing the acquisition systems in the higher layers can really benefit of using that platform. So I would say that if we achieve that, it is very likely that the operator will see some success in the end on adopting the technologies.
Guy Daniels, TelecomTV (33:07):
Great. Thanks Joan. Clear goal there. You mentioned, well, let's get some views from our other operators on the panel. Kai, let's come across to you first then we'll hear from Beth, but Kai first,
Kai Steuernagel, Deutsche Telekom (33:17):
So I agree with most of what was said. So yeah, stable infrastructure, we need performance, we need reliability and availability of the whole, that's kind of clear. And that is what we also, when we look at do telecom and our platform, our cloud platform, it's a self grown ca platform, which we call TCAs Telecom in the beginning for sure. What was not yet said was kind of what is around that. So it's not only a Kubernetes platform, there's a lot of orchestration and things around, so we want to have a declarative approach when we deploy things. So all that stuff, it was mentioned here and there in different words also, that what is very important at the end is that we are following industry standards, that we are not trying to reinvent the wheel once more and that refine solutions that kind of all our network suppliers can say, okay, yes, I can use that.
(34:28):
I can build upon this infrastructure upon this foundation you are providing here, which is the challenge we are currently seeing and this is what we need to approach for. And there are a lot of open source components, tools and so on which we're using. There's one more approach to that, which is the silver project, an open source initiative to have a reference implementation of a telco cloud stack, which then also gets where network function suppliers can then validate their application to run on the silver stack. That is one way to go forward. We haven't yet implemented it in Doche telecom, but that's what we are looking at. So this is an important thing to get there that we have a standard way of onboarding new applications in a way, even if we swap out the cast layer and put another product in, whatever, that shouldn't matter, but the interfaces to the network function should be harmonized in a way that I don't need a separate cloud platform if I change or have another region in another network function supplier.
Guy Daniels, TelecomTV (35:48):
Thanks so much Kai, and as I was mentioned before, the last thing we want is any disruption of any kind as well. Beth, let's come across to you for thoughts on how do we grow and nurture this environment and make it a success.
Beth Cohen, Verizon (36:03):
I think there's two things I'd like to talk about. Several people have mentioned day two. I think that clout for telcos day two is really important, right? Because at the end of the day, we're most of the time during the life cycle, we're in day two, we are maintaining and supporting these functions. So I think that many of our vendors don't tend to pay as much attention to day two because of course they're selling us something that they're focused on day zero and day one more. And I think there's a disconnect there, and I think that has led to some issues in the community, but I think more importantly, we haven't really talked about it yet, but I'd like to bring up the open standards. And it's not just standards, it's the open source community. Because increasingly telcos have traditionally sort of said, oh yeah, well, we have to develop standards and then we will all abide by these standards.
(37:13):
But increasingly standards and open source are two sides of the same coin. And I think we need to use both. We have reference architectures that, and I'll mention the one that I'm most active with, which is the anate reference architecture. And in anate, although we started it about six years ago with the idea that it would become kind of a standard, what it has evolved into is a guidance and for how to stand up and deploy and manage these infrastructure environments with the idea that the vendors that are creating the applications that sit on top of these environments can be informed about how the environment will work with their applications. And that's a key gap. That's been a gap for I'd say a while. In my work, I tend to work with the vendors that are sort of higher up in the stack, so the security vendors and the SD-WAN vendors, and they don't tend to pay as much attention to the underlying infrastructure as I think that they should. The wireless vendors that are creating the CNFs and vfs, I think do pay more attention to the infrastructure, but the vendors I'm working with don't, because they tend to have solutions that are boxes and they're more proprietary. And I think we as telcos need to break them of that habit and get them to see the value of working, having these applications work within the cloud native environments.
Guy Daniels, TelecomTV (39:13):
Great, thanks for those observations, Beth. Really important. We've still got a couple of points I want to get through on this opening panel, and Beth, I'm going to come straight back to you for our next one because I'd like to ask if there is any agreed way that we can measure performance and success of implementing a cloud native workplace?
Beth Cohen, Verizon (39:34):
Well, there is no standard I can tell you that. So most companies look at it from two perspectives, and I think one we have a better handle on than the other. So many companies look at capitalization and cost efficiency. So how much does it run in day two? And I think we do in fact see cost efficiencies for running things in day two. Although as I mentioned earlier, it's complexity to actually get into the fine points of that because the other component is the efficiency and the ability to be more flexible, which doesn't tend to drive down, costs it to, it gives us more opportunities to add new technologies quickly and add new services and more revenue sources. But at the same time, there's a cost to running a system that has that flexibility. So in terms of trying to measure all this stuff, it's very difficult. I mean, I argue with our finance people all the time about how do we capture the costs of running these services? And there's no one answer,
Guy Daniels, TelecomTV (41:03):
Well, this is really good that there's no one answer because there's plenty of viewpoints here as part of our summit, and we're going to hear a few more now hopefully. Kai, what do you think, Kai? Do you think that we have a way of measuring this or we need to find a way of measuring success?
Kai Steuernagel, Deutsche Telekom (41:22):
It's hard to measure, I think the success of that. So at the end, it'll take some time in order to see the operational effectiveness of that coming through. The first thing I would, okay, this is a success if I'm able to really scale down the network functions and save energy, and so the build is getting smaller on the energy side, then it would say, okay, for us that would be a success. There is more to that and we need to get to that also to what we talked on before. I don't want to repeat the whole stuff again and again, I think to get there, we need to adopt what is there now and develop it further.
Guy Daniels, TelecomTV (42:06):
Great. Thanks very much, Kai. Well, I'm going to come to Joan in a moment, but Michele, let's come to you next.
Michele D’Agostino, Wind River (42:11):
Yeah, so I definitely agree that it's hard to measure success. So if I look at cloud native metrics, normally I would look at performance, resource usage, application health. But more specifically for telco, we must say that traditional networks have been deployed for a very long time and they've undergone a lot of optimizations performing at five nines or more. So in the context of telco networks, the cloud native deployment should compare to these traditional macro networks in terms of performance and reliability. So in other words, the performance of the cloud native deployment should be acceptable by the CSP as good or better than the traditional run performance. And I have some experience with that. So for example, in Europe, which is where I'm based, we have deployed the Wind River studio cast platform with Vodafone, and Vodafone has set the bar very, very high. So basically they looked at the KPIs of the cloud native based networks, and they compared them with KPIs from the traditional run vendors, which have been deployed for a very long time.
(43:18):
Now the good news is that the Vodafone itself announced in many events, including at Fuse in October last year, that the open run KPIs that were measured were at parity and in some cases even better than those of legacy equipment. So for me, that's quite encouraging. And in fact, Vodafone announced the same results of, showed the same results within a demo which was demonstrated on mobile called Congress in February. So performance is very critical, but then you also have to look at scalability and data operations, as Beth was saying. So when it comes to scalability, the network should be able to scale from one single server to how to even to a national data center, and it would be ideal if the whole infrastructure could be monitored from one single pane of glass. And then lastly, regarding lifecycle management or day two operations, I definitely agree with Beth that that's very, very important. So it's very important. So upgrades are extremely critical and it is important that you are able to upgrade 10, 20, 30,000 sites within one maintenance window. So for me, that's definitely an important success criteria. So they too, I fully agree that is something to pay attention to.
Guy Daniels, TelecomTV (44:44):
Great. A lot of consensus on this particular issue. Thanks very much for that, Sidd. Let's come across to you next for your thoughts please.
Sidd Chenumolu, VMware by Broadcom (44:52):
Yeah, I think I probably comment at it a little differently. We need to define an objective as to the why. We're even talking about going to cloud native help in the first place. This is about modernizing the network and offering new services. So perhaps we start looking at that, what the real objective is, and then start figuring out what the total cost of ownership that is resultant because of that migration or modernization, what you want to call it. It could be from a services driven, it could be from an operations driven from any other perspective, but for every operator, if the objective is different, then it's very hard to standardize something. So I think that's where I come, just start with an objective and just consider cloud native Telco as more of a framework or operational process to achieve that.
Guy Daniels, TelecomTV (45:42):
Thanks very much Sidd. And Joan. I think you wanted to come in with a comment as well, so let's come across to you.
Joan Triay, DOCOMO Euro-Labs (45:48):
Yeah, I fully agree also with others and I will add a little bit more consensus in what I already heard. I think that is also the way to measure success and the metrics that we should use from an operator perspective is whether our networks are more efficient, whether we are saving money, whether we are able to monetize it better, whether we are able to create new services. This should be really the metrics that we can identify and use as a way to measure if our adoption of cloud native is useful. I've come across sometimes from some questions or analysts or reports trying to figure out whether if the introduction of key tops or whether my VNS are running on containers or not as a way to measure if I'm successful or not. And I think it's very useful to understand that there are these kind of aspects to understand because these are really all aspects that need to be considered, but I'll not use them as a way that we can define if we are on the right path of being cognitive and the right path. As I said, I believe is more from what as an operator we can deliver.
Guy Daniels, TelecomTV (47:05):
Thank you very much indeed for that. Thanks everyone. It's been a great conversation. We are rapidly running out of time though, so perhaps I can ask one final question and get some quite concise short answers from you all because I do want to round this out by just asking how telcos themselves can contribute to the cloud native ecosystem, the developer ecosystem, and ensure that their requirements receive attention and support. Kai, can I start with you please?
Kai Steuernagel, Deutsche Telekom (47:33):
Yeah, sure, absolutely. Try to make it short. So three things to mention, starting to use what is there, there's some of the network function suppliers have some solutions which are not yet in the market. They have been delivered, but no one is using them now. So let's start with that in order to get the industry to develop further and so on. So this is my number one. The second thing is we need to drive also into the open source market projects like silver. I mentioned before, I know KA mentioned by be, but that is kind of the obvious things. We also see other projects where we need to involve further and that brings me to my third point. We need to work shoulder and shoulder with the IT industry in that space because their world is turning three times faster than the NT world to be honest.
(48:34):
Take an example of Kubernetes and 5G. It was started to develop at about the same time. 5G is here now, but Kubernetes is there for long. If we now define it, I was asked about what is kind of the cloud requirements for six G? And I said, yeah, cloud native easy. But then I thought again, 2030, what is cloud native in the IT industry in 2030? I don't know at the moment at serverless. So where are they going to and do we need to maybe shorten our innovation loops a little bit in order to cope with that and to better kind of take what was developed there to even improve?
Guy Daniels, TelecomTV (49:18):
Oh, great points Kai, thanks very much. And especially that last one about looking ahead five years and trying to see what definition's going to be and how far part of this cloud native community will have come in that short time, who knows. Beth, let's come across to you for your final thoughts on this question.
Beth Cohen, Verizon (49:36):
Well, I want to build on what Kai said. Please participate in the open source and standards communities. Your requirements are key to the success of these projects.
Guy Daniels, TelecomTV (49:50):
Perfectly said, absolutely we want to see more telcos participating in these communities. Joan, let's come across to you
Joan Triay, DOCOMO Euro-Labs (49:58):
Same as so, but I will add a little bit more emphasis on actually participating in standards as well. So I think that for a long-term sustainability of telco business, we do still need standards. We need to promote a lot more the interaction and the change of information requirements use cases in between the open and the standard communities. And by experience, I believe that from the telco perspective, participation of standards is also very beneficial. And even more in the case that some of the operators have already reused the standards or frameworks in their development of the early phases of virtualization and cloudification, like for example, using the H-C-N-A-V framework and so on. And we need to steal the support of all the operators and vendors to drive the standards, create use cases, requirements and all that. I believe that is going to be quite essential for the open source communities, therefore afterwards, sorry, to actually develop solutions that then we can adopt. And I believe that that kind of synergies in between the two. As it was also said before that there are the two sides of the same coin. It's very, very important.
Guy Daniels, TelecomTV (51:25):
Thanks very much. And Sidd, what are your thoughts? How can telcos contribute?
Sidd Chenumolu, VMware by Broadcom (51:31):
Well, first I would like to acknowledge that telcos are already contributing heavily into this one. So almost like any year ago you see that te, the NGM man release its manifesto for cloud native telco, right? We can build on top of that. Definitely keep more detailed requirements based on that manifesto, but also the CNCF, the CNTI working group has released the test vectors and test criteria for what a cloud native telco means. So there is definitely work being done, but to echo Kyle's point, we should adopt what is there already instead of waiting for something that's going to come down to the future. I think we should take the first step and put a timeline as to how and when these cloud native aspects would be introduced to the network so that it gives confidence to the developers to keep going with it.
Guy Daniels, TelecomTV (52:20):
Yeah, absolutely. And we need the developers. Thank you very much indeed for that comment. So thank you everyone for your comments. We have to leave it there though because we are out of time for this first panel debate. I'm sure we will continue this during our live q and a show later today. For now though, thank you all for taking part in our discussion. And if you're watching this on day one of our cloud native telco summit, then please send us your questions and we'll answer them in our live q and a show, which starts at 4:00 PM UK time today. The full schedule, the programs and speakers can be found on the telecom TV website and that is where you'll also find the q and a form and our poll question For now though, thanks for watching and goodbye.
Hello, you are watching the Cloud Native Telco Summit part of our year-Round DSP Leaders Coverage. I'm Guy Daniels and today's discussion looks at the essential components of a cloud native strategy. What are the benefits and challenges of adopting a cloud native approach and how should telcos develop and nurture a successful cloud native environment? And i'm delighted to say joining me on the program are: Kai Steuernagel, VP Cloud Technology, Group Technology, at Deutsche Telekom; Beth Cohen, SDN Network Product Strategy at Verizon Business Group; Sidd Chenumolu, Head of Product Management, Software-Defined Edge Division, VMware by Broadcom; Michele D’Agostino, Director of Product Management at Wind River; And Joan Triay, Manager and Network Architect at DOCOMO Euro-Labs, and Rapporteur for the ETSI ISG NFV.
(02:12):
Great. Well thanks very much everyone. Good to have you on this first panel of the summit. Well, after all these years there's still confusion over cloud native and what it means. It comes up year after year. We still hear that it's getting mixed up with cloud hosting and public cloud. Anything with the word cloud in seems to muddy the waters here. So do we have a clear definition of the cloud native telco and if so, what is it and perhaps what is it not? Beth, would you like to try and clear this up for us first and we'll go around our other guests as well?
Beth Cohen, Verizon (02:51):
So I think we have a definition, however, do we have a common definition? I'd say the answer is no, but the definition that I think makes the most sense is applications that are designed and optimized to work in the cloud. Now that can be containerized applications, it can also be virtual machine applications, so VMs or containerized applications such as applications based on using Kubernetes. But we also have serverless applications and we have other types of cloud native that really I think fit that definition. So what's primary to me is that the application was built and designed from the ground up to work in a virtual environment, whatever that virtual environment be may be.
Guy Daniels, TelecomTV (03:54):
Yeah, thanks very much. Beth, that last point there is good to reiterate. Kai, what about you? Do you think we have a common definition or is there an acceptable definition of what we mean when we talk cloud native?
Kai Steuernagel, Deutsche Telekom (04:08):
I think there is a definition of cloud native and I see maybe a little bit different. So I would distinguish between what is cloud native and we hear the term of CNF cloud native network functions quite a lot and sometimes it's misunderstood as containerized network functions, which is for me not the same. A cloud native application in the cloud native function is really built in mind to be running on a cloud infrastructure, which has all the benefits of the cloud infrastructure to scale automatically with the load and so on, which requires to be stateless to be event driven rather than stateful and kind of monolithic just containerized software environment. But this is not unique to the telco market. This is kind of also what happened years ago in the IT industry. The same also there once it was running on Kubernetes, we called it cloud native, which is not, there are some directives to make it. So it's important that we will reflect that we want to use the cloud in the way the cloud is intended to be used and not running it in different way on some computers.
Guy Daniels, TelecomTV (05:33):
Great. Thanks very much. Kai. It's important that we cover this ambiguity and everyone knows what we're talking about. Michele, let's come to you next. What do you see as the definition or what constitutes cloud native for you?
Michele D’Agostino, Wind River (05:49):
So for me, cloud native is a strategy to develop and deploy applications in the cloud environment. So in a traditional development you get this big application which is difficult to scale and maintain in a cloud native telco approach. On the other hand, you divide the functionality into microservices and containers, but if I wanted to put together a framework to define a cloud native telecom infrastructure, then it would be based on I would say four general principles. And Kay mentioned some of them. So of course it has to be based on microservices and container orchestration. It needs to support dynamic scaling based on demand. It needs to have automation and resiliency in case there are failures which need to be handled gracefully. And it should also include analytics tools based on A ML AI and ML in order to provide closed loop optimization, for example, for energy efficiency and sustainability in general, which is a key aspect for the Wind River cloud solution.
(06:48):
But if I want to add in addition to this four general principles, two that are very unique to telecoms, I would say that they fall into two categories. One is within the technology domain. So basically these cloud native deployments need to be designed to support 5G with the native integration of accelerators, for example in Intel rapid processors, but it should also support a geo distributed cloud for tens of thousands of nodes so that you can scale the network and you can ensure ultra load agency and high availability. And then there is another aspect which is acid to telecom, which is what I call the operational domain. So basically you need to be able to provide a service provider with a highly automated tool set including automated software upgrades and zero touch deployment, which is critical to scale the type of networks that we have within telecom.
Guy Daniels, TelecomTV (07:49):
Great. Well we're covering a lot of ground here and this is very good. Joan, let's come across to you next though. I know we've had this conversation before, but how do you see it now? How do you see cloud native?
Joan Triay, DOCOMO Euro-Labs (08:01):
Well, I can say what I not see cloud native, and I think it has already been answered by answered by others, but definitely to me, cloud native is not about the specific technologies, it's not about the specific solutions. And even if it might sound not very popular, I would even, as others have said as well, it's not even about containers. So we cannot be claimed that something cannot be cloud native just because it's not being deployed or operated with containers. For me, one of the aspects that I think it's quite challenging for the industry is indeed that it's very difficult to define it precisely, and I doubt that we will ever achieve that. One of the challenges here is that actually the world is becoming also kind of a marketing buzzword. So there are so many different opinionated perspective when we use the word cloud native.
(09:00):
But as I said, I think the important aspect and factories try not to couple the concept and the principles to specific technologies. Since technologies are evolving what might be now, right now the best orchestration system that we can apply does not mean that it might be the case also in the future in five years. And one final remark that I want to also express is that to me, cloud native, it's just also the consequence of all the concepts and visions that were initially driven by the creation of the N concepts as well. So there's no too much difference in between the two, so to speak.
Guy Daniels, TelecomTV (09:49):
Thanks very much for that. Sidd, did you want to come in here on this one as well?
Sidd Chenumolu, VMware by Broadcom (09:54):
Yeah, probably. I mean it's interesting while I hear everyone speak about it. So obviously it's clear that we don't have a common definition, but the intent is quite clear, everyone agrees to what it should be and what it means. So from my perspective, I've simply say cloud native is an ability that gives to service providers to deploy their applications using open APIs at the simplest form. But just to also augment one of the previous speaker point is there is a difference between the cloud native for enterprise or what is the cloud native for telco? I think just want to call it the difference that there is an expectation on the telco side to meet performance of the application that is on power with a custom silicon driven application hardware. When you look from that perspective, it's essential that we have a curated stack that can meet the performance needs of the application. And this is especially true for high performance workloads like DU at UPF, where you need to have access to the infrastructure, the compute directly with the specific network network APIs and things like that. So there is cloud native and there is cloud native for telco. I think that's slight difference, but again, I said the intent as to where the industry wants to go is clear. We may just not agree verbatim on the exact definition.
Guy Daniels, TelecomTV (11:24):
Yeah, I think you are absolutely right, certainly from what we hear, that is absolutely true. Before we go onto our next question, I just want to quickly come back to Beth though.
Beth Cohen, Verizon (11:31):
Yeah, I heard a number of people say, and I think it's important for us to not let the cloud service providers hijack the definition because I've seen that over and over again. Telco cloud is different and we need to keep that in mind, but I think a lot of service providers do tend to spread their definition of cloud cloud native is the right definition, but I don't think that's true. I think there's a number, as we've all talked about, there's a number of definitions and they're all right.
Guy Daniels, TelecomTV (12:13):
So what are the benefits of cloud native to telcos and what are some of the main challenges? Sidd, can we hear your views first?
Sidd Chenumolu, VMware by Broadcom (12:23):
Yeah, I think so. Number one benefit I would say is from the cost perspective, there's an expectation that the overall cost structure of the operations is going to be less by adopting a cloud native principles and its architecture. The ability for a service provider to do lifecycle management in an automated manner, both at the platform and applications is definitely a huge cost saving. But to augment that, I would say if you have no custom tooling, that's a cost saving tool because with the cloud native, you can adopt the best tool sets out there and there's no, what do you call one-offs. The third I would say is the packaging of the applications on the infrastructure where you can get hardware efficiencies. So there's a cost benefits, but equally important is the service benefit. Now, I know for a while as an industry, we have been talking about curated connectivity for enterprises based on demand basis, whether it is through network slicing or APIs.
(13:33):
Now again, if you take a step back, these APIs are at the exposure level, but for an orchestration system to allow these APIs to offer a service, the orchestration system needs to manage the underlying infrastructure and the application, whether it's about the scaling or configuration and cloud native deployment allows them to do it in automated manner and fast. So there is a benefit from the cost and services both. But again, there are challenges as you said. So number one is that right now we are looking at a spread of deployment, whether it's pet set, whether it's A VNF or CNF microservices or cloud native, there are quite a few out there. So there needs to be convergence of those and how to manage them. But more importantly, I think we need testing. We need testing at scale for both platform and application in order to introduce new services, not only for performance and conformance, but also for negative operational scenarios that I have seen.
(14:35):
That's one area that has been neglected quite a bit. And the last, I would say in terms of not as much of a challenge but more of a mindset change. The cloud native tool sets are not managed by standards and telcos are used to looking everything from a standards perspective, CNCF, which is more of an industry body that looks at the developer ecosystem and what is the uptake of different tools they manage those tool sets used for cloud native, I think. So there is bit of a mindset shift that not everything needs to be standardized and we may want to go with the tool sets that broader industry and get the benefit of it.
Guy Daniels, TelecomTV (15:17):
Yeah, thank you very much Sidd. We've got a few responses to get through for this question, but Kai, let me come across to you for your perspectives from Deutsche Telecom on this one.
Kai Steuernagel, Deutsche Telekom (15:26):
The key benefits of going for cloud nativeness for us is really to be able eventually at that time then to scale our network functions up and down with the load. So the app isn't so hard, the down is difficult part, and why would we do that? So while you're in the public cloud, you're concerned about costs of the service, we are concerned about cost and in general the energy consumption. And so we need to come up with a way to scale kind of the network loads so that in off peak times we are able to use less energy and turn finally than even service off in the environment to get there. But that's not the extent to that. That is just kind of the easiest or kind of the low hanging food we are after. The other things are we can easily update the service.
(16:33):
So with the concept of microservices and cloud native, each service and microservice can be updated independently without impact to the others, which brings a huge benefit to the operations of the networks. And so we can finally also come to some sort of DevOps approach, changing our operations way, how we operate these networks is essential to that. So we also have to do some homework. This is a challenge, but these are the benefits of that. And at the end, if we go the full length of that, at the moment we are struggling with updating to new network generations. So in the mobile network we have updated from 4G to 5G, and now we are bringing in six G in 2030 and there might be 70 G already in the mines and eight G and whatever. But these generation shifts are unnecessary if we are in the cloud actually.
(17:36):
So it was necessary in two G and 3G and 4G because we bought in new appliances and different hardware, but now we can run it essentially on the same hardware. The lifecycle management of the Harper is independent of the network generation. And so when we have an iterative approach to update the service and features of the networks, then we can spare new technologies like six G and so on. Maybe we need it for marketing reason to have something shown on the mobile phone, but that should be extent from the network technology once in the cloud. It's not necessary all generations any longer.
Guy Daniels, TelecomTV (18:22):
Yeah, I think your comment today will resonate with a lot of telcos, a lot of our viewers. We certainly get feedback thinking along the exact same lines there, this is great. Joan, let's come across to you next for comments on the benefits and perhaps the challenges of cloud native for telcos.
Joan Triay, DOCOMO Euro-Labs (18:39):
Yeah, thank you. So yeah, I agree with many of the benefits that have been highlighted. I'm not sure if it has been forgotten, but I would say that I would also highlight one about the automation. It's quite essential or quite visible that cognitive can be a real true enabler for introduce more automation in our networks. But if I focus more on the points of challenges, I would like to highlight maybe four that come to my mind. One is about how Cloudnative is actually changing our shape of the current status of the telco operators that need to provide long-term support for services. Introduction of cloud native with a much shorter time to market, faster upgrades and so on can actually create quite an important challenge to the operator on trying to adapt its kind of operations to this new form. So I see that quite a big challenge and something that can actually make difficult for the operator to adapt to this new environment.
(19:49):
So more efforts on trying to improve the ecosystem on how to understand the needs for operators for providing support is very much appreciated. One other challenge that I see, and it's a little bit related also to the concept of the definition of cloud native, it's about not being coupled to specific technologies. So there is quite danger situation that by adopting specific solutions or technologies, the operators might also get coupled locked into a certain ecosystem which would probably and of course not be a good endpoint. And finally the one that I would like to highlight is it's also a little bit related to the kind of operations that we're doing as an operator. One of the key aspects of Cloud Nativeness is also about the introduction of more declarative driven management, which is quite good and it's very important. However, we need to really understand whether all our kind of operations that we perform on our networks can really be translated or can really be performing at the ative manner.
(21:11):
And I don't really have a good answer for that, but some of the examples that come to my mind, how do you perform troubleshooting or how you perform root cause analysis and so on that in the past we had our own procedures, our own workflows to perform that when we transition to the dec quality way of work can create some big trouble for the operator. So in a sense, I would say that if we can all together work on trying to cope with these challenges, you will make also the concept and cognitive much more appealing for the operators.
Guy Daniels, TelecomTV (21:52):
Thanks Joan. All good points there. Thank you very much. Michele. Let's come across to you next for comments.
Michele D’Agostino, Wind River (21:58):
Yeah, so I just wanted to make a comment. So I've seen that the benefits and challenges have been extensively covered already, and I would definitely agree in terms of challenges that security of course is a challenge, but also performance, especially in a telco cloud network where basically the network has to match the KPIs of the traditional run. But I just wanted to add an additional benefit of cloud run technologies, which is the fact that with this you get an easy version control in terms of software configuration management. So basically you can upgrade only the layers or components that you want to upgrade. So for example, in a CAS stack, you have the infrastructure, you have the host, you have the cas platform, you have the Kubernetes layer, and with cloud native approaches you can update all these components independently. And I think that's another key advantage benefit which was not mentioned before.
Guy Daniels, TelecomTV (23:02):
Great, thank you very much for that. Let's go across to Beth as well to round out this set of answers, Beth.
Beth Cohen, Verizon (23:10):
There are challenges and advantages both and many of them have been already mentioned, but I think another consideration is that cloud native is actually a more complex environment. There's a lot more interactions than the traditional proprietary box or hardware-based environment. So where we're disaggregating the hardware from the software, the advantage of course is as Joan mentioned, that you can upgrade the software without upgrading the hardware. So you're separating those functions and obviously you can use APIs and you can use other mechanisms, but you do lose efficiency in some ways. You gain efficiency because obviously you're using the hardware more efficiently. Although I would argue that telco workloads tend to be pretty steady, so that elasticity that web workloads take advantage of is less important for telcos. But we also lose efficiency in that when we do need to do a hardware upgrade. It's extremely expensive and extremely painful. So as I said, as we've all said, there's trade-offs.
Guy Daniels, TelecomTV (24:38):
So we've talked about the benefits and challenges, but how does a telco actually develop and grow a cloud native environment? And also how does it ensure it is a success? What are some of the main components and tasks required? Michele, let's start with you.
Michele D’Agostino, Wind River (24:56):
Thank you. That's a great question. So first of all, you need to have a solution that is architected to deliver operations at scale across the whole life cycle. That means day one, day zero, day one, and day two operations. And you need to be able to perform all these operations on tens of thousands of knots within a single maintenance window. So in general, rather than building a technology which is only targeted to IT or enterprise, you have to be focused on requirements which are specific for the telco market. And for 5G, for me that means three things at high level. First of all, ultra low latency and then operational characteristics such as zero touch deployment and zero touch upgrades. And then of course carrier grade, which is required to deliver the high level of scalability, residency and redundancy, which is required in telecom Telecom. So for example, we need to be able to provide the famous five nine availability in order to ensure that the network is always available.
(25:58):
And then there is another very important piece in my opinion, which is the fact that to be successful, you also have to constantly innovate all the components of the telco cloud ecosystem, including for example, the cost layer by for example, augmenting the kubernetes capabilities for example. You have to be made sure that additional security is added because of the sensitive nature of telco workloads or need to add more observability. And I'll give you two great examples of this type of innovation which contributed for Wind River, for the Wind River class platform to be ranked number one in a recent study that a BI research published where basically they looked at all the 5G cost platforms and they ranked all of them. And of course I'm very proud and excited about the result. But what we have done as two examples of innovation is that we have number one developed an innovative solution for reliability which provides self feeling.
(27:03):
And that's very critical, especially in a distributed network where you have thousands of edge sites. And then another great example of innovation is in the area of total cost of ownership. And as all the people know on this panel, I'm sure this has been a recurring argument used by cloud native or in general open run detractors. So what we've done in this space is we have developed a very resource efficient solution so that the whole cloud platform can fit into one core. And with this innovation, not only we deliver for the cost of ownership and reduce the footprint, which is what operators want, but in addition to that, we make available the course for other services and other workloads which the customer can run for revenue generating services or even to run new network elements which have recently been visualized. For example, the sell side router.
Guy Daniels, TelecomTV (28:06):
Thanks very much, Michele. Let's go across to Sidd now to bring Sidd into the conversation At this point, there's a lot of elements required to make cloud native success in telcos. What do you think are the main components and maybe some of the tasks that are required to do so?
Sidd Chenumolu, VMware by Broadcom (28:23):
Yeah, I think in the previous question what Joan and Beth covered, I think those are some of the areas we should address here. Also, I think Beth covered like this is complex, right? As that deploying a cloud native applications and platform are complex. Got it. Then also Joan covered about long-term support for solutions, and I think he said something about troubleshooting that we need proper information and how to troubleshoot in cloud native environment. So those are the key things. I mean the reality is that today in the network for most service providers, majority of the deployments are vfs. There are few CNFs and there are far fewer ones that are actually microservices or cloud native based. So from a service provider point of view is looking at a gamut of deployment types and to the points that Joan mentioned, that you need a solution that is automation driven and also coupled with assurance in a single management plane that can manage all this vnf, CNFs, cloud native applications in a unified manner such that when an operator decides to migrate from one type to the other, there is minimal to no service impact. I think that is the key. Similarly, day zero deployment is half the battle in my opinion, the day two where we continue to get the benefit of cloud native is by not falling into the original trap of having long maintenance windows. I think I would rather see people putting more effort into no impact upgrades such as inline upgrades or cannery upgrades and not so much doing a long maintenance window. I think that's where we'd see most benefit ability to introduce new applications and services at a faster rate.
Guy Daniels, TelecomTV (30:14):
Thanks, Sidd. Interesting focus on day two there. That's great. And let's come across to Joan now because you referenced some of his earlier comments. So let's hear from Joan now about some of the main components and tasks required to make this a success.
Joan Triay, DOCOMO Euro-Labs (30:27):
Yeah, one component is more organic sessional, it's more about the company. So if the companies are not transformed to embrace the concepts and the principles of cloud native, it's going to be very difficult to make it a success for a TechCom operator. And that implies changes in the organizations like creation of dedicated teams. For example, in our case, we are turning into a cloud-centric and service provisioning organization where there are dedicated teams that perform all these set up for the whole network, not just only for a dedicated domain in the network. As a mobile operator, we need to provide end-to-end and covering different areas from access to core. And it is quite essential that the organizations in itself are also adapted to make it a success story. And from a system perspective, I would say it is very important that it's created in a way that the operator, I mean I'm speaking on behalf of an operator, it has visibility of that platform and that infrastructure.
(31:49):
Ideally it should be a unified and common infrastructure and platform that can cover all network domains so that we can really streamline the generation of new services in a common manner, whatever they need to be deployed. And that is just only the underlay for the success. But if we are not able to actually connect that underlay platform to our OSS systems or our orchestration systems, it's always going to be a break point. And for that, one of the ways to make it a success I believe, is to put more efforts on actually making all those enablers in our platforms be with the standardization by reusing open source solutions and so on that enable all the hooks so that our network reconciliation that is performing the acquisition systems in the higher layers can really benefit of using that platform. So I would say that if we achieve that, it is very likely that the operator will see some success in the end on adopting the technologies.
Guy Daniels, TelecomTV (33:07):
Great. Thanks Joan. Clear goal there. You mentioned, well, let's get some views from our other operators on the panel. Kai, let's come across to you first then we'll hear from Beth, but Kai first,
Kai Steuernagel, Deutsche Telekom (33:17):
So I agree with most of what was said. So yeah, stable infrastructure, we need performance, we need reliability and availability of the whole, that's kind of clear. And that is what we also, when we look at do telecom and our platform, our cloud platform, it's a self grown ca platform, which we call TCAs Telecom in the beginning for sure. What was not yet said was kind of what is around that. So it's not only a Kubernetes platform, there's a lot of orchestration and things around, so we want to have a declarative approach when we deploy things. So all that stuff, it was mentioned here and there in different words also, that what is very important at the end is that we are following industry standards, that we are not trying to reinvent the wheel once more and that refine solutions that kind of all our network suppliers can say, okay, yes, I can use that.
(34:28):
I can build upon this infrastructure upon this foundation you are providing here, which is the challenge we are currently seeing and this is what we need to approach for. And there are a lot of open source components, tools and so on which we're using. There's one more approach to that, which is the silver project, an open source initiative to have a reference implementation of a telco cloud stack, which then also gets where network function suppliers can then validate their application to run on the silver stack. That is one way to go forward. We haven't yet implemented it in Doche telecom, but that's what we are looking at. So this is an important thing to get there that we have a standard way of onboarding new applications in a way, even if we swap out the cast layer and put another product in, whatever, that shouldn't matter, but the interfaces to the network function should be harmonized in a way that I don't need a separate cloud platform if I change or have another region in another network function supplier.
Guy Daniels, TelecomTV (35:48):
Thanks so much Kai, and as I was mentioned before, the last thing we want is any disruption of any kind as well. Beth, let's come across to you for thoughts on how do we grow and nurture this environment and make it a success.
Beth Cohen, Verizon (36:03):
I think there's two things I'd like to talk about. Several people have mentioned day two. I think that clout for telcos day two is really important, right? Because at the end of the day, we're most of the time during the life cycle, we're in day two, we are maintaining and supporting these functions. So I think that many of our vendors don't tend to pay as much attention to day two because of course they're selling us something that they're focused on day zero and day one more. And I think there's a disconnect there, and I think that has led to some issues in the community, but I think more importantly, we haven't really talked about it yet, but I'd like to bring up the open standards. And it's not just standards, it's the open source community. Because increasingly telcos have traditionally sort of said, oh yeah, well, we have to develop standards and then we will all abide by these standards.
(37:13):
But increasingly standards and open source are two sides of the same coin. And I think we need to use both. We have reference architectures that, and I'll mention the one that I'm most active with, which is the anate reference architecture. And in anate, although we started it about six years ago with the idea that it would become kind of a standard, what it has evolved into is a guidance and for how to stand up and deploy and manage these infrastructure environments with the idea that the vendors that are creating the applications that sit on top of these environments can be informed about how the environment will work with their applications. And that's a key gap. That's been a gap for I'd say a while. In my work, I tend to work with the vendors that are sort of higher up in the stack, so the security vendors and the SD-WAN vendors, and they don't tend to pay as much attention to the underlying infrastructure as I think that they should. The wireless vendors that are creating the CNFs and vfs, I think do pay more attention to the infrastructure, but the vendors I'm working with don't, because they tend to have solutions that are boxes and they're more proprietary. And I think we as telcos need to break them of that habit and get them to see the value of working, having these applications work within the cloud native environments.
Guy Daniels, TelecomTV (39:13):
Great, thanks for those observations, Beth. Really important. We've still got a couple of points I want to get through on this opening panel, and Beth, I'm going to come straight back to you for our next one because I'd like to ask if there is any agreed way that we can measure performance and success of implementing a cloud native workplace?
Beth Cohen, Verizon (39:34):
Well, there is no standard I can tell you that. So most companies look at it from two perspectives, and I think one we have a better handle on than the other. So many companies look at capitalization and cost efficiency. So how much does it run in day two? And I think we do in fact see cost efficiencies for running things in day two. Although as I mentioned earlier, it's complexity to actually get into the fine points of that because the other component is the efficiency and the ability to be more flexible, which doesn't tend to drive down, costs it to, it gives us more opportunities to add new technologies quickly and add new services and more revenue sources. But at the same time, there's a cost to running a system that has that flexibility. So in terms of trying to measure all this stuff, it's very difficult. I mean, I argue with our finance people all the time about how do we capture the costs of running these services? And there's no one answer,
Guy Daniels, TelecomTV (41:03):
Well, this is really good that there's no one answer because there's plenty of viewpoints here as part of our summit, and we're going to hear a few more now hopefully. Kai, what do you think, Kai? Do you think that we have a way of measuring this or we need to find a way of measuring success?
Kai Steuernagel, Deutsche Telekom (41:22):
It's hard to measure, I think the success of that. So at the end, it'll take some time in order to see the operational effectiveness of that coming through. The first thing I would, okay, this is a success if I'm able to really scale down the network functions and save energy, and so the build is getting smaller on the energy side, then it would say, okay, for us that would be a success. There is more to that and we need to get to that also to what we talked on before. I don't want to repeat the whole stuff again and again, I think to get there, we need to adopt what is there now and develop it further.
Guy Daniels, TelecomTV (42:06):
Great. Thanks very much, Kai. Well, I'm going to come to Joan in a moment, but Michele, let's come to you next.
Michele D’Agostino, Wind River (42:11):
Yeah, so I definitely agree that it's hard to measure success. So if I look at cloud native metrics, normally I would look at performance, resource usage, application health. But more specifically for telco, we must say that traditional networks have been deployed for a very long time and they've undergone a lot of optimizations performing at five nines or more. So in the context of telco networks, the cloud native deployment should compare to these traditional macro networks in terms of performance and reliability. So in other words, the performance of the cloud native deployment should be acceptable by the CSP as good or better than the traditional run performance. And I have some experience with that. So for example, in Europe, which is where I'm based, we have deployed the Wind River studio cast platform with Vodafone, and Vodafone has set the bar very, very high. So basically they looked at the KPIs of the cloud native based networks, and they compared them with KPIs from the traditional run vendors, which have been deployed for a very long time.
(43:18):
Now the good news is that the Vodafone itself announced in many events, including at Fuse in October last year, that the open run KPIs that were measured were at parity and in some cases even better than those of legacy equipment. So for me, that's quite encouraging. And in fact, Vodafone announced the same results of, showed the same results within a demo which was demonstrated on mobile called Congress in February. So performance is very critical, but then you also have to look at scalability and data operations, as Beth was saying. So when it comes to scalability, the network should be able to scale from one single server to how to even to a national data center, and it would be ideal if the whole infrastructure could be monitored from one single pane of glass. And then lastly, regarding lifecycle management or day two operations, I definitely agree with Beth that that's very, very important. So it's very important. So upgrades are extremely critical and it is important that you are able to upgrade 10, 20, 30,000 sites within one maintenance window. So for me, that's definitely an important success criteria. So they too, I fully agree that is something to pay attention to.
Guy Daniels, TelecomTV (44:44):
Great. A lot of consensus on this particular issue. Thanks very much for that, Sidd. Let's come across to you next for your thoughts please.
Sidd Chenumolu, VMware by Broadcom (44:52):
Yeah, I think I probably comment at it a little differently. We need to define an objective as to the why. We're even talking about going to cloud native help in the first place. This is about modernizing the network and offering new services. So perhaps we start looking at that, what the real objective is, and then start figuring out what the total cost of ownership that is resultant because of that migration or modernization, what you want to call it. It could be from a services driven, it could be from an operations driven from any other perspective, but for every operator, if the objective is different, then it's very hard to standardize something. So I think that's where I come, just start with an objective and just consider cloud native Telco as more of a framework or operational process to achieve that.
Guy Daniels, TelecomTV (45:42):
Thanks very much Sidd. And Joan. I think you wanted to come in with a comment as well, so let's come across to you.
Joan Triay, DOCOMO Euro-Labs (45:48):
Yeah, I fully agree also with others and I will add a little bit more consensus in what I already heard. I think that is also the way to measure success and the metrics that we should use from an operator perspective is whether our networks are more efficient, whether we are saving money, whether we are able to monetize it better, whether we are able to create new services. This should be really the metrics that we can identify and use as a way to measure if our adoption of cloud native is useful. I've come across sometimes from some questions or analysts or reports trying to figure out whether if the introduction of key tops or whether my VNS are running on containers or not as a way to measure if I'm successful or not. And I think it's very useful to understand that there are these kind of aspects to understand because these are really all aspects that need to be considered, but I'll not use them as a way that we can define if we are on the right path of being cognitive and the right path. As I said, I believe is more from what as an operator we can deliver.
Guy Daniels, TelecomTV (47:05):
Thank you very much indeed for that. Thanks everyone. It's been a great conversation. We are rapidly running out of time though, so perhaps I can ask one final question and get some quite concise short answers from you all because I do want to round this out by just asking how telcos themselves can contribute to the cloud native ecosystem, the developer ecosystem, and ensure that their requirements receive attention and support. Kai, can I start with you please?
Kai Steuernagel, Deutsche Telekom (47:33):
Yeah, sure, absolutely. Try to make it short. So three things to mention, starting to use what is there, there's some of the network function suppliers have some solutions which are not yet in the market. They have been delivered, but no one is using them now. So let's start with that in order to get the industry to develop further and so on. So this is my number one. The second thing is we need to drive also into the open source market projects like silver. I mentioned before, I know KA mentioned by be, but that is kind of the obvious things. We also see other projects where we need to involve further and that brings me to my third point. We need to work shoulder and shoulder with the IT industry in that space because their world is turning three times faster than the NT world to be honest.
(48:34):
Take an example of Kubernetes and 5G. It was started to develop at about the same time. 5G is here now, but Kubernetes is there for long. If we now define it, I was asked about what is kind of the cloud requirements for six G? And I said, yeah, cloud native easy. But then I thought again, 2030, what is cloud native in the IT industry in 2030? I don't know at the moment at serverless. So where are they going to and do we need to maybe shorten our innovation loops a little bit in order to cope with that and to better kind of take what was developed there to even improve?
Guy Daniels, TelecomTV (49:18):
Oh, great points Kai, thanks very much. And especially that last one about looking ahead five years and trying to see what definition's going to be and how far part of this cloud native community will have come in that short time, who knows. Beth, let's come across to you for your final thoughts on this question.
Beth Cohen, Verizon (49:36):
Well, I want to build on what Kai said. Please participate in the open source and standards communities. Your requirements are key to the success of these projects.
Guy Daniels, TelecomTV (49:50):
Perfectly said, absolutely we want to see more telcos participating in these communities. Joan, let's come across to you
Joan Triay, DOCOMO Euro-Labs (49:58):
Same as so, but I will add a little bit more emphasis on actually participating in standards as well. So I think that for a long-term sustainability of telco business, we do still need standards. We need to promote a lot more the interaction and the change of information requirements use cases in between the open and the standard communities. And by experience, I believe that from the telco perspective, participation of standards is also very beneficial. And even more in the case that some of the operators have already reused the standards or frameworks in their development of the early phases of virtualization and cloudification, like for example, using the H-C-N-A-V framework and so on. And we need to steal the support of all the operators and vendors to drive the standards, create use cases, requirements and all that. I believe that is going to be quite essential for the open source communities, therefore afterwards, sorry, to actually develop solutions that then we can adopt. And I believe that that kind of synergies in between the two. As it was also said before that there are the two sides of the same coin. It's very, very important.
Guy Daniels, TelecomTV (51:25):
Thanks very much. And Sidd, what are your thoughts? How can telcos contribute?
Sidd Chenumolu, VMware by Broadcom (51:31):
Well, first I would like to acknowledge that telcos are already contributing heavily into this one. So almost like any year ago you see that te, the NGM man release its manifesto for cloud native telco, right? We can build on top of that. Definitely keep more detailed requirements based on that manifesto, but also the CNCF, the CNTI working group has released the test vectors and test criteria for what a cloud native telco means. So there is definitely work being done, but to echo Kyle's point, we should adopt what is there already instead of waiting for something that's going to come down to the future. I think we should take the first step and put a timeline as to how and when these cloud native aspects would be introduced to the network so that it gives confidence to the developers to keep going with it.
Guy Daniels, TelecomTV (52:20):
Yeah, absolutely. And we need the developers. Thank you very much indeed for that comment. So thank you everyone for your comments. We have to leave it there though because we are out of time for this first panel debate. I'm sure we will continue this during our live q and a show later today. For now though, thank you all for taking part in our discussion. And if you're watching this on day one of our cloud native telco summit, then please send us your questions and we'll answer them in our live q and a show, which starts at 4:00 PM UK time today. The full schedule, the programs and speakers can be found on the telecom TV website and that is where you'll also find the q and a form and our poll question For now though, thanks for watching and goodbye.
Please note that video transcripts are provided for reference only – content may vary from the published video or contain inaccuracies.
Panel Discussion
This panel explores the ongoing confusion surrounding cloud native, emphasising the necessity for a precise and universally understood definition within the telecoms industry. It delves into the benefits and challenges of adopting a cloud-native approach, and offers valuable insights and strategies for organisations to effectively navigate this transformative shift. The panel also highlights the intricacies of developing and nurturing a successful cloud-native environment, highlighting the importance of robust infrastructure and operational practices.
Recorded September 2024
Speakers
Beth Cohen
SDN Network Product Strategy, Verizon Business Group
Dr. Joan Triay
Manager and Network Architect, DOCOMO Communications Lab. Europe (DOCOMO Euro-Labs), Rapporteur, ETSI ISG NFVs
Kai Steuernagel
VP Cloud Technology, Group Technology, Deutsche Telekom
Michele D’Agostino
Director of Product Management, Wind River
Sidd Chenumolu
Head of Product Management, Software-Defined Edge Division, VMware by Broadcom
