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)