Ray Le Maistre, TelecomTV (00:12):
We've been talking about cloud native for years, but for some network operators, it's still early days on the cloud native telco journey. So what has been learned and what experience can be passed on to those still finding their cloud native feat? Well, to find out, I'm talking today with Carlos Torrentí, presale solution architect in the cloud division at Rakuten Symphony. Carlos, thanks so much for joining us today. Let's start at the beginning. What's the very first step for going cloud native and what big mistakes should network operators avoid?

Carlos Torrentí, Rakuten Symphony (00:48):
Thanks, Ray. I'm very pleased to be here. So what I would say to that question is that I would start by a very, but the thing that's made seem very obvious, which is to define exactly what cloud native means for the organization and to get a common consensus across all the organization of what actually that means. So I think I've seen different interpretations of the cloud native world in different organizations. I think for me, it's just bringing some best practices in software development and delivery into the products and services that the operators deliver to the market. And that implies things like ization, loosely coupling services that connect through APIs, orchestration of those services, GitHubs and DevOps and so on. But because this is a so broad term in many aspects, then it's good to have that common consensus across the organization because that's going to be the foundation for getting a common understanding and be able to achieve the goals that the organization wants to achieve in that sense.

(02:09):
Right? So the ultimate goal of the cloud native transformation at the end is to try and achieve business results. And I think one of the biggest mistakes you can make is that to just jump into the technology without understanding really what is the value behind. So I think it should be a layer approach. It should be a ladder that you climb up progressively, and the technology has to be a tool, but it doesn't have to be the goal. And I'll put you a very simple example. When we started in Rakuten Symphony and where we started deploying some of these disaggregated networks based on cloud native architectures in some of the operators, and for example, in Rakuten Mobile in Japan, we started with a very strong CAS layer, containerization layer. But when we started deploying that in multiple sites across many different islands in Japan, we recognized that there was a need to do something else, right?

(03:19):
There was multiple containerized clusters running in different locations, and all of them had to be managed from a single site. So the goal was to this problem needed to rethinking how we should approach it, and that lead to the creation of tooling that supported that management, and that's how we ended up having a multi clustered orchestrator that is able to manage things like the hardware life cycle, the software life cycle, and it's able to do zero touch provisioning on many of those layers. I think the last thing I would say is that even cloud native is a global term requirements are very much dependent on geographies and locations because each different operator has different interpretations and different local regulations. So adapting to those small nuances and small differences makes also an important step in how you define your cloud native journey.

Ray Le Maistre, TelecomTV (04:27):
So what kind of organizational and cultural shifts are most critical for successful cloud native transformation?

Carlos Torrentí, Rakuten Symphony (04:36):
I'd say that it is important to get executive support from the beginning. The cloud native transformation journey is not free of obstacles, and you need to make sure that the organization is supportive of such changes. In the case of Rakuten, that was quite granted because it's very much a history of being disruptive with technology. And so our executives were fully supportive of taking this journey of deploying open running, being one of the first operators in the world to do so, and having that technology branch that supports that deployment with Rakuten Symphony. But you have to make sure that the organization is prepared because the journey to cloud native transformation is long, and it might not be free of obstacles, it might not be free of complexities, and it's important that all the organization is supportive of that once you have that support from the executive levels, I think it's also really key to foster that cloud native philosophy or approach across all the levels of the organization, whether that's engineers that are developing products, whether that's the operations team and so on.

(06:04):
So all of them need to be aware that what you're doing is actually productive and what are the results and why is this aligned to the company values and so on. So key aspects of this transformation also are the ability to do things quickly, do things, do fail and error so that if something doesn't go well, the organization is prepared to redo things, try to rework how things are done and when things are going right, then basically productize. In the case of Rakuten, that's really embedded as well into the DNA of Rakuten. We have something called the five principles of success. One of them is about the speed, which I think is key to do things an agile way. And the other is something, it's a Japanese world work called Ika. I don't know Japanese, but it means something like try to strategize from your hypothesis.

(07:12):
So try to develop something, test it, and if it goes well, then go for it. So I think those are very important values that every organization needs to have and that it needs to bring into their cloud native journey. The last one I would add is the capability to be reactive. And that implies that there's a lot of observability components that need to be plugged in. So I think actually observability is really key and the organization has to be prepared to measure from the field, see what the results are of these transformation, whether it's going well, it's going bad, and act upon those results to make sure that whatever it's not going as desired can be reworked and can be improved.

Ray Le Maistre, TelecomTV (08:02):
So you've mentioned the importance of speed there, but how can operators be fast and agile with cloud native while still being secure and compliant?

Carlos Torrentí, Rakuten Symphony (08:14):
I think security is just another component that needs to be incorporated into the release process and into the cloud native journey. It has to be there from the beginning. It's not something that you do at the end. It's not something that you do after you deliver software products. It has to be absolutely embedded into the development chain and the operations chain. And for that, you need to make sure that right from the beginning of your cloud native journey, whatever you use, GitHubs, ci, CICD, you have that security deployed into those processes. I'll give you an example. We run a deployment network for our customers where we have multiple CICD components and we have different tools at each stage of the deployment process to make sure that wherever we deploy, whether that's our own software products or third party products that we distribute to our customers, we have that security embedded into the release process.

(09:20):
And that means that we have static analysis tools, dynamic analysis tools, code scanning, components scanning, all of those things need to be part of the release processes need to be factored in when you deploy your applications. The other thing that is quite important is once you have deployed your products, you need to make sure that you are testing your deployment and that you also can react quickly under any circumstances. So if there's any security incident happening on your network, the way to react and the way to control that is to make sure that you have your observability tools in place and that you are able to basically react. And the more they automated the reaction is obviously the better. Some operators may not be able to do closed loop automation at the beginning of the cloud native journey, but ultimately doing those automated actions, making sure that you get the right approvals in there, it's something that is really important.

(10:32):
And finally, the last point I would like to bring is to try to be consistent across environments. I think one of the good things you can do in a cloud native approach, and one of the things that cloud native brings you is to do policies and define policies as code as well. So that allows you to be consistent no matter what the environment is, whether that's the lab, whether that's a production network, it allows also you to cooperate with your security department, make sure that the policies defined by your security department are just realized into the production networks. And those policies also help with consistency across deployments and the way you can do things in many different productions, whether that's pure compute or whether that's also data. So if you have any problem with your data, it's very important that you get the right backups and security tools and basically the ability to restore to a previous state. So having that configured as a policy is a really key point to ensure that your network is secure and stable.

Ray Le Maistre, TelecomTV (11:49):
So measuring success is something that network operators are always looking to do. So what kind of metrics and KPIs are most effective for tracking the progress and demonstrating the return on investment or ROI of a cloud native transformation roadmap?

Carlos Torrentí, Rakuten Symphony (12:08):
So I think there's different metrics that you can use, and those metrics are very related to the business objectives that you define it in the initial stage. So for example, there could be metrics around the time for innovation, the ability to develop new products on a shorter life cycle. We tend to have a metric internally that checks the number of pipelines executed. In our software development, we run more than 6,000 pipelines a week approximately with millions of pipelines having been run from the beginning of the network. So that's really something that we measure against, and it's not really a KPI, but it also, it gives us a very good understanding of how that is working and how that is affecting the production deployment and our time for innovation. There are other metrics around cost savings that we have measured against our deployment versus traditional deployments.

(13:19):
And that's typically another metric that most operators want to look at. How much are they saving compared to what they did before? So that oversees different aspects and it's not a single thing that makes it cheaper or more cost effective. I think it's a combination of factors that span across OPEX and CapEx investments in the way that we deploy the services. And that has to do with reduced hardware footprint because of better utilization, the ability to do faster automation and reduce the number of customized services that we need to do for each one of our installations because we have this automation running with zero touch provisioning and therefore we can save on the services of setting new sites. And I think also one maybe aspect that doesn't sometimes gets overlooked is the ability to do advanced capabilities such as energy savings. So with the automation on our networks, we're able to produce significant energy savings that can be used really to reduce the monthly bill at the end of the day. And that is a real impact on the cost savings. So I think all those are KPI measurements. So you can check whether what is the utilization of your network, what is the time that it gets you to deploy, and what are the cost savings in terms of all of these factors that are I have mentioned.

Ray Le Maistre, TelecomTV (15:08):
And how important is open source technology in a cloud native plan and how can it best be used?

Carlos Torrentí, Rakuten Symphony (15:16):
I think open source is a key component of any cloud native transformation project. Luckily, we have a very broad community that does open source projects and we have a really strong capability on the open source market. So there's no need to reinvent the wheel every single time. I think now we're getting to a mature point in some of the open source solution. For example, Kubernetes has become the fact standard for orchestration. CNCF reports indicate that almost 80% of the organizations are using Kubernetes in production. So let's take the advantage of that community and let's use those projects to transform our network. So the key point is that some of these community projects also, they're complex technically, right? So our mission as vendors is to simplify that complexity and provide the tools that you need to deploy your network. But all whilst keeping you on the open source, being on the open source track and being able to leverage all these community enhancements, but also simplifying the life of deployment.

(16:37):
You don't need to be a Kubernetes expert. You don't need to be developing a custom resource adapter if you have the right tools in place. So what I would suggest is for people to look at mature community projects that tend to have better documentation, tend to have better support. So it's great if you can take those projects and ensure that you incorporate them into your cloud native journey whilst also making sure that those projects align with your business goals. So one of the things I would recommend to anyone is that you do not start your house on the rooftop, right? Don't go to closed loop automation. Don't go to reconciliation if you first don't have, settle up your orchestration layer in a way that you can run your containerized functions and your virtualized functions with a single management plan, because otherwise you're going to struggle with that capability without having set up the foundation for your basic cloud native journey.

(17:48):
So I would say stick to the basics for the beginning and climb up the ladder progressively, add new capabilities, add reconciliation, add GitHubs at CICD at a later stage. And first of all, set up your foundation. Make sure that you have your new functions running properly. Make sure that you have the right storage, that you have the right backup for your solution so that nothing happens in your network, that your network is stable. And then make sure that you start doing that closed loop automation, that automatic correction on your network progressively as you move along. And as well, make sure that whatever you pick from allows you to stay on the CNCF well on the open source community as well, so that you have the flexibility to decide what tools you want to use because each company is different. You may choose, there are multiple tools doing similar things.

(18:50):
There are multiple artifactory tools, there are multiple registry tools, there are multiple reconciliation tools, and they're all open source. They're all good, but you need to make sure that if you want to use them, your base layer supports them. So that's what we do at Rakuten Symphony. We really embrace the open source community. We are CNCF compliant with our cloud layer. For example, what we allow customers to do whatever they want with their layer, with their tools. So if they want to use something that we don't provide as a package, they're perfectly free to use, but we try to simplify their lives by giving them pre-packaged solutions that they can use right away in the market that they can use to automate their solutions, to automate their deployments, to make sure that their applications are secured and can use any networking and so on. So I think that those are the key elements to take into account.

Ray Le Maistre, TelecomTV (19:50):
So for organizations that have successfully completed significant portions of their cloud native transformation, what have been the most unexpected challenges that they've encountered and what advice can be offered to those that are just starting out?

Carlos Torrentí, Rakuten Symphony (20:06):
I think that a key or a major thing that I would say from the beginning is that there is the difference between hype and reality. Cloud native transformation is an endless journey. So even though we have done a vast large improvement on our network and we have gone quite far in the cloud native journey, there's still a lot to go. So we have to, during that journey, we have learned that there is a lot of hype in some aspects. And then reality brings you down. Really at the beginning when we started deploying functions in some of our operators in Japan, for example, we noticed that some of these basic functions, many of them were not containerized and others didn't have the ability to do things that you may think are basic qualities of any cloud native application, right? Things like scaling out and things like resilience, automatic resilience and so on.

(21:15):
But many of the functions were not prepared for that. So I think we have to understand that this is an ongoing process and that it's constantly evolving. So the ability to adapt to those changes is really important for organizations. And that we have to understand that sometimes we have legacy functions that are not maybe suited for cloud native things like all SS seven functions running in the network that might not even have the right APIs. And we have to take into account that some of these still need to be there for some years. So we have to make sure that whatever we plan has into account those hurdles, and we have that ability to live through the transition of that cloudnative journey with the tools we have. So that's why, for example, we develop a very strong OS layer that is able to cope with different API types is able to hide that sort of underlying complexity in the network about functions that do some things and others then don't to the upper layers.

(22:32):
And also why we have a cloud layer that is supportive of both cloud native containerized functions, but also virtual functions because we think that those functions are going to be there for a while. And it's important that any customer that is finding travel in their existing deployments, maybe because they are having shaking by their existing vendor on the prices and so on, they're able to have a way forward without losing what they have at the moment. So this is really important for any customer doing a cloud native transformation. And the other thing I would add in that respect is that migration really is also a key aspect, maybe not so relevant for some of the operators that I've mentioned before, because some of them were mostly greenfield, but we are finding a lot of operators in the market that have their functions already deployed. They have their 4G networks, they have their 3G networks, they have their IT workloads running with databases and so on, and they want to get to a containerized or more cloud native infrastructure. And migration is really one key aspect. They don't want to lose their existing workloads, they still want to serve their clients. So it's important to be able to do that migration smoothly, be able to understand and assess the priorities for that particular customer and follow those customers into their journey of transformation with the right tool sets, with the right services to make sure that everything is done smoothly. And that is going to be a complex, but that's our responsibility as vendors to be there and to support those customers in their transformation journeys.

Ray Le Maistre, TelecomTV (24:31):
Okay, Carlos, a lot of great advice there. A lot of great insight for network operators that are still going down the cloud native road. And as you said, it's an endless journey, but a fascinating and of course very worthwhile one. So great to chat with you today and thanks very much for joining us at telecom tv.

Carlos Torrentí, Rakuten Symphony (24:50):
Thanks for having me. It was a pleasure. Thank you.