>> 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)

right so with kubernetes the history is we started off with only file systems block is something very new within the past couple releases that actually personally worked on the next piece that we're doing at Red Hat is leading the charge to create CRTs for object storage so it's defining those api's so customers can dynamically provision and manage their object storage with that in addition we recently acquired a company called nuba that does exactly that they're able to have that data mobility through object buckets across many clouds doing the sharding and replication with the ability to do and that's super important because it opens up for our customers to have image streams photos things like that that they typically use within an enterprise and quickly move the data and copy it as they as they need to so we notice that that more and more people want to try their workloads outside of the centralized one centralized data cluster so the big you know term for the last year was the hybrid cloud but it's not just hybrid cloud people coming from also from the iot user space wants to you know containerize their work clothes what wants to put the processing closer and closer to the devices that are actually producing and consuming those data in the users and there is a lot of use cases which should be tackled in in that way and as you all said previously like you Burnett is want developers hearts and minds so api's are stable everybody is using them it will be supported for decades so it's it's natural to try to bring all these tools and and all these platforms that are already you know available to developers try to tackle these new new challenges so that's why last year we reformed the kubernetes at the edge working group trying to you know start with the simple questions because when people come to you and say edge everybody thinks something different from somebody it's in IOT gateway for somebody it's a it's a full-blown you know kubernetes faster it's some telco providers so that's what we're trying to figure out all these and try to form a community because as we saw in the previous cell so for the IOT user space is that complex problems like these are never basically solved by single single company you need open source you need open standards you need the community around it so that people can pick and choose and build a solution to fit their needs yeah yeah so I care a lot about diversity in tech and women in tech more specifically one of the things that I I feel like this community has a lot of very visible women so when I actually looked at the number of contributors by by men and women I was really shocked to find out it was 3 percents it's kind of disappointing it's 3 percent of all the contributors to the all the projects in the CNCs it's only if you look at the 36 projects you look at the number of the people who've made issues commits comments pull requests it's 3 percent women and I think the CSUF has put a lot of effort into the for example of the diversity scholarships so bringing more than 300 people from underrepresented groups to cube corn including 56 here in Barcelona and it has a personal meaning to me because I really got my start through that diversity scholarship to keep calm Berlin two years ago and when I first came to keep on Berlin I knew nobody but just that little first step can go a long way into getting people into feeling like they're part of the community and they have something valuable to give back and then once you're in you're hooked on it and yeah then there's a lot of fun I think the ecosystem may finally be ready for it and this is I feel like it's easy for us to look at examples of the past you know people kind of shake their heads and OpenStack as a cautionary tale or sprawl and you know whatnot but this is a thriving which means growing which means changing which means a very busy ecosystem but like you're pointing out if your enterprises are gonna adopt some of this technology gee they look at it and everyone here was you know eating cupcakes or whatever for the kubernetes 5th birthday to an enterprise just because this got launched in 2014 you know ok June 2014 that sounds kind of new we're still running that mainframe that is still producing business value and actually that's fine I mean I think this maybe is one of the great things about a company like Microsoft is we are our customers like we also respect the fact that if something works you don't just Yolo a new thing out into production to replace it for what reason what is the business value of replacing it and I think for this that's why this kind of UNIX philosophy of the very modular pieces of this ecosystem and we were talking about how them a little earlier but there's also you know draft brigade you know etc like the porter the C NAB spec implementation stuff and this cloud native application bundles which that's a whole mouthful one of the things I like I've been a long history and open source too is if there are things that aren't perfect or things that are maturing a lot of times we're talking about them in public because there is a roadmap and you know people are working on it and we can all go to the repositories and you know see where people are complaining so at a show like this I feel like we do have some level of transparency and we can actually have realism here we I don't think we hear that as much anymore because there is no more barrier to getting the technology it's no longer I get this technology from vendor a and I wish somebody else would support the standard it's like I can get it if I want it I think the competition we typically have aren't about features anymore they're simply my business is driven by software let that's the way I interact with my customer that's the way I collect data for my customers whatever that is I need to do that faster and I need to teach my people to do that stuff so the technology becomes secondary like I have this saying it frustrates people so nice but I'm like there is not a CEO a CIO a CTO that you would talk to that wakes up and says I have a kubernetes problem they all go I have a I have this business problem I have that problem it happens to be software kubernetes is a detail sure I think the NSM is just a first step so the natural service 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 SEO and how SEO is changing the game in terms of how you consume layer seven services think of bringing that down to the layer two 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 whereas it's 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 BGP reacts van VLAN for me I want to take a little bit more into the idea of multi cloud I've been making a bit of a stink for the past year with a talk called the myths of multi cloud where it's not something I generally advise as a best practice and I'm holding to that fairly well but what I want to do is I won't have conversations with people who are pursuing multi-cloud strategies and figure out first are they in fact pursuing that the same thing that we're defining our terms and talking on the same page and secondly I want to get a little more context and insight into why they're doing that and what that looks like for them is it they want to be able to run different workloads in different places great that's fair the same workload run everywhere the lowest common denominator well let's scratch build a surface a bit and find out why that is bob wise and his team spent a ton of time working on the community and the whole the whole team does right for one of the the biggest contributors to @cd we're hosting birds of a feather we've committed we've contributed back to a fair amount of community projects and I think a lot of them are in fact around how to just make kubernetes work better on AWS and that might be something that we built because uks or it might be something like the like cluster autoscaler right which ultimately people would like to work better with with auto-scaling groups I think we we had the community involvement but I think it's about having a quiet community involvement right that it's it's about chopping wood and carrying water and being present and committing and showing up and having experts and answering questions and being present and things like say groups than it is necessarily having the biggest booth so Joe tremendous progress in five years look look forward for us a little bit you know what what what does you know kubernetes you know 2024 look like for us well you know a lot of folks like to say that you know in five years kubernetes is going to disappear and sometimes they come at this from the sort of snarky angle but other times I think you know it's gonna disappear in terms of like it's gonna be so boring so solid so assumed that people don't talk about it anymore I mean we're here at you know something that you know the the CNC F is part of the Linux Foundation which is great but you know how often do people really focus on the Linux kernel these days it is so boring so solid there's new stuff going on but like clearly all the exciting stuff all the action all the innovation is happening at higher layers and I think we're gonna see something similar happen with kubernetes over time exciting is being here if you rewind five years and tell me I'm ready in Barcelona with with 7,500 of my best friends I would think you were crazy or from Mars this is amazing and I thank everybody who's here who's made this thing possible we have a ton of work to do you know if you feel like you can't figure out what you need to work on come talk to me and we'll figure it out yet for me I just want to give a big thank you to all the maintain a nurse folks like Tim but also you know some other folks who you may not know their name but they're the ones slogging it out and to get up PRQ you know trying to just you know make the project's work in function day today and we're it not for their ongoing efforts we wouldn't have any of this you [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)