 Live from Barcelona, Spain, it's theCUBE, covering KubeCon CloudNativeCon Europe 2019. brought to you by Red Hat, the CloudNative 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'll be years and soon it'll be forgotten, but I did come from Google, I spent a whole bunch of time there in the networking space. I actually ran the data center footprint, I also ran the VAN footprint for a couple of years and then I ended up building the automation, modeling, telemetry, data analytics 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 a networking guy by background and if you talk about just the Google network and 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 let's 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 notes the thing or two about networking. Can you tell some of those, it just helped connect the dots for me. We've had this premise that the hyper and web scale, what they have done is what's bleeding into the enterprise. That's what Kubernetes is, what Google did at board and from a networking standpoint, some of the things that the top 20 hyperscale companies were doing, we're now starting to see into the enterprise. Does that premise hold water for you? Yeah, that's correct. But I think what you need to realize is that not everybody is a hyperscaler, 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. I mean if you asked me earlier why I came and joined Cisco and you're right, I mean Cisco is the big behemoth in the networking space and there is a little bit of a disconnect in how the hyperscalers have approached networking in the past couple of years or few years and how Cisco's customers and Cisco's go-to-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 hyperscaler 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 with the same zero-offs mentality that the Googles and the AWS have done. So bringing those concepts within Cisco and giving it to our customers is where the opportunity is. Yeah, if I go back in time, 15 years or so, and I want to start about 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 that you use 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 it's probably the latter. I mean, 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 the need for the network. And it comes in a variety of ways. One is just around regulations. So if you have data that you need to protect, you need on-prem compute storage 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, I mean, for all of those workloads, you need local compute, you need local networks. So depending on where the data is, you will see compute and 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 the critical way forward. So, VJoy, 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. I 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 software is eating the world and like, 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's 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 the developer's mindset and the network is no different. So, talking about the automation bits that I mentioned earlier, even at Cisco, the products that we build around even physical boxes, which is the bread and butter for a large majority of our 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 where DevNet comes in. So, just to be able to train the people who are operating the networks, who are building on top of our 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 their 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 their 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 AWS 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? How does that inform how you meet your customers? I didn't catch the last part of it. And 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 mean, I think so, that's exactly right. So, if you look at what Cisco is trying to do, it's no different than our entire customer set. You can see a whole bunch of things happening, whether they are being, whether they are companies that are being acquired. So, let's say Duo is a great example that we just acquired in the security space. AppDynamics 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 our transformation. The way we are consuming our own products, talking about DevNet, we are actually consuming them in a very programmatic 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 hyperscalers that we just talked about. So, how we approach this problem resonates 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 build and we consume ourselves. So, we dog food our own products. For example, the Kubernetes stack that we've had, CCP, we consume it internally. We run it as a SaaS product internally. We, actually there are a lot of other be used 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, VJoy, one of the hottest topics at this show, you know, it has been for a while, is security. And we know there is a, you know, tight connection between security and a lot of times with networking there. The keynote this morning, you talked a little bit about network service mesh, which is now a sandbox project under the CNCF. Explain a little bit about how that's, you know, helping to, you know, attack some of these key issues. Sure, I think the NSM is just a first step. So, the network service mesh is basically doing a couple of things. One is it is simplifying networking so that the consumption paradigm is similar to what you've seen on the developer L7 layer. So, if you think of Istio and how Istio 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 a developer to consume. The second thing that I touched upon is we don't want developers to think about switches, routers, subnets, BGP, VXLAN, VLAN. And they don't. They don't, exactly. And so, how do you get hybrid and multi-cloud connectivity where you leave a Kubernetes pod? Within a pod it's very nice and well-constructed and you don't think about those concepts. The moment you leave the pod, 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 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 were building, you wrapped it up in a VM and you called 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 other things. So, just dissecting the capabilities in the networking and security space and offering them as individual capabilities which are specific to the application is where we want to be. That's a world we want to enable. Perfect, I guess 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 no 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 is going to come out, we turn the tap on. Same issue with networking. Do you find that, I guess the lack of being first and foremost in people's mind, which incidentally is an assessment to your success, that that is going to start working against you in some ways as people stop thinking about networking as a primary thing they need to solve for? So, it's an 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 a YouTube or an ML application and say, what do you want the 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, right? I mean, 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 architectures and products that enable that. Number two, observability, figuring out how to bump up availability as we 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 of it that will be plumbing, but there will be parts of it where Cisco will move up the stack. And getting the observability, getting SLAs in the network figured out, I think there's where, those are the places where Cisco will add value. All right, so, Vijay, I'll ask you to close with how you opened your keynote and 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, A, 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 they need to be built in a zero ops manner. 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 where I think the evolution of the network should be. Well, Bijoy, congratulations on the progress so far and thank you so much for joining us. Thank you, it was very nice to be here. All right, for Corey Quinn, I'm Stu Miniman. Back with more of our two days of wall-to-wall coverage here at KubeCon CloudNativeCon 2019, Barcelona, Spain. Thank you for watching theCUBE.