>>from around the globe it's the >>cube >>presenting >>Future Cloud one event. A >>world of >>opportunities >>brought to you by Cisco. We're here with Dejoy Pandey a VP of emerging tech and incubation at Cisco. V. Joy. Good to see you welcome. >>Good to see you as well. Thank you Dave and pleasure to be here. >>So in 2020 we kind of had to redefine the notion of agility when it came to digital business or you know organizations, they had to rethink their concept of agility and business resilience. What are you seeing in terms of how companies are thinking about their operations in this sort of new abnormal context? >>Yeah I think that's a great question I think what what we're seeing is that pretty much the application is the center of the universe and if you think about it the application is actually driving brand recognition and the brand experience and the brand value. So the example I like to give is think about a banking app uh recovered that did everything that you would expect it to do. But if you wanted to withdraw cash from your bank you would actually have to go to the ATM and punch in some numbers and then look at your screen and go through a process and then finally withdraw cash. Think about what that would have, what that would do in a post pandemic era where people are trying to go contact less. And so in a situation like this the digitization efforts that all of these companies are going through and the modernization of the automation is what is driving brand recognition, brand trust and brand experience. >>Yeah. So I was gonna ask you when I heard you say that, I was gonna say well but hasn't it always been about the application? But it's different now, isn't it? So I wonder if you talk more about how the application is experience is changing? Yes. As a result of this new digital mandate. But how should organizations think about optimizing those experiences in this new world? >>Absolutely. And I think, yes, it's always been about the application, but it's becoming the center of the universe right now because all interactions with customers and consumers and even businesses are happening through that application. So if the application is unreliable or if the application is not available is untrusted insecure, uh, there's a problem. There's a problem with the brand with the company and the trust that consumers and customers have with our company. So if you think about an application developer, the weight he or she is carrying on their shoulders is tremendous because you're thinking about rolling features quickly to be competitive. That's the only way to be competitive in this world. You need to think about availability and resiliency, like you pointed out and experience, you need to think about security and trust. Am I as a customer or consumer willing to put my data in that application? So velocity availability, security and trust and all of that depends on the developer. So the experience, the security, the trust, the feature velocity is what is driving the brand experience now. >>So are those two tensions that say agility and trust, you know, zero trust used to be a buzzword now, it's a mandate. But are those two vectors counter posed? Can they be merged into one and not affect each other? Does the question makes sense? Right? Security usually handcuffs my speed. But how do you address that? >>Yeah, that's a great question. And I think if you think about it today, that's the way things are. And if you think about this developer, all they want to do is run fast because they want to build those features out and they're going to pick and choose a purpose and services that matter to them and build up their app and they want the complexities of the infrastructure and security and trust to be handled by somebody else is not that they don't care about it, but they want that abstraction so that is handled by somebody else. And typically within an organization we've seen in the past where there's friction between Netapp, Succop cited hopes and the cloud platform teams and the developer on one side and these these frictions and these meetings and toil actually take a toll on the developer and that's why companies and apps and developers are not as agile as they would like to be. So I think, but it doesn't have to be that way. So I think if there was something that would allow a developer to pick and choose, discover the apis that they would like to use, connect those api is in a very simple manner and then be able to scale them out and be able to secure them and in fact not just secure them during the run time when it's deployed, we're right off the back when the fire up that I'd and start developing the application, wouldn't that be nice? And as you do that, there is a smooth transition between that discovery connectivity and ease of consumption and security with the idea cops, netapp psych ops teams and see source to ensure that they are not doing something that the organization won't allow them to do in a very seamless manner. >>I want to go back and talk about security but I want to add another complexity before we do that. So for a lot of organizations in the public cloud became a staple of keeping the lights on during the pandemic. But it brings new complexities and differences in terms of latency security, which I want to come back to deployment models etcetera. So what are some of the specific networking challenges that you've seen with the cloud? Native architecture is how are you addressing those? >>Yeah. In fact, if you think about cloud, to me that is a that is a different way of seeing a distributed system. And if you think about a distributed system, what is at the center of the distributed system is the network. So my my favorite comment here is that the network is the wrong time for all distribute systems and modern applications. And that is true because if you think about where things are today, like you said, there's there's cloud assets that a developer might use in the banking example that I gave earlier. I mean if you want to build a contact less app so that you get verified, a customer gets verified on the app. They walk over to the ATM and they were broadcast without touching that ATM. In that kind of an example, you're touching the mobile Rus, let's say, Ohio escapees, you're touching Cloud API is where the back end might sit, you're touching on primary purpose, maybe it's an oracle database or a mainframe even where transactional data exists, you're touching branch pipes were the team actually exists and the need for consistency when you withdraw cash and you're carrying all of this and in fact there might be customer data sitting in Salesforce somewhere. So it's cloud API is a song premise branch, it's ass is mobile and you need to bring all of these things together and over time you will see more and more of these API is coming from various as providers. So it's not just cloud providers but saAS providers that the developer has to use. And so this complexity is very very real and this complexity is across the wide open internet. So the application is built across this wide open internet. So the problems of discovery ability, the problems of being able to simply connect these apis and manage the data flow across these apis. The problems of consistency of policy and consumption because all of these areas have their own nuances and what they mean, what the arguments mean and what the A. P. I. Actually means. How do you make it consistent and easy for the developer? That is the networking problem. And that is a problem of building out this network, making traffic engineering easy making policy easy, making scale out, scale down easy, all of that our networking problems. And so we are solving those problems. Uh Francisco >>Yeah the internet is the new private network but it's not so private. So I want to go back to security. I often say that the security model of building a moat, you dig the moat, you get the hardened castle that's just outdated now that the queen is left her castle. I always say it's dangerous out there. And the point is you touched on this? It's it's a huge decentralized system and with distributed apps and data, that notion of perimeter security, it's just no longer valid. So I wonder if you could talk more about how you're thinking about this problem and you definitely address some of that in your earlier comments. But what are you specifically doing to address this? And how do you see it evolving? >>Yeah, I mean that that's that's a very important point. I mean I think if you think about again the wide open internet being the wrong time for all modern applications, what is perimeter security in this uh in this new world? I mean it's to me it boils down to securing an API because again, going with that running example of this contact lists cash withdrawal feature for a bank. The FBI wherever it sits on tram branch sas cloud, IOS android doesn't matter that FBI is your new security perimeter and the data object that is trying to access is also the new security perimeter. So if you can secure ap to ap communication and P two data object communication, you should be good. So that is the new frontier. But guess what? Software is buggy? Everybody's software not saying Cisco software, everybody's Softwares buggy. Uh software is buggy, humans are not reliable and so things mature, Things change, Things evolve over time. So there needs to be defense in depth. So you need to secure at the API layer had the data object layer, but you also need to secure at every layer below it so that you have good defense and depth if any layer in between is not working out properly. So for us that means ensuring ap to ap communication, not just during long time when the app has been deployed and is running, but during deployment and also during the development life cycle. So as soon as the developer launches an ID, they should be able to figure out that this API is security uses reputable. It has compliant, it is compliant to my my organization's needs because it is hosted, let's say from Germany and my organization wants a P is to be used only if they are being hosted out of Germany. So compliance needs and and security needs and reputation. Is it available all the time? Is it secure and being able to provide that feedback all the time between the security teams and the developer teams in a very seamless real time manner? Yes, again, that's something that we're trying to solve through some of the services that we're trying to produce in SAN Francisco. >>Yeah, I mean those that layered approach that you're talking about is critical because every layer has, you know, some vulnerability and so you you've got to protect that with some depth in terms of thinking about security, how should we think about where where Cisco's primary value add is, I mean it's parts of the interview has a great security business. Is growing business. Is it your intention to to to to add value across the entire value chain? I mean obviously you can't do everything so you've got a partner but so has the we think about Cisco's role over the next I'm thinking longer term over the over the next decade. >>Yeah, I mean I think so. We do come in with good strength from the runtime side of the house. So if you think about the security aspects that we haven't played today, uh there's a significant set of assets that we have around user security around around uh with with do and password less. We have significant assets in random security. I mean the entire portfolio that Cisco brings to the table is I don't run time security. The security checks aspects around posture and policy that will bring to the table. And as you see, Cisco evolve over time, you will see us shifting left. I mean I know it's an overused term, but that is where security is moving towards. And so that is where api security and data security are moving towards. So learning what we have during runtime. Because again, runtime is where you learn what's available and that's where you can apply all of the M. L. And I models to figure out what works what doesn't taking those learnings, Taking those catalogs, taking that reputation database and moving it into the deployment and development life cycle and making sure that that's part of that entire they have to deploy to runtime chain is what you will see Cisco do overtime. >>That's fantastic phenomenal perspective video. Thanks for coming on the cube. Great to have you and look forward to having you again. >>Absolutely. Thank you. Pleasure to be here. >>This is Dave Volonte for the cube. Thank you for watching. Mhm. >>Mhm mm.

>> .. >> From around the globe. It's the Cube. Presenting Future Cloud. One event, a world of opportunities. Brought to you by CISCO. >> We're here with Vijoy Panday, VP of emerging tech and incubations at Cisco. Vijoy, good to see you. Welcome. >> Good to see you as well. Thank you, Dave. And pleasure to be here. >> So in 2020, we kind of had to redefine the notion of agility when it came to digital business or, you know organizations they had to rethink their concept of agility and business resilience. What are you seeing in terms of how companies are thinking about their operations in this sort of new abnormal context? >> Yeah, I think that's a great question. I think what, what we're seeing is that pretty much the application is the center of the universe. And if you think about it the application is actually driving brand recognition and the brand experience and the brand value. So, the example I like to give is think about a banking app, pre COVID, that did everything that you would expect it to do. But if you wanted to withdraw cash from your bank you would actually have to go to the ATM and punch in some numbers and then look at your screen and go through a process. And then finally withdraw cash. Think about what that would do in a post pandemic era where people are trying to go contact-less. And so in a situation like this the digitization efforts that all of these companies are going through and the modernization and the automation is what is driving brand recognition, brand trust and brand experience. >> Yeah. So, I was going to ask you when I heard you say that I was going to say well, but hasn't it always been about the application, but it's different now, isn't it. So I wondered if you'd talk more about how the application experience is changing. Yes, as a result of this new digital mandate, but how should organizations think about optimizing those experiences in this new world? >> Absolutely. And I think, yes, it's always been about the application, but it's becoming the center of the universe right now. Because all interactions with customers and consumers and even businesses, are happening through that application. So if the application is unreliable or if the application is not available, is not trusted, insecure. There's a problem. There's a problem with the brand, with the company and the trust that consumers and customers have with that company. So if you think about an application developer the weight he or she is carrying on their shoulders is tremendous because you're thinking about rolling features quickly to be competitive. That's the only way to be competitive in this world. You need to think about availability and resiliency like you pointed out, and experience. You need to think about security and trust. Am I as a customer, a consumer willing to put my data in their application? So velocity, availability, security, and trust, and all of that depends on the developer. So the experience, the security, the trust the feature velocity is what is driving the brand experience now. >> Those are two tensions, let's say agility and trust. You know, zero trust used to be a buzzword. Now it's a mandate. But are those two vectors counter posed? Can they be merged into one and not affect each other? Does the question make sense? Right? Security usually handcuffs my speed. But how do you address that? >> Yeah, that's a great question. I think if you think about it today that's the way things are. And if you think about this developer all they want to do is run fast because they want to build those features out and they want to pick and choose the APIs and services that matter to them and build out their app. And they want the complexities of infrastructure and security and trust to be handled by somebody else. It's not that they don't care about it but they want that abstraction. So that is handled by somebody else. And typically within an organization we've seen in the past where there's friction between Net Ops, Sec Ops, IT Ops and the cloud platform teams and the developer on one side. And these frictions and these meetings and toil actually take a toll on the developer. And that's why companies and apps and developers are not as agile as they would like to be. But it doesn't have to be that way. So I think if there was something that would allow a developer to pick and choose, discover the APIs that they would like to use, connect those APIs in a very simple manner and then be able to scale them out and be able to secure them. And in fact, not just secure them during the run time when it's deployed but right off the bat, when they fire up that IDE and start developing the application, wouldn't that be nice. And as you do that, there is a smooth transition between that discovery, connectivity and ease of consumption and security with the IT Ops, Net Ops, Sec Ops teams and CSOs to ensure that they're not doing something that their organization won't allow them to do in a very seamless manner. >> I want to come back and talk about security but I want to add another complexity before we do that. So for a lot of organizations and having the public cloud became a staple of keeping the lights on during the pandemic but it brings new complexities differences in terms of latency, security which I want to come back to deployment models, etc. So what are some of the specific networking challenges that you've seen with the cloud native architectures? How are you addressing those? >> Yeah. In fact, if you think about cloud, to me, that is a different way of saying a distributed system. And if you think about a distributed system, what is at the center of the distributed system is the network. So, my favorite commentary is that the network is the run time for all distributed systems and modern applications. And that is true because if you think about where things are today, like you said, there's cloud assets that a developer might use in the banking example that I gave earlier. I mean, if you want to build a contact-less app so that you get verified, a customer gets verified on the app, they walk over to the ATM and they were draw cash without touching that ATM. In that kind of an example you are touching the mobile iOS, let's say iOS APIs, you're touching cloud APIs where the backend might sit. You're touching on prem APIs. Maybe it's an Oracle database or a mainframe even where transactional data exists. You're touching branch APIs where the ATM actually exists. And there needs to be consistency when you withdraw cash and you're carrying all of this. And in fact, there might be customer data sitting in Salesforce somewhere. So it's cloud APIs, it's on prem, it's branch it's SaaS, it's mobile and you need to bring all of these things together. And over time, you'll see more and more of these APS coming from various SaaS providers. So it's not just cloud providers but SaaS providers that the developer has to use. And so this complexity is very, very real. And this complexity is across the wide open internet. So the application is built across this wide open internet. So the problems of discoverability, the problems of being able to simply connect these APIs and manage the data flow across these APIs, the problems of consistency of policy and consumption because all of these APIs have their own nuances and what they mean what the arguments mean and what the API actually means. How do you make it consistent and easy for the developer? That is the networking problem. And that is the problem of building out this network making traffic engineering easy, making policy easy making scale-out scale down easy all of that are networking problems. And so we are solving those problems at Cisco. >> Yeah, the internet is a new private network but it's not so private. So I want to come back to security. You know, I often say that the security model of building a moat, dig the moat you get the hardened castle. That's just outdated now. The queen has left her castle I always say, and it's dangerous out there. And the point is, and you touched on this, it's a huge decentralized system with distributed apps and data, that notion of perimeter security, it's just no longer valid. So I wonder if you could talk more about how you're thinking about this problem and you definitely address some of that in your earlier comments but what are you specifically doing to address this and how do you see it evolving? >> Yeah, I mean, that's, that's a very important point. I mean, I think if you think about again, the wide open internet being the run time for all modern applications. What is perimeter security in this, in this new world? I mean, it's, to me it boils down to securing an API because again going with that running example of this contact-less cash withdrawal feature for a bank, the API, wherever it sits on-prem, branch, SaaS, cloud, iOS, Android, doesn't matter. That API is your new security perimeter. And the data object that it's trying to access is also the new security perimeter. So if you can secure API to API communication and API to data object communication, you should be good. So that is the new frontier. But guess what, software is buggy, everybody's software, I'm not saying Cisco software everybody's software is buggy. Software is buggy. Humans are not reliable. And so things mature, things change things evolve over time. So there needs to be defense in depth. So you need to secure at the API layer and the data object layer, but you also need to secure at every layer below it, so that you have good defense in depth. If any layer in between is not working out properly. So for us, that means ensuring API to API communication not just during runtime, when the app has been deployed and is running, but during deployment and also during the development life cycle. So as soon as the developer launches an ID they should be able to figure out that this API is secure to use, is reputable. It is compliant to my organizations needs because it is hosted, let's say from Germany. And my organization wants APIs to be used only only if they are being hosted out of Germany. So compliance needs and security needs and reputation, is it available all the time? Is it secure? And being able to provide that feedback all the time between the security teams and the developer teams in a very seamless real-time manner. Because again, that's something that we're trying to solve through. Some of the services that we're trying to produce inside of Cisco. >> Yeah. I mean, those, that layered approach that you're talking about is, is critical because every layer has, you know, some vulnerability. And so you, you've got to protect that with some depth. In terms of thinking about security. How should we think about where Cisco's primary value add is? I mean, there's parts of the, you know, you guys are a great security business. It's a growing business. Is it your intension to add value across the entire value chain? I mean, obviously you can't do everything so you've got a partner. But how should we think about Cisco's role, you know, over the next I'm thinking longer term, over the next decade? >> Yeah. I mean, I think so we do come in with good strength from the run time side of it. So if you think about the security aspects that we have in play today, there's a significant set of assets that we have around user security, with duo and password-less. We have significant assets in runtime security. I mean, the entire portfolio that Cisco brings to the table is runtime security, the secure X, aspects around posture and policy that we bring to the table. And as you see Cisco evolve over time you will see us shifting left. I mean, I know it's an overused term but that is where security is moving towards. And so that is where API security and data security are moving towards. So learning what we have during run time, because again run time is where you learn what's available. And that's where you can apply all of the ML and AI models to figure out what works, what doesn't. Taking those learnings, taking those catalogs, taking that reputation database and moving it into the deployment and development life cycle and making sure that that's part of that entire dev to deploy to run time chain is what you will see Cisco do overtime. >> That's fantastic, phenomenal perspectives. Thanks for coming on the Cube. Great to have you and look forward to having you again. >> Absolutely. Thank you. Pleasure to be here. >> This is Dave Volante for the Cube. Thank you for watching.

>> From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020 Virtual brought to you by Red Hat, the CloudNative Computing Foundation, and Ecosystem Partners. >> Hi and welcome back to theCUBE's coverage of KubeCon, CloudNativeCon 2020 in Europe, of course the virtual edition. I'm Stu Miniman and happy to welcome back to the program one of the keynote speakers, he's also a board member of the CNCF, Vijoy Pandey who is the vice president and chief technology officer for Cloud at Cisco. Vijoy, nice to see you and thanks so much for joining us. >> Thank you Stu, and nice to see you again. It's a strange setting to be in but as long as we are both health, everything is good. >> Yeah, it's still a, we still get to be together a little bit even though while we're apart, we love the engagement and interaction that we normally get through the community but we just have to do it a little bit differently this year. So we're going to get to your keynote. We've had you on the program to talk about "Network, Please Evolve", been watching that journey. But why don't we start it first, you know, you've had a little bit of change in roles and responsibility. I know there's been some restructuring at Cisco since the last time we got together. So give us the update on your role. >> Yeah, so that, yeah let's start there. So I've taken on a new responsibility. It's VP of Engineering and Research for a new group that's been formed at Cisco. It's called Emerging Tech and Incubation. Liz Centoni leads that and she reports into Chuck. The role, the charter for this team, this new team, is to incubate the next bets for Cisco. And, if you can imagine, it's natural for Cisco to start with bets which are closer to its core business, but the charter for this group is to mover further and further out from Cisco's core business and takes this core into newer markets, into newer products, and newer businesses. I am running the engineering and research for that group. And, again, the whole deal behind this is to be a little bit nimble, to be a little startupy in nature, where you bring ideas, you incubate them, you iterate pretty fast and you throw out 80% of those and concentrate on the 20% that make sense to take forward as a venture. >> Interesting. So it reminds me a little bit, but different, I remember John Chambers a number of years back talking about various adjacencies, trying to grow those next, you know, multi-billion dollar businesses inside Cisco. In some ways, Vijoy, it reminds me a little bit of your previous company, very well known for, you know, driving innovation, giving engineering 20% of their time to work on things. Give us a little bit of insight. What's kind of an example of a bet that you might be looking at in the space? Bring us inside a little bit. >> Well that's actually a good question and I think a little bit of that comparison is, are those conversations that taking place within Cisco as well as to how far out from Cisco's core business do we want to get when we're incubating these bets. And, yes, my previous employer, I mean Google X actually goes pretty far out when it comes to incubations. The core business being primarily around ads, now Google Cloud as well, but you have things like Verily and Calico and others which are pretty far out from where Google started. And the way we are looking at these things within Cisco is, it's a new muscle for Cisco so we want to prove ourselves first. So the first few bets that we are betting upon are pretty close to Cisco's core but still not fitting into Cisco's BU when it comes to go-to-market alignment or business alignment. So while the first bets that we are taking into account is around API being the queen when it comes to the future of infrastructure, so to speak. So it's not just making our infrastructure consumable as infrastructure's code, but also talking about developer relevance, talking about how developers are actually influencing infrastructure deployments. So if you think about the problem statement in that sense, then networking needs to evolve. And I talked a lot about this in the past couple of keynotes where Cisco's core business has been around connecting and securing physical endpoints, physical I/O endpoints, whatever they happen to be, of whatever type they happen to be. And one of the bets that we are, actually two of the bets that we are going after is around connecting and securing API endpoints wherever they happen to be of whatever type they happen to be. And so API networking, or app networking, is one big bet that we're going after. Our other big bet is around API security and that has a bunch of other connotations to it where we think about security moving from runtime security where traditionally Cisco has played in that space, especially on the infrastructure side, but moving into API security which is only under the developer pipeline and higher up in the stack. So those are two big bets that we're going after and as you can see, they're pretty close to Cisco's core business but also very differentiated from where Cisco is today. And once when you prove some of these bets out, you can walk further and further away or a few degrees away from Cisco's core as it exists today. >> All right, well Vijoy, I mentioned you're also on the board for the CNCF, maybe let's talk a little bit about open source. How does that play into what you're looking at for emerging technologies and these bets, you know, so many companies, that's an integral piece, and we've watched, you know really, the maturation of Cisco's journey, participating in these open source environments. So help us tie in where Cisco is when it comes to open source. >> So, yeah, so I think we've been pretty deeply involved in open source in our past. We've been deeply involved in Linux foundational networking. We've actually chartered FD.io as a project there and we still are. We've been involved in OpenStack. We are big supporters of OpenStack. We have a couple of products that are on the OpenStack offering. And as you all know, we've been involved in CNCF right from the get go as a foundational member. We brought NSM as a project. It's sandbox currently. We're hoping to move it forward. But even beyond that, I mean we are big users of open source. You know a lot of us has offerings that we have from Cisco and you would not know this if you're not inside of Cisco, but Webex, for example, is a big, big user of linger D right from the get go from version 1.0. But we don't talk about it, which is sad. I think for example, we use Kubernetes pretty deeply in our DNAC platform on the enterprise site. We use Kubernetes very deeply in our security platforms. So we are pretty deep users internally in all our SAS products. But we want to press the accelerator and accelerate this whole journey towards open source quite a bit moving forward as part of ET&I, Emerging Tech and Incubation as well. So you will see more of us in open source forums, not just the NCF but very recently we joined the Linux Foundation for Public Health as a premier foundational member. Dan Kohn, our old friend, is actually chartering that initiative and we actually are big believers in handling data in ethical and privacy preserving ways. So that's actually something that enticed us to join Linux Foundation for Public Health and we will be working very closely with Dan and the foundational companies there to, not just bring open source, but also evangelize and use what comes out of that forum. >> All right. Well, Vijoy, I think it's time for us to dig into your keynote. We've spoken with you in previous KubeCons about the "Network, Please Evolve" theme that you've been driving on, and big focus you talked about was SD-WAN. Of course anybody that been watching the industry has watched the real ascension of SD-WAN. We've called it one of those just critical foundational pieces of companies enabling Multicloud, so help us, you know, help explain to our audience a little bit, you know, what do you mean when you talk about things like CloudNative, SD-WAN, and how that helps people really enable their applications in the modern environment? >> Yeah, so, well we we've been talking about SD-WAN for a while. I mean, it's one of the transformational technologies of our time where prior to SD-WAN existing, you had to stitch all of these MPLS labels and actual data connectivity across to your enterprise or branch and SD-WAN came in and changed the game there. But I think SD-WAN as it exists today is application-alaware. And that's one of the big things that I talk about in my keynote. Also, we've talked about how NSM, the other side of the spectrum, is how NSM, or network service mesh, has actually helped us simplify operational complexities, simplify the ticketing and process hell that any developer needs to go through just to get a multicloud, multicluster app up and running. So the keynote actually talked about bringing those two things together where we've talked about using NSM in the past, in chapter one and chapter two, ah chapter two, no this is chapter three and at some point I would like to stop the chapters. I don't want this to be like, like an encyclopedia of networking (mumbling) But we are at chapter three and we are talking about how you can take the same consumption models that I talked about in chapter two which is just adding a simple annotation in your CRD and extending that notion of multicloud, multicluster wires within the components of our application but extending it all the way down to the user in an enterprise. And as you saw an example, Gavin Russom is trying to give a keynote holographically and he's suffering from SD-WAN being application alaware. And using this construct of a simple annotation, we can actually make SD-WAN CloudNative. We can make it application-aware, and we can guarantee the SLOs that Gavin is looking for in terms of 3D video, in terms of file access or audio just to make sure that he's successful and Ross doesn't come in and take his place. >> Well I expect Gavin will do something to mess things up on his own even if the technology works flawly. You know, Vijoy the modernization journey that customers are on is a neverending story. I understand the chapters need to end on the current volume that you're working on. But, you know, we'd love to get your view point. You talk about things like service mesh. It's definitely been a hot topic of conversation for the last couple of years. What are you hearing from your customers? What are some of the the kind of real challenges but opportunities that they see in today's CloudNative space? >> In general, service meshes are here to stay. In fact, they're here to proliferate to some degree and we are seeing a lot of that happening where not only are we seeing different service meshes coming into the picture through various open source mechanisms. You've got Istio there, you've got linger D, you've got various proprietary notions around control planes like App Mesh from Amazon. There's Console which is an open source project But not part of (mumbles) today. So there's a whole bunch of service meshes in terms of control planes coming in on volumes becoming a de facto side car data plane, whatever you would like to call it, de facto standard there which is good for the community I would say. But this proliferation of control planes is actually a problem. And I see customers actually deploying a multitude of service meshes in their environment. And that's here to stay. In fact, we are seeing a whole bunch of things that we would use different tools for. Like API Gate was in the past. And those functions are actually rolling into service meshes. And so I think service meshes are here to stay. I think the diversity of some service meshes is here to stay. And so some work has to be done in bringing these things together and that's something that we are trying to focus in on all as well because that's something that our customers are asking for. >> Yeah, actually you connected for me something I wanted to get your viewpoint on. Dial back you know 10, 15 years ago and everybody would say, "Ah, you know, I really want to have single pane of glass "to be able to manage everything." Cisco's partnering with all of the major cloud providers. I saw, you know, not that long before this event, Google had their Google Cloud show talking about the partnership that you have with Cisco with Google. They have Anthos. You look at Azure has Arc. You know, VMware has Tanzu. Everybody's talking about, really, kind of this multicluster management type of solution out there. And just want to get your viewpoint on this Vijoy is to, you know, how are we doing on the management plane and what do you think we need to do as a industry as a whole to make things better for customers? >> Yeah, but I think this is where I think we need to be careful as an industry, as a community and make things simpler for our customers because, like I said, the proliferation of all of these control planes begs the question, do we need to build something else to bring all of these things together. And I think the SMI apropos from Microsoft is bang on on that front where you're trying to unify at least the consumption model around how you consume these service meshes. But it's not just a question of service meshes. As you saw in the SD-WAN and also going back in the Google discussion that you just, or Google conference that we just offered It's also how SD-WANs are going to interoperate with the services that exist within these cloud silos to some degree. And how does that happen? And there was a teaser there that you saw earlier in the keynote where we are taking those constructs that we talked about in the Google conference and bringing it all the way to a CloudNative environment in the keynote. But I think the bigger problem here is how do we manage this complexity of disparate stacks, whether it's service meshes, whether it's development stacks, or whether it's SD-WAN deployments, how do we manage that complexity? And, single pane of glass is over loaded as a term because it brings in these notions of big, monolithic panes of glass. And I think that's not the way we should be solving it. We should be solving it towards using API simplicity and API interoperability. I think that's where we as a community need to go. >> Absolutely. Well, Vijoy, as you said, you know, the API economy should be able to help on these, you know, multi, the service architecture should allow things to be more flexible and give me the visibility I need without trying to have to build something that's completely monolithic. Vijoy, thanks so much for joining. Looking forward to hearing more about the big bets coming out of Cisco and congratulations on the new role. >> Thank you Stu. It was a pleasure to be here. >> All right, and stay tuned for much more coverage of theCUBE at KubeCon, CloudNativeCon. I'm Stu Miniman and thanks for watching. (light digital music)

(upbeat music) >> From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020 Virtual brought to you by Red Hat, the Cloud Native Computing Foundation, and the ecosystem partners. >> Hi, and welcome back to theCUBE's coverage of KubeCon + CloudNativeCon 2020 in Europe, of course, the virtual edition. I'm Stu Miniman, and happy to welcome you back to the program. One of the keynote speakers is also a board member of the CNCF, Vijoy Pandey, who is the Vice President and Chief Technology Officer for Cloud at Cisco. Vijoy, nice to see you, thanks so much for joining us. >> Hi there, Stu, so nice to see you again. It's a strange setting to be in, but as long as we are both healthy, everything's good. >> Yeah, we still get to be together a little bit even though while we're apart. We love the the engagement and interaction that we normally get to the community, but we just have to do it a little bit differently this year. So we're going to get to your keynote. We've had you on the program to talk about "Networking, Please Evolve". I've been watching that journey. But why don't we start at first, you've had a little bit of change in roles and responsibility. I know there's been some restructuring at Cisco since the last time we got together. So give us the update on your role. >> Yeah, so let's start there. So I've taken on a new responsibility. It's VP of Engineering and Research for a new group that's been formed at Cisco. It's called Emerging Tech and Incubation. Liz Centoni leads that and she reports on to Chuck. The charter for the team, this new team, is to incubate the next bets for Cisco. And if you can imagine, it's natural for Cisco to start with bets which are closer to its core business. But the charter for this group is to move further and further out from Cisco's core business and take Cisco into newer markets, into newer products, and newer businesses. I'm running the engineering and resource for that group. And again, the whole deal behind this is to be a little bit nimble, to be a little bit, to startupy in nature, where you bring ideas, you incubate them, you iterate pretty fast, and you throw out 80% of those, and concentrate on the 20% that makes sense to take forward as a venture. >> Interesting. So it reminds me a little bit but different, I remember John Chambers, a number of years back, talking about various adjacencies trying to grow those next multi-billion dollar businesses inside Cisco. In some ways, Vijoy, it reminds me a little bit of your previous company, very well known for driving innovation, giving engineers 20% of their time to work on things, maybe give us a little bit insight, what's kind of an example of a bet that you might be looking at in this space, bring us in tight a little bit. >> Well, that's actually a good question. And I think a little bit of that comparison is all those conversations are taking place within Cisco as well as to how far out from Cisco's core business do we want to get when we're incubating these bets? And yes, my previous employer, I mean, Google X actually goes pretty far out when it comes to incubations, the core business being primarily around ads, now Google Cloud as well. But you have things like Verily and Calico, and others, which are pretty far out from where Google started. And the way we're looking at the these things within Cisco is, it's a new muscle for Cisco, so we want to prove ourselves first. So the first few bets that we are betting upon are pretty close to Cisco's core but still not fitting into Cisco's BU when it comes to, go to market alignment or business alignment. So one of the first bets that we're taking into account is around API being the queen when it comes to the future of infrastructure, so to speak. So it's not just making our infrastructure consumable as infrastructure as code but also talking about developer relevance, talking about how developers are actually influencing infrastructure deployments. So if you think about the problem statement in that sense, then networking needs to evolve. And I've talked a lot about this in the past couple of keynotes, where Cisco's core business has been around connecting and securing physical endpoints, physical I/O endpoints, wherever they happen to be, of whatever type they happen to be. And one of the bets that we are, actually two of the bets, that we're going after is around connecting and securing API endpoints, wherever they happen to be, of whatever type they happen to be. And so API networking or app networking is one big bet that we're going after. Another big bet is around API security. And that has a bunch of other connotations to it, where we think about security moving from runtime security, where traditionally Cisco has played in that space, especially on the infrastructure side, but moving into API security, which is earlier in the development pipeline, and higher up in the stack. So those are two big bets that we're going after. And as you can see, they're pretty close to Cisco's core business, but also are very differentiated from where Cisco is today. And once you prove some of these bets out, you can walk further and further away, or a few degrees away from Cisco's core. >> All right, Vijoy, why don't you give us the update about how Cisco is leveraging and participating in open source? >> So I think we've been pretty, deeply involved in open source in our past. We've been deeply involved in Linux Foundation Networking. We've actually chartered FD.io as a project there and we still are. We've been involved in OpenStack, we have been supporters of OpenStack. We have a couple of products that are around the OpenStack offering. And as you all know, we've been involved in CNCF, right from the get-go, as a foundation member. We brought NSM as a project. I had Sandbox currently, but we're hoping to move it forward. But even beyond that, I mean, we are big users of open source, a lot of those has offerings that we have from Cisco, and you will not know this if you're not inside of Cisco. But Webex, for example, is a big, big user of Linkerd, right from the get-go, from version 1.0, but we don't talk about it, which is sad. I think, for example, we use Kubernetes pretty deeply in our DNAC platform on the enterprise side. We use Kubernetes very deeply in our security platforms. So we're pretty good, pretty deep users internally in our SaaS products. But we want to press the accelerator and accelerate this whole journey towards open source, quite a bit moving forward as part of ET&I, Emerging Tech and Incubation, as well. So you will see more of us in open source forums, not just CNCF, but very recently, we joined the Linux Foundation for Public Health as a premier foundational member. Dan Kohn, our old friend, is actually chartering that initiative, and we actually are big believers in handling data in ethical and privacy-preserving ways. So that's actually something that enticed us to join Linux Foundation for Public Health, and we will be working very closely with Dan and foundational companies that do not just bring open source but also evangelize and use what comes out of that forum. >> All right, well, Vijoy, I think it's time for us to dig into your keynote. We've we've spoken with you in previous KubeCons about the "Network, Please Evolve" theme that you've been driving on. And big focus you talked about was SD-WAN. Of course, anybody that's been watching the industry has watched the real ascension of SD-WAN. We've called it one of those just critical foundational pieces of companies enabling multi-cloud. So help explain to our audience a little bit, what do you mean when you talk about things like Cloud Native SD-WAN and how that helps people really enable their applications in the modern environment? >> Yes, well, I mean, we've been talking about SD-WAN for a while. I mean, it's one of the transformational technologies of our time where prior to SD-WAN existing, you had to stitch all of these MPLS labels and actually get your connectivity across to your enterprise or branch. And SD-WAN came in and changed the game there, but I think SD-WAN, as it exists today, is application-unaware. And that's one of the big things that I talk about in my keynote. Also, we've talked about how NSM, the other side of the spectrum, is how NSM or Network Service Mesh has actually helped us simplify operational complexities, simplify the ticketing and process health that any developer needs to go through just to get a multi-cloud, multi-cluster app up and running. So the keynote actually talked about bringing those two things together, where we've talked about using NSM in the past in chapter one and chapter two. And I know this is chapter three, and at some point, I would like to stop the chapters. I don't want this like an encyclopedia of "Networking, Please Evolve". But we are at chapter three, and we are talking about how you can take the same consumption models that I talked about in chapter two, which is just adding a simple annotation in your CRD, and extending that notion of multi-cloud, multi-cluster wires within the components of our application, but extending it all the way down to the user in an enterprise. And as we saw an example, Gavin Belson is trying to give a keynote holographically and he's suffering from SD-WAN being application-unaware. And using this construct of a simple annotation, we can actually make SD-WAN cloud native, we can make it application-aware, and we can guarantee the SLOs, that Gavin is looking for, in terms of 3D video, in terms of file access for audio, just to make sure that he's successful and Ross doesn't come in and take his place. >> Well, I expect Gavin will do something to mess things up on his own even if the technology works flawlessly. Vijoy, the modernization journey that customers are on is a never-ending story. I understand the chapters need to end on the current volume that you're working on, but we'd love to get your viewpoint. You talk about things like service mesh, it's definitely been a hot topic of conversation for the last couple of years. What are you hearing from your customers? What are some of the kind of real challenges but opportunities that they see in today's cloud native space? >> In general, service meshes are here to stay. In fact, they're here to proliferate to some degree, and we are seeing a lot of that happening, where not only are we seeing different service meshes coming into the picture through various open source mechanisms. You've got Istio there, you've Linkerd, you've got various proprietary notions around control planes like App Mesh, from Amazon, there's Consul, which is an open source project, but not part of CNCF today. So there's a whole bunch of service meshes in terms of control planes coming in. Envoy is becoming a de facto sidecar data plane, whatever you would like to call it, de facto standard there, which is good for the community, I would say. But this proliferation of control planes is actually a problem. And I see customers actually deploying a multitude of service meshes in their environment, and that's here to stay. In fact, we are seeing a whole bunch of things that we would use different tools for, like API gateways in the past, and those functions actually rolling into service meshes. And so I think service meshes are here to stay. I think the diversity of service meshes is here to stay. And so some work has to be done in bringing these things together. And that's something that we are trying to focus in on as well. Because that's something that our customers are asking for. >> Yeah, actually, you connected for me something I wanted to get your viewpoint on, go dial back, 10, 15 years ago, and everybody would say, "Oh, I really want to have a single pane of glass "to be able to manage everything." Cisco's partnering with all of the major cloud providers. I saw, not that long before this event, Google had their Google Cloud Show, talking about the partnership that you have with, Cisco with Google. They have Anthos, you look at Azure has Arc, VMware has Tanzu. Everybody's talking about really the kind of this multi-cluster management type of solution out there, and just want to get your viewpoint on this Vijoy as to how are we doing on the management plane, and what do you think we need to do as an industry as a whole to make things better for customers? >> Yeah, I think this is where I think we need to be careful as an industry, as a community and make things simpler for our customers. Because, like I said, the proliferation of all of these control planes begs the question, do we need to build something else to bring all these things together? I think the SMI proposal from Microsoft is bang on on that front, where you're trying to unify at least the consumption model around how you consume these service meshes. But it's not just a question of service meshes as you saw in the SD-WAN announcement back in the Google discussion that we just, Google conference that you just referred. It's also how SD-WANs are going to interoperate with the services that exist within these cloud silos to some degree. And how does that happen? And there was a teaser there that you saw earlier in the keynote where we are taking those constructs that we talked about in the Google conference and bringing it all the way to a cloud native environment in the keynote. But I think the bigger problem here is how do we manage this complexity of this pallet stacks? Whether it's service meshes, whether it's development stacks, or whether it's SD-WAN deployments, how do we manage that complexity? And single pane of glass is overloaded as a term, because it brings in these notions of big monolithic panes of glass. And I think that's not the way we should be solving it. We should be solving it towards using API simplicity and API interoperability. And I think that's where we as a community need to go. >> Absolutely. Well, Vijoy, as you said, the API economy should be able to help on these, the service architecture should allow things to be more flexible and give me the visibility I need without trying to have to build something that's completely monolithic. Vijoy, thanks so much for joining. Looking forward to hearing more about the big bets coming out of Cisco, and congratulations on the new role. >> Thank you, Stu. It was a pleasure to be here. >> All right, and stay tuned for lots more coverage of theCUBE at KubeCon + CloudNativeCon. I'm Stu Miniman. Thanks for watching. (upbeat music)

>>Live from San Diego, California at the cube covering to clock in cloud native con brought to you by red hat, the cloud native computing foundation and its ecosystem Marsh. >>Welcome back. This is the cubes coverage of CubeCon cloud native con here in San Diego. I am Stu Miniman. He is Justin Warren and our guest for this segment, a cube alumni VJ pan day, who's the vice president and CTO of cloud inside Cisco. Also on the keynote stage this morning. Be joined. Thanks so much for joining us again. Welcome. Pleasure to be here. All right, so, uh, we've got to see the sequel on stage. Uh, network. Please evolve. Part two. Uh, there were magnets involved. Uh, there were some XKCD Keke humor in there, which, uh, definitely this audience appreciates it. Um, but part to come on the networking industry is known for its lightening fast changes. Um, Oh, maybe I'm thinking of this ecosystem, but um, it could give her audience a little bit of a taste of, uh, you know, the, the, the, the premise, uh, of, of what you were talking about. >>Absolutely. I think, uh, so back in Barcelona I talked about how networking needed to evolve for a cloud native environment and the whole idea behind that talk was we've gone from physical infrastructure, which we call infant one dot Oh two virtual, which is in for two Dato. And in that transition, really nothing much changed except taking everything that was physical or even in the application space, taking monolithic apps and just wrapping everything up in a VM. And that was okay because you got a few things around a agility, you got disaster recovery, you got a few aspects that you would like. But largely things are monolithic largely, especially on the networking side, things were still being touted as routers or via routers, switches or switches, mr music, BGP and so on and so forth. Now when you're looking at containers and microservices, and I'm not talking about containers, which are just different shifts, but if you're breaking the application down into microservices or you're using silver less to build your applications, the app is getting thinner and thinner and much more distributed. >>That's where there's a complete reimagining of the application. There's a rearchitecture and because of that, the operational architecture is changing because you can't just have a database admin. The database is now 500 components. So you need your SRE organizations, your DevOps organizations to be aligned to that. You also, and therefore your organization changes because you're following this architecture paradigm shift. Yeah. So when that happens, how can the infrastructure remain the same? So you cannot use the concepts that you've used for physical and virtual networking, which have aggregate statistical networks to solve an application networking problem. Right? >>So w w one of the big challenges there is enterprise especially they've got a lot of applications. >>When you talk about how many of them are modern apps, it's a very small segment. You know, we talk about, Oh, 20% of apps in the cloud. Well how many apps have been modernized? It's a smaller piece of that and we need to have the bridge to the customer in all of the places that they are and are going. And you know, cloud is not a destination. It's, it's an operational model. So how do I, how do I span all of the environment? And embrace them and still keep, keep, everything's moving forward to, to drive the business. That's a good question. So I think if you look at, so to your point, there is a small percentage of apps that are cloud native today. I don't think it's as small as 20% I think it's closer to around 40 but we may differ on that number. >>What we are seeing is that that number is only growing. So that's a trend to watch out for. And the other trend to watch out for is it's not just the mobile front end or the dashboard that's becoming cloud native, which was the case a couple of years ago. You're seeing databases, you're seeing a middleware, you're seeing data processing pipelines, things that are critical to our business, do all of the apps that are getting modernized and becoming cloud native. So that's one aspect. The other aspect is you might have a function that remains and legacy, so to speak and get replaced by a cloud native app that does the same thing. So you might not rewrite it, but you might replace it. So that's happening quite a bit. And so, but to your question, how do you connect all of this, these things together? Cloud native is a philosophy. It's a way of operating an infrastructure is a way of building in the redundancy we have building in velocity. So that philosophy needs to percolate not just the new cloud native apps, but you need to uplift the old infrastructure and let them become cloud native as well. So things that we're doing with an assignment, things that we're doing with the attrition and our dynamic and a whole bunch of efforts within Cisco are geared towards uplifting the older gear on all the infrastructure in order applications. Do a client cloud native operational paradigm. >>Yeah, that's true. You mentioned part of that requires changing the way human behavior works, that it changing the way you operate a lot of this infrastructure. So it's not just about purchasing a particular tool, it's about actually using different tools in completely new and different ways. So what are some of the ways that Cisco is changing the kinds of products that it offers to customers that encourages them to operate their infrastructure in a new way? >>So let me start with the networking piece and since it's fresh and new from the keynote today, uh, one of the things, if you think about again, the developers and how they deal with applications, they want the network to be simple, available and pervasive. And so if you think about this in couple of tiers, so there is a physical infrastructure that sits below everything that is again, pervasive across a multicloud environment. And it goes all the way from your handset to the data center, including the edge compute locations. It connects everything together. So taking a network like that and simplifying it in terms of automation, in terms of how dev ops can handle that networking subsystem, in terms of how do you ensure that policy is consistent across this common environment, that is something that Cisco is pushing pretty deeply. So we have this multi-domain architecture that allows you to push policy across the entire network handset to the data center through the van. >>So that's one aspect of it. But above this sits a platform layer that is closer to the developer. And this is why things like NSM comment, because the developers don't want to deal with the bells and whistles at the physical or the virtual infrastructure layer. They are defining the CRDs. They are defining that if I'm a microservice, I want to talk to another microservice, all of bare metal orders over less function. I just want to connect a to B within my application. I don't care about every other application that exists in your infrastructure. And these are the attributes that I want from that connection. So it's like a watch and Wyatt like a bus and these are the attributes to the bus and that's what we're trying to handle from a cloud native perspective. So that's what you see from the NSM side of things. >>So, uh, we, we just had to go on talking about the database and talking about a cloud native database. And, uh, the way he really describes it is, you know, it's baked into Kubernetes even though Vitez doesn't have to have Coobernetti's. And he said he even had customers that it made it possible for them to be able to, uh, have that database from one cloud to another without needing to talk to his team. Uh, and it's, it's made things possible. Help us understand how the network service mesh fit into solutions like that. >>Absolutely. And I think if you think, I mean, I love the Virtus project they've graduated, so congratulations to them. But I think, uh, the concept behind that is taking the multicloud aspect of everything that we do to a layer which is higher in the stack. So we've talked about multicloud in terms of networking, in terms of compute, uh, in terms of infrastructure primarily, but looking at a database which is multicloud looking at storage, which is multicloud. I think that's the next layer of evolution in this entire stack. But one of the examples that are talked about in my keynote, very simple, but as, or not retest, it doesn't matter. Something that every organization wants to do is dig databases that are scattered across a multitude of on-prem or a multitude of clouds and just replicate. And to do that replication, the amount of pain that any organization needs to go through today. >>It's just like programming with magnets. Going back to my keynote where you're dealing with the technical complexities of doing this, you're talking to so many routers and switches, you're talking to firewalls, you're talking to colo providers, you're talking to cloud providers and especially every tore provider has their own compliance and configuration paradigms. So all of that being different. That's just the technical complexity within one organization. They like multitudes of teams. They have dev ops, net ops, tech ops, they all need to talk to each other. Even within Cisco we talked to our Cisco ID guys. Just dev ops is like 20 teams. There's not one team. So just imagine talking to all of those teams trying to fix this thing and trying to get just database application, simple problem like that. And then process complexity. So all of those things exist. And with NSM, all you do is say, just put me on the Santa Sam domain that lets me talk securely to every other database on the same domain, wherever they happen to be in a different cluster within the same data center or geographically somewhere else in the globe. I really don't care. And NSM basically takes care of that. So that's the simplicity that we're going after. And it's a simplicity that walks across. There are seven meshes across simple layer three problems like this across service provider use cases across a whole bunch of use cases. >>Hmm. Yeah. And it just, the simple act of moving data around you would think that we'd managed to solve that problem by now, but it turns out it's hard problem to solve and being able to connect this myriad of new services together to one why we have technologies like service mesh is changing the nature of the way we operate it. And, and as you say, putting tools in place to automate a lot of the mechanisms that go on so that we as humans don't have to do it anymore because it's just not attractive or attractable problem for the humans to deal with. And I think a lot of organizations are still wrestling with that concept of, of how they can change the way that they do things so that the humans aren't going to be able to do this. It's not actually a matter of choice. They are going to be going and having, they're going to go and do different things, new and interesting things, but they're going to be at a higher level of abstraction. And I think a lot of people are very concerned by that, that we may not have jobs anymore. No, no, no, you can't have these jobs. It is just not possible for humans to do them. We need to get you to go and do these other new jobs so that we can get on with solving these business problems. >>That's a very good problem point. And I think, uh, so prior to this role I was at Google and I ran the networking infrastructure for a while and then I ended up writing the automation and telemetry stack for running that infrastructure. And one of the things that we used to say back there was, if you are infrastructure depends on humans to scale out, then there aren't enough humans to hire. Even if you have the dollars to invest, there aren't enough humans to hire to fix that problem in a human centric way. So one of the things that we are doing at Cisco for example, is this whole push towards intent based networking. And to me that's an evolution from where SDN was to now where IBM is, because SDN has had these very specific connotations around it with said software defined separation of control and data. >>It gets into this very heated debates about what this is. To me, the answer is actually intent based networking. We did some of that back at Google as well, which is treat the entire network as a singular entity and operated in a very declarative fashion. That's what this is, regardless of whether they're built in a control data separated with all their traditional BGP networks, so we are pushing IBN in a very big way and the whole problem statement there is to your point, humans can't comprehend the complexities that arise. One one, one quick topic where we were sending telemetry data through SNMP, now we are sending telemetry data was the streaming and the amount of data that any operator receives is just through the roof. What are you going to do with it? So humans can't deal with that kind of complexity. So putting formal verification, formal models, formal closed loop automation systems with AI in place. I think that's the only way to go forward at least on large scale networks and on the other side, I think on the application side, like I said, being deep and narrow and being very selfish about the application that you're trying to connect to simplifies the problem because as an app developer I'm only concerned about this particular app and have what it connects to and that is going to attract a book from a human perspective. >>Yes. thank you so much. I think anyone that's attended this conference can definitely agree with that. There is a flood of information that no one person could keep up with. So, uh, thank you so much for joining us. We hope that, uh, your journey of network please evolve, uh, that we had comes to a successful conclusion in the near future. Absolutely. Look forward to chatting with you again soon for Justin Warren. I am Stu Miniman. Uh, stay tuned. We're going to wrap up day two, and we have a whole nother day tomorrow of our coverage here from CubeCon cloud native con 2019 in San Diego. Thank you for watching the queue.

>> Live from Barcelona, Spain. it's theCUBE. Covering KubeCon CloudNativeCon Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation and ecosystem partners. >> Welcome back to theCUBE, two days live coverage here in Barcelona, Spain at KubeCon CloudNativeCon 2019. I'm Stu Miniman. My co-host is Corey Quinn, and happy to welcome to the program first-time guest Vijoy Pandey, who's the vice president and CTO of Cloud at Cisco, and Vijoy, it's a relatively new job for you. Something we're still measuring in months. So, why don't we start there, give our audience a little bit of your background and what brought you to the Cisco Cloud team? >> Sure, so first of all thank you Stu, thank you Corey. Glad to be here. Yes, I am measuring my tenure right now in months. It was days, now it's months, soon it will be years and soon it will be forgotten, but I did come from Google. I spent a whole bunch of time there in the networking space. I actually ran their data center footprint. I also ran the ram footprint for a couple of years. And then I ended up building the automation, modeling, telemetry, data analytic stack for all of their physical infrastructure, for a while. >> Okay, so how much time do we have? Because I always put out there, I'm an networking guy by background and if you talk about just the Google network, how do we get our search results, and our ads to us globally in a short period of time. And you talk about undersea cables, I mean, Google was the example. The first time I heard about SDN and what that was going to be, oh, well lets look at what Google was doing, and when Cloud rolled out, Google's network was really second to none. Now of course, you move over to Cisco, which knows a thing or two about networking. Can you tell us some of those, I guess help connect the dots for me. We've had this premise that the hyperweb scale, what they have done, is what's bleeding into the enterprise. That's what Kubernetes is, what Google did at Boar. And from a networking standpoint, some of the things that the top 20 hyper-scale companies were doing we're now starting to see into the enterprise. Does that premise hold water for you? >> Yeah, that's correct. But what I think what you need to realize is that not everybody is hyper-scaler, not everybody is a Google. But there are concepts and there are mechanisms that Google has used and AWS and Facebook and the others have used, that are very, very relevant to large enterprises, to large service providers, and that is the opportunity. You asked me earlier, why I came and joined Cisco, and you're right, Cisco is the big behemoth in the networking space. And there is a little bit of disconnect in how the hyper-scalers have approached networking in the past couple of years, or few years. And how Cisco's customers and Cisco's global market has been approaching their customers over the past couple of decades. So trying to bridge that gap is what's exciting. And I think there are a lot of concepts that have been developed in the hyper-scalers space that do apply. For example, like you said, SDN is a big one. It simplifies how you do networking. Automation is the other big one. So we see, I've seen in the eight months I've been here, most of our customers looking for an automation platform to build at the same agility and on the same zero-offs mentality that the Googles and AWSs have done. So bringing those concepts within Cisco and giving it to our customers is where the opportunity is. >> If I go back in time, 15 years or so, and I want to start a 50-person company, there's no way I'm going to be able to effectively do that without at least one network engineer on the staff, or almost any reasonable company. Today if something starts up that's cloud-native, a lot of that starts to instead be pushed onto the networks of sort that you used to build at Google, or folks doing the similar things at AWS. Do you see that as a longer-term trend where enterprises are going to start moving in that type of direction as well? Or do you see that enterprises are always going to have specific needs that are not going to be met by the hyper-scale public clouds? >> Yeah, I think that it's probably the latter. What I see in the future is, especially, the way I look at the market, it's data driven in a different way. So wherever you have data, you have the need for compute, you have a need for the network. It comes in a variety of ways. One is just around regulations, so if you have data you need to protect, you need on-prem computes towards networking. If you need a lot of insight from your data, you need to do a lot of number crunching or data crunching. ML, AI, for all of those workloads, you need local compute, you need local network. So, depending upon where the data is, you will see computer networking follow. So in that sense, yes, there will be the need for cloud-based access for all of our enterprises, cloud based applications. But the need for on-prem will never disappear. And that's why I think making the bet on multi-cloud, making the bet on hybrid, is a critical way forward. >> All right, so, Vijoy, one of the things we see at this show, especially, is that intersection between what's happening in the enterprise and what's happening in the developer community. We've watched closely the DevNet group inside of Cisco, and that rise of, it's not just in the DevNet group but Cisco going through a lot of transformation. Heard one of the keynotes in this building a year ago, is when you think of Cisco in like 2030, it shouldn't be Cisco, the networking company, it's Cisco's a software company. And there's the platitudes out there about softwares eating the world alive, but help us give it a little insight as to what that means. Networking of course is Cisco's DNA and how most of us today still think of Cisco, but what's that journey that Cisco is going through? >> Sure. And you touched upon a couple of points there, so let me just walk through a couple of them. First of all, the reference to DevNet, it's pretty evident that everything is moving towards a developer mindset. And the network is no different. So talking about the automation bits that I mentioned earlier even at Cisco the products have been built around even physical boxes, which is the bread and butter for a large majority of out customers. We are trying to move that towards a more developer-friendly paradigm. And instead of going through SNMP or CLI, we are moving towards a very programmatic API, model-driven networks, streaming telemetry. And to do all of those things, you need a developer-centric mindset. So whereas our products are enabling APIs to do those things, there is a need for a community to ingest that API set, and that's were DevNet comes in. So just to be able to train the people who are operating the networks or building on top of out networks, you need a community that is familiar with programmability and development and the software engine principles that go with it. So that's one aspect of the statement that you mentioned earlier and that's one place where Cisco is going. Just with the switches and routers. Another aspect is in 2030 where do you see Cisco evolving towards? And like everybody else we are also going through a transformation. We are becoming cloud-native internally. So it's not just that our products are becoming cloud-native in there nature, it's also what we offer is becoming cloud-native. So the products, the way they are constructed, the way the apps are being developed are becoming cloud-native. We want to be SaaS enabled, so the company is going through a transformation of enabling SaaS on a lot of our products. So transforming Cisco to enable that business model, is also something that you see happen over the course of the next few years. And so we are internally going through how do we build these things out of microservices? How do we scale out? How do we share common code? How do we share common services? How do we stand up a platform just like the Googles and the AWSs have done? And so that's a big push inside of Cisco, as well. >> What does that look like as you go through your own transformation and how does that inform how you meet your customers? >> I didn't catch the last part. >> How does that inform how you meet your customers? As you start to gain empathy for what they're going through too, by going through it yourself. >> That's right, I think, that's exactly right. If you look at what Cisco's trying to do, it's no different than our entire customer set. You can see a whole bunch of things happening, whether whether their companies are being acquired. So lets say, Duo is a great example that we just acquired in the security space. AB Dynamics is a great example. So there's a whole bunch of companies that you acquire that are already SaaS based that are already microservices based. Then there are products that we have had internally that are going through a transformation themselves. Our IT department is going through a transformation. The way we are consuming our own products, talking about DevNet, we are actually consuming them in a very programtic way. So we are no different than all of our customers out there, most of our customers out there, if you skip the top four or five hyper-scalers that we just talked about. So how we approach this problem resinates really, really well with our customer set. And so coming up with use cases and saying that this is how we've solved the problem, these are the products that we built and we consume ourselves so we dog food our own products. For example, the Kubernetes tag that we've had, CCP, we consume it internally. We run it as SaaS product internally. Actually there are a lot of other BUs within Cisco, that consume it as part of their own product offering. So enabling that gives us a lot of credibility when we go and talk to our customers, that this is how we've gone through the journey. And in fact, we want to talk a lot more about that journey in the coming few quarters, because that'll give us the credibility in the marketplace, as well. >> All right, so Vijoy, one of the hottest topics at this show, and has been for a while, is security. And we know there is a tight connection between security and a lot of time with networking there. On the keynote this morning, you talked a little bit about Network Service Match, which is now a sandbox project under the CNCF, explain a little bit how that's helping to attack some of these key issues. >> Sure. I think the NSM is just the first step. So the Network Service Match is basically doing a couple of things. One is it is simplifying networking, so that the consumption paradigm is similar to what you see on the developer L7 layer. So if you think Istio, and how Istio is changing the game in terms of how you consume Layer 7 services, think of bringing that down to the layer to layer three layer, as well. So the way a developer would discover services at the L7 layer is the same way, we would want developers to discover networking endpoints, or networking services, or security capabilities. That's number one. So the language in which you consume needs to be simplified, whereby it becomes simple for developer to consume. The second thing that I touched upon is we don't want developers to think about switches, routers, subnets, BCP, VXLAN, VLAN. >> And they don't! >> They don't, exactly. And so how do you get hybrid and multi-cloud connectivity when you leave a Kubernetes port. Within a port it is very nice and well constructed, and you don't think about those concepts. The moment you leave the port, all of those things come in. And IPs change, subnets change, routing comes into the picture, peering endpoints come into the picture. You don't want developers to think about it and they don't want to think about it, so NSM tries to hide all of that below a shim layer and gives you a simple discovery mechanism, from point A to point B regardless of how far you're going. So that's how the other abstraction that we are bringing in. The third bit, going back to your security question, today if I look at how VNFs are constructed, these are basically cardboard boxes, like I said. They are basically you took the sheet metal, that you are building, you wrap it up in a VM and you call it a virtualized network function. You could follow the same paradigm, wrap up everything, put it in a container, and call it a container network function. We don't want that to happen. So we want to end up in a world where you want specific targeted capabilities. So if a certain application all it needs is an IPSec Tunnel and nothing else, you should be able to provide just that capability, and just basic connectivity for that application. If another application needs a lot more than that, maybe it needs a WAF, maybe it needs something more beyond that, you should be able to provide those capabilities without bringing in the other things. So just dissecting the capabilities of the networking and security space and offering them as individual capabilities which are specific to the application is where we want to be. And that's the world we want to enable. >> Perfect, my last question for you is, when I started off my career as a grumpy Unix administrator, because there's no other kind of Unix administrator that isn't grumpy, I had to learn networking in order to be halfway effective at my job. Today I think you can do the same sort of operational role without having much awareness of networks, because very often that's handled for you, they're a lot more reliable these days, in most cases, too. So you have people who are hitting senior or architect-level roles that have never really touched networking at all. It's always been working behind the scenes until it doesn't. At which point there's not awareness there among those types of people. Those developers are viewing that as part of the plumbing, it always just works. You don't question whether the water's going to come out we turn the tap on, same issue with networking. Do you find that the lack of being first and foremost in people's mind, which is incidentally is a assessment to your success, that that is going to start working against you in some ways as some people stop thinking about networking as a primary thing they need to solve for? >> So, it's and interesting point, and I think if you think about, again, my background where I came from. So at Google, we used to have this thing, that since we control the application stack end to end, we could build the infrastructure the way the applications would want them to be built. So for example, you would go to YouTube or an ML application and say, what do you want infrastructure to be? And in a utopian world they would tell you, build me this. To your point what they told us, even within Google, is, give me infinite capacity at zero latency, at zero cost and then go away. That's what developers want. They don't want to think about it, till it breaks. >> Yes. >> And so number one, building something that will give you infinite capacity at zero latency, high availability and as little cost as possible, I think there is a role for networking for a long, long, long time to come. Number one, because there are architects and products to enable that. Number two, observability. Figuring out how to bump up availability as you go on, getting into zero ops and automation, getting into AI and making sure that these things operate and run on their own, and there is very little burden on the network engineer or operator. These are all problems that a company like Cisco can bring, or solve, in this world. And so you will see Cisco just move up the stack. So it's not that these things will disappear. But, yes, there will be parts that will be plumbing, but there will be parts that Cisco will move up the stack. Getting the observability, getting SLAs in the network figured out, I think there's where, those are the places were Cisco will add value. >> All right, so Vijoy, I'll ask you to close with how you opened your keynote. Help explain network Please Evolve. >> So this, actually yes, so I think wrapping up in terms of everything that I've just said, a few things that networking needs to do is move forward into the cloud-native world, where you are building things in the same way that applications are being built today. And so the consumption model, the architecture of the application in terms of microservices, the way you would operate these networks in terms of building very specific SRE teams, those are the ways the network should be built, as well. The other thing, which is near and dear to my heart, is the need to build in a zero ops matter. You cannot have network engineers and operators muck around with the network anymore. Because they're becoming bigger, larger, and more complicated than ever before. So we need to move towards a zero ops model, and that's were I think evolution of the network should be. >> Well, Vijoy, congratulations on the progress so far, and thank you so much for joining us. >> hank you, and it was very nice to be here. >> All right, for Corey Quinn, I'm Stu Miniman. Back with more of two days of wall-to-wall coverage here at KubeCon CloudNativeCon 2019 Barcelona, Spain. Thank you for watching theCUBE. (upbeat music)