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