Beyond Cloud Native with Jitin Bhandari

Smart telecom providers are embracing the concept of “Cloud Native” when deploying 5G. But networking expert Jitin Bhandari tells our Michael Hainsworth there’s more to next generation wireless than moving to the cloud. Learn about what’s needed beyond cloud-native, automation’s four pillars and the capability to use any cloud.

Below is a transcript of this conversation. Some parts have been edited for clarity.

Michael Hainsworth: Jitin Bhandari has been guiding the telecommunications industry on a transformational journey from a dumb pipe provider to a flexible 5G partner of the fourth industrial revolution - and going cloud native is critical to that success. But once a communications service provider recognizes the need to move much of their functionality to various cloud models, what's beyond cloud native? I started my conversation with Jitin by pointing out that when we talk about going beyond cloud native, we're acknowledging that cloud is just one of the many tools needed for the overall digital transformation of a wireless carrier.

Jitin Bhandari: You started up right on the note by talking mentions of a word called cloud native. But before we go there, you gotta understand that, you know, there are two fundamental transformations that are happening and I'll use a word what we call as network disaggregation. And that's what the whole concept of cloud is. And what cloud brings in is this whole concept of edge, far edge and core data centers or what we call a regional and national data centers in CSPs’ terminology.

So there's a lot of network - what we call disaggregation - is happening at a network level. And these are obvious concepts of cloud. What is also interesting and I don't know if our listeners have thought through this is, cloud native concepts bring a unique network function disaggregation, or what we call as workload disaggregation, because the very principle of cloud native is to break down any software applications, any workload.

And here we are obviously talking about telco workloads or telco software applications. We'll talk and double dip more about it. Cloud native is all about workloads or network function, disaggregation. That is taking a workload, taking a software, what it does in any part of the network - whether you're doing radio, whether you are doing routing, whether you are in the core of the network, whether you're doing operations or assurance, part of the software - what we are seeing here behind the cloud native principles, you are disaggregating your network function, your workload, into smaller chunks. What we know and call as microservices. Each one of them is independently capable of scaling, handling each of these functionalities independently and so that we can embrace maximum concept of reuse. So, you know, this whole notion of when we talk about 5G, and when we talk about cloud, these extrapolations to cloud native then becomes a norm because keep in mind, we're talking about networks disaggregation as well as network function disaggregation when we talk about the telco world.

MH: And, and going cloud native, isn't sufficient into itself. As you pointed out, when we had discussed on a recent episode, that we must embrace a high degree of automation, you point out however that there are many nuances and sub-segments to this, I think this is something we need to dig deeper into.

JB: You know, you said it so rightly and I believe that, you know, the concepts of cloud and cloud native has been overly talked about. And before we go into the word automation, I must also say that, you know, automation as a whole has been a very overused term in our telco industry, as in general. Right? And you know, I almost request my listeners to start thinking and breaking down the frameworks of automation into four clear distinct categories. And before I go into that you know, I want to bring up two important concepts that will be critical to our talk. There are two important toolsets beyond cloud native that we will be talking today, right? One is that we will be talking about automation that you just brought it up, we'll scratch the surface. What really automation means, why it's an overused and overloaded term, how we should break it down in truly telco segments, right? And in our telecom software transformation as we are going through it. The other concept that you know, is almost very important for us is this concept of what we have started calling the readiness to any cloud. And this concept of any cloud that will scratch it sort of surface later is seamlessly connected to the concepts of automation. And you know, they go hand in hand to truly make the promise of 5G come full to life. Let's break down automation into four frameworks, right? And, and if you pause and think there is a whole lot of software transformation going on right now in our networks, right? Our radios are getting transformed as we know heavily, utilizing and using virtualized and cloud concepts, what we call as V-RAN and C-RAN concepts.

There's a huge transformation of overlays, underlays, software defined networking inside the routing is going on. There's a whole lot of discussion in the industry, in the routing space of using white boxes and generic software that can control those white boxes of shuffling packets from left to right, as we said. And then there's a huge transformation going on in the core of the network and the associated applications, which we call the operations applications, the experience applications and the assurance applications. So software is everywhere, right? And when we talk about software at such large scale, that our telco CSP journey is ongoing. And as I said, it's a very exciting time because our CSPs have not had even a single CSP who has brought up these kinds of huge transformation, one concept that constantly emerges is the concept of automation. And when I say that, we break it down into four parts we almost need to think about the automation in four phases.

One is and I'll keep these concepts on the table, and we can definitely deep dive further into each one of them. The one concept is of just in entirety when you're talking about a workload, when I talk about a software application, but it's a radio application or a core application, how do you bring it to life in a day zero, day one scenario. When I say day zero, day one scenario it is when you're bringing network to life when you are onboarding that applications, when you are making those first configurations to make that service to life, how are you deploying that applications seamlessly then comes underneath those deployment and initial configs? The architectures of what we love about is the resiliency and redundancy. You know, how do you scale these applications? How do you make them more resilient?

How do you get them ready for five nines, seven nines, and how are your architectures and resiliencies working around it? And all those relates to what we call as the lifecycle management, often a workload or an application, right? That's right in itself is first degree of automation that one needs to be thinking about. And remember, in all of this dialogue, in the backdrop of it, we have this concepts of cloud native and cloud native brings up the concept of microservices. And microservices brings up the concepts of containers and network function disaggregation that I've been talking about, here comes the complexity around automating a workload and application through the true life cycle management of it from its days of initial deployment, to a full functioning of that network function to a depleting of a network function. If you may want to call, if you want to take down that service that's already in the network.

That in itself is a Hercules tasks. If I may say, when you're talking about just the life cycle management in a true cloud native world, when you have done network function disaggregation and embrace the concepts of microservices, how do you solve that puzzle at a level zero is in itself a challenge. And that's where most of the discussions that now that we are having with our customers.

MH: So then what are the other three facets that we need to focus on here?

JB: We are living in a true software world. And when we are living in as true software, we are talking about hundreds of workloads and applications. And these hundreds of workloads and applications will be continuously built by multi-vendor communities. Because if you think about our CSP friends, and I really, really think a lot about them because they are truly in an any-to-any scenario.

What I mean by, in any-to-any scenario is that in every CSP environment, you have got multiple vendors sourcing in their software in different parts of their networks. And there are multiple use cases that they are heading to taking those software use cases, right, and software workloads that they are consuming. And so, as a result of which they have a very unique challenge when you have a continuous pipeline of software that is being pumped by multiple software vendors out there. And how do you automate the consumption and the delivery model. And this is where the second phase of automation comes into play. Often you have heard this term of CI and CD, which is the continuous integration and continuous delivery. To me actually beyond the life cycle management that becomes your next second stop. When we talk about automation, because if you are a service provider and you are working in multi-vendor environments and you are set up to consume software from different sources, and that software is going to be very high touchpoint, you will probably be getting software drops every eight weeks, every 12 weeks, sometimes every four weeks to various security vulnerability patches, to features functionality, and to new enhancements in 5G.

What you need to be doing is you need to almost automate seamlessly that pipeline from your vendor communities, all the way to your delivery pipeline of how those softwares are consumed into your network. Build up to the use case and dynamically delivered to the end use case that our CSP friends are building up for their networks, right? So that whole continuous delivery, continuous consumption of that software, and then dynamism, and inside that dynamism, Michael, you got to think about all those plethora, hundreds of test use cases that will emerge because a new software has arrived into the CSP arena. How do you automate life cycles of those test automation frameworks that you need to build into it? How does that CD pipeline or the continuous delivery pipeline matures as we embrace these multiple softwares, whether it's a core software or a radio software or a join of a core software to a radio software and doing end to end validation, is a very complex topic for our CSPs. So to me, bringing that double-click on that second phase of automation, which is about faster consumption, faster deliveries, agile models of absorbing software is almost going to be a second stop for us to be thinking about automation.

MH: And sounds like an incredible headache for any CSP to be dealing with multi-vendor software deployments coming in, as quickly as every four weeks, we had this experience in Canada recently with a major telecommunications provider, getting a third party software update that knocked their entire network nationwide down. How do we ensure that we're building these environments that are scalable, but also that don't destroy the fabric of the network we've been trying to build in the first place.

JB: Yeah. And, and then I must say that security has been of utmost concern out there, and that's why not only you hear the concepts of DelOps or delivery operations. That's a term that we started talking more about, which is talking about exactly this dynamism of dynamic consumption of the software. We have also been talking about DF SecOps or design for security, but at the same times, thinking about security while delivering reliable software out into the CD pipelines. And, and one other aspect that, you know, I want to focus Michael out here is, as you're consuming these dynamic softwares, you got to step back and go to the next intent, which is the basic foundational intent of the 5G era is all about what verticalization and unleashing new businesses, right? And if you want to do that, you're talking about dynamic creation and depletion of services on building what we call a service intent network, no longer you're talking about one software applications or one specific aspect of your network, whether it could be radio or core, but you are zooming up at a higher degree level.

And you're talking about services and the creation of the services. This is all the fun and the promise of the 5G was behind the concept of network slicing. So if you want to embrace that dynamism, that agility, that promise of creating new value proposition of creating new vertical services for various ports, various dynamic transportation industries, and so on and so forth, we gotta be talking about the third phase of automation. And what is that third phase of automation? That third phase of automation is taking the concepts of life cycle management as how workloads are deployed, managed, and depleted, taking the concepts of continuous integration and delivery, and tying those concepts into a third degree of automation, what we call service orchestration, where service definitions services comes to life. These are services where CSPs thinks about their end customers, how these services will be consumed, how the SLA and the QoS be associated with these services, how the underlying fabric of the network delivered to those QoS and SLA as we build these services from a higher degree service orchestrator. So to me that becomes a paramount design exercise when we are rebuilding our 5G networks behind the concepts of cloud and cloud native, that we start thinking about a service based intent network, a service oriented framework, and all the more service orchestration that is going to be the brain of the network in a 5G concepts. So that's our third stop to automation and, and the journey is not yet complete. We have a full stop coming.

MH: Well, the journey is just beginning, really. I suppose, even though we've been on this road for some time, geographies and markets may be different, but several CSPs like Dish, AT&T and T-Mobile and others, they've already implemented 5G SA, 5G standalone, but beginning with the core and the associated functions, what are they doing right. That we can then apply to other CSPs who are just beginning this year.

JB: You know, that is a phenomenal question. And, I said in the start at the beginning of our talk, we are entering already into a very, very exciting phase of our times. And I must say, this is the best time of my career that I'm enjoying. I'm staying here with Nokia and seeing the transformation that I'm seeing all around us. One thing, for sure, the amount of dialogues and the maturity of dialogues this time around with the wave of 5G, unlike any other way before, whether it's a 3G wave or a 4G wave is all about talking about business value, how do we create business value? And what's the business intent behind any transformation that we are embracing onto the network? So that's a fantastic discussion to have. And some of the service providers you named in while they are embracing digital transformation, one thing is in sharp focus for each one of these is how do I create more business value?

And that is why, what they have realized is beyond the noise of cloud native, beyond the noise of cloud, what they have started focusing on that if I need to bring in agility and dynamism to the network, I need to embrace this concept over automation in any cloud. And the fourth piece of it that I was about to close on is also a very essential piece, because if you think about it, Michael, that we spend about 30% of our life cycle in building a network and 70% of the life cycle in continuously managing and updating our networks, which means that service assurance aspects of our networks becomes very critical.

And hence the concept of automation into service assurance also becomes critical. So a lot of our vendors, a lot of our service provider friends, who are knee deep into these dialogues are not only just talking about initial roll-outs and initial build-out, but also building a very sound framework of automation around service assurance. How does in a cloud and in a cloud native world, when you have already disaggregated a cloud network, when you have already disaggregated your network functions into various microservices, how do you keep a part of this highly complex network in a cloud native environment? And the only answer to that is pure degree of automation into service assurance frameworks. How do you take out fault management, performance management, various aspects of the network that keeps your network pulse at check? How do you build a proactive or reactive framework around the assurance is almost becoming critical. So these are the kinds of mature dialogues, and I'm really, really happy nowadays that the dialogues are very holistic in nature. They are not only talking about the initial phase of the network, but also the manageability, maintainability, operability of the network and a full dynamism and a full 360 degree way, the way automation is being done. And that's the kind of mature dialogue we expect from our service provider friends who are almost in their fifth generation, as we say, of rebuilding their networks.

MH: To them, is the sell job of network disaggregation that it creates more flexibility for the end customer and new business opportunities, or is it that it reduces costs for the CSP?

JB: I must say that, you know, the more worry that we all have collectively as an industry is how do we create more value, right? Absolutely. The more concepts of automation, the more concepts of zero touch we embrace in these networks, we are going to bring down the cost of operations that is humongous in today's network. That goes without the saying. And this brings me to a very important concept as we have been talking about 5G, and then we've been talking about cloud the concepts of any cloud. You know, if you pause and think about it right, now you're talking cost and savings. The classic problem our service providers are facing today is that I've got a new wave of technology.

That's what we call 5G. I need to update my radio stations to the newest and greatest technology. It's sounding like I need to rebuild my routing and core of the network and associated operations, embracing cloud native technologies, but then I have a business problem. And the business problem is should I go to a CAPEX based model or an OPEX based model as I build up and rebuild up my network into a cloud paradigm. So that's a business problem. And that's one of the unique business problems that our service provider friends are facing, and they are in sort of a trifecta. And based on the geographies you play in, based on the areas and the domains and the services you play in, based on the lifecycle of your own network, the business drivers, whether it should be a CAPEX or an OPEX based decision is actually leading up to you, whether you will make a choice of going full on a private cloud, full on embracing on a public cloud, and taking all your workloads in all of your network into a full public cloud gamut, or you grow more an intermediate path of what we call as hybrid clouds, where you have the best of both worlds. And many of these decisions when you talk about cost and optimization and embracing cloud and embracing the concept of 5G, is all about driven by your business decisions. And that's what's happening right now as we speak. And that is why any cloud concepts has become almost critical to the discussions of selection and rebuilding of our 5G networks.

MH: So to come back to step three, building the core for any cloud, it sounds like that means deploying the mobile core requires partnership with a public cloud service provider.

JB: Yes. And, you know, before you make that statement and come and jump to that conclusions, you know, let me, let me give a little color to what I mean by any cloud and why we absolutely believe that at this point in time when our service provider friends are rebuilding their networks all across the game what sort of strategies they must use for selections of various vendors that they select, whether in the space of radio, whether in the space of routing, and whether in the space of core of the network, right? And realize, you know, as I said you know, what we strongly believe, and I think that's where the industry is fast transforming to. The strategies of today can transform as the time cycle of business changes for CSPs. And what I mean by that, today's day of CAPEX intensive frameworks could be translating to an OPEX intensive framework, based on the dynamics of what kind of services and what kind of geographies you're serving and into.

So that means that if your business value proposition and your hunger to chase down new services and new services revenue means that you need to have underlying dynamism of how you build your network. You need to select right vendors, right application vendors, as your true partners, whose application can be deployed in any form of cloud. That's what we mean by any cloud. That means if I'm a supplier of an application, say, take a couple of examples of our core applications, whether we call about the packet core or the subscriber data management. These are the heart of these applications of the core network. I should be able to take this application, and based on the underlying strategies of the CSP should be able to deploy them to a private cloud of their choice or to a public cloud of their choice. If they partner with the big hyperscalers that we know of, who are ready to jump in into the telco gamut, or somewhere in between where they have hybrid strategies, where they've gone with the regional and national data centers, where they're building it privately, where as they are partnering with hyperscalers and public cloud vendors for their edge and far edge strategies.

And what is interesting to note here is that, that the true partnership for a CSP, with a vendor or with a vendor like us or anybody else out there would only be successful is if there is dynamism to the principle of how these applications are built ground up with the concept of agnostic platforms and the concepts of any cloud. So, we are seeing these interesting dialogues. We are seeing very interesting challenges and opportunities as we are building these workloads and applications on any cloud some phenomenal discoveries we have done as we have had experience in building to both private cloud arena, as well as public cloud readiness, with bigger power hyperscalers, we have thrown a bunch of workloads and validated them and have all sorts of interesting discoveries. But I must say that my request, my call out to our service provider friends is that, you know, whenever you're making selections, whenever you're making decisions, as you're rebuilding either the radio of the networks or the core of the networks behind 5G and cloud, make sure that these applications are grounded up into the concepts of any cloud.

MH: It sounds like you're telling us that everyone's going through a software transformation journey. They're all at different stages, but CSPs don't need to relive each step of the journey over and over and over. If they lay out their automation principles in a way that supports this multi-vendor environment.

JB: That's actually right. You know, so now we are coming to sort of a convergence. What I talked about at the start of the talk, you know, we talked about the four principles of automation, clearly four cycles to it. And that gives you a full 360 degree view of not only how you deploy a workload, not only how you consume software, not only how you define a service, but also how do you do assurance and manageability of your operations? And that's the four pillar framework for automation. And then we talked about cloud and how any cloud readiness to your workloads is almost critical. What we are interestingly finding Michael, and this is where I want to take a pause and just reflect on some of our learnings around any cloud, to our CSP friends who are listening out there to the show.

You know, we are finding very interesting findings and seems like a very simple concept. It doesn't take much, everyone would think that you take a software application, design it in such way that it could run on a Google cloud versus an Amazon versus, and VMware cloud and things like that. There shouldn't be much challenges to it. The fact of the matter is, and, you know, a real-time communication applications, whether we talk about radio or whether we talk about routing or whether we talk about core of the network, they seems to be very network hungry applications. What I mean by that is the intensity at which we shuffle packets through our networks and the concepts of latency and jitter is so prime that you need to almost start thinking about what are the challenges in networking that we need to overcome if we want to truly build a real time communications application that can run on any cloud.

And that's the thought of problem solving we are doing right now, as we speak. The amount of the unique challenges that we are seeing around in this area, whether we talk about how do we handle the simple concepts of network segregation, a concept of network segregation that has lived in our telco networks for almost three or more decades, almost segregate all the time, our control plane traffic from our user plane traffic. Now we onboard these applications on public cloud. How do we make sure that in public cloud environments network segregation is respected under the concept? I will bring up here the concepts of condition handling, signaling storms. We have often talked about in telco cloud environments, that you could have attach thousands and millions of subscribers at one go attaching to the network, just because of a power surge or a failure or a natural disaster, or a calamity and congestion handling and signaling storms are very normal to telco environments.

How do we make sure that signaling storm scenarios, congestion handling scenarios? When we turn on all of these workloads into public cloud environment on private cloud environments are well handled through throughput and scale. That's another nuance that we have been talking about when we talk about any cloud concepts that we are thinking that are we delivering to those promises of 10 milliseconds, 20 milliseconds latency, and acute amount of jitters that we want to deliver to in a 5G use case. Will the public clouds and the private clouds of the world be able to deliver to this. So these are the kinds of concepts we are discussing the topic of any cloud, as much as it looks simple on the surface, Michael trust me, you know, we are having a lot of fun. That's all I would say from a software design perspective. And, and then, you know, it's a very exciting journey. And, that's why I thought, you know, it's very relevant for us to bring these two concepts, not only the automation concept, but also the concepts of any cloud. Because right now I feel like we are still in large part of our discussions just scratching the surface, as I say, through the concepts of 5G or cloud or cloud native and not deep diving into the two concepts that we are talking today, which is automation in any cloud.

MH: You sound like a kid let loose in a wireless candy store.

JB: This is the passion that I live for. And, you know, if I recollect you know, last time we talked about and you asked me a very thought-provoking question last time, you know, what do you live for? And if you asked me that question again on this talk of ours, my answer would be the same. Do remember what I said? I gave you an answer in one single word and that single word was simplification. And I tell you I stand by my word. And I must say that, you know, these two concepts that we are talking, one is of automation. The other one is of readiness of workload applications to any cloud. If you pause and think about it, this is all geared up towards simplifying our networks. Simplification is the theme that lives through behind these two big concepts. And that's exactly what we need for our CSPs and our telco environments, which are getting complicated by every day. So that complexity has to be thrown out. And that is why I’m urging our friends out there on the CSP side, that we have to bring these two concepts up front and center. As we are building our 5G journey.

<<Go to previous episode     Go to next episode>>