 Live from San Diego, California, it's theCUBE. Covering KubeCon and CloudNativeCon. Brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome back, this is theCUBE's coverage of KubeCon, CloudNativeCon, here in San Diego. I am Stu Miniman, he is Justin Warren, and our guest for this segment, a CUBE alumni, Vijay Pandey, who's the vice president and CTO of Cloud, inside Cisco, also on the keynote stage this morning. Thanks so much for joining us again. Welcome, and pleasure to be here. All right, so we got to see the sequel on stage. Network, please evolve, part two. There were magnets involved, there were some XKCD key humor in there, which definitely this audience appreciates it. But part two, come on, the networking industry is known for its lightning fast changes. Oh, maybe I'm thinking of this ecosystem, but give our audience a little bit of a taste of, you know, the premise of what you were talking about this morning. Absolutely, I think, so back in Barcelona, I talked about how networking needed to evolve for a CloudNative environment. And the whole idea behind that talk was, we've gone from physical infrastructure, which we call Infra 1.0, to virtual, which is Infra 2.0. 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 agility, you got disaster recovery, you got a few aspects that you would like, but largely things were monolithic, largely, especially on the networking side, things were still being touted as routers or V routers, switches or V switches. You're still using 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 lift and shift, but if you're breaking the application down into microservices, or you're using serverless to build your applications, the app is getting thinner and thinner, and much more distributed. And so there's a complete reimagining of the application, there's a re-architecture, 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. 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 are aggregate statistical networks to solve an application networking problem. So one of the big challenges there is, enterprises 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. We talk about, oh, 20% of apps in the cloud? Well, how many apps have been modernized? It's a smaller piece than that. And we need to have the bridge to the customer in all of the places that they are and are going, and cloud is not a destination, it's an operational model. So how do I span all of the environments, embrace them and still keep everything's moving forward 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, is 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 middleware, you're seeing data processing pipelines, things that are critical to a business. Those are 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 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 these things together? Cloud native is a philosophy. It's a way of operating your infrastructure. It's a way of building in redundancy, a way of 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 NSM and things that we're doing with deterioration and our dynamic and a whole bunch of efforts within Cisco are geared towards uplifting the older gear or older infrastructure and older applications to a cloud native operational paradigm. Yeah, as Stu mentioned, part of that requires changing the way human behavior works, 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, 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 a couple of tiers, so there is a physical infrastructure that sits below everything that is again pervasive across a multi-cloud environment and 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 DevOps 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 where things like an SM come in because the developers don't want to deal with the bells and whistles at the physical or the virtual infrastructure layer. They are defining their CRDs. They are defining their, if I am on microservice, I want to talk to another microservice or a bare metal or a serverless 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 virtual wire, 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. All right, so we just had Sugu on talking about the VITES database and talking about a cloud native database. And the way he really describes it is, you know, it's baked into Kubernetes even though VITES doesn't have to have Kubernetes. And he said he even had customers that it made it possible for them to be able to have that database from one cloud to another without needing to talk to his team. And it's made things possible. Help us understand how the network service mesh fit into solutions like that. Absolutely, and if you think, I mean, I love the VITES project. They've graduated, so congratulations to them. But I think 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, 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 I talked about in my keynote, very simple, VITES or not VITES, doesn't matter. Something that every organization wants to do is take 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 paying that any organization needs to go through today, is 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 color providers, you're talking to cloud providers, especially every cloud provider has their own compliance and configuration paradigms. So all of that being different, that's just a technical complexity. Within one organization, they're like multitude of teams. Dev, DevOps, NetOps, SecOps, they all need to talk to each other. Even within Cisco, we talk to our Cisco IT guys, just DevOps, it's like 20 teams, it's not one team. So just imagine talking to all of those teams, trying to fix this thing and trying to get just database replication, 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 this NSM 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 works across layer seven meshes, across simple layer three problems like this, across service provider use cases, across a whole bunch of use cases. Yeah, and 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 why we have technologies like service mesh is changing the nature of the way we operate it. 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 a tractable problem for the humans to deal with. And I think a lot of organizations are still wrestling with that concept 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. So 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 point. And I think, so prior to this role, I was at Google and I ran their networking infrastructure for a while. And then I ended up writing their automation and telemetry stack for running that infrastructure. And one of the things that we used to say back there was, if your 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 had these very specific connotations around it which 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 operate it in a very declarative fashion. That's what this is. Regardless of whether they're built in a control data separated way or they are traditional BGP networks. So we are pushing IBM in a very big way. And the whole problem statement there is, to your point, humans can't comprehend the complexities that arise. One quick topic where we were sending telemetry data through SNMP. Now we are sending telemetry data which is 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 what it connects to. And that is again, tractable from a human perspective. Yes. Vidroy, 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 thank you so much for joining us. We hope that, by the way, your journey of network please evolve that it comes to a successful conclusion in the near future. Absolutely, and that'll happen. Look forward to chatting with you again soon. For Justin Warren, I am Stu Miniman. Stay tuned, we're going to wrap up day two and we have a whole another day tomorrow of our coverage here from KubeCon, CloudNativeCon 2019 in San Diego. Thank you for watching the queue.