(busy music) >> Announcer: Live from the Computer History Museum in Mountain View, California, it's the Cube, covering DevNet Create 2018. Brought to you by Cisco. (busy music) >> Hello and welcome back to the Cube's live coverage here in Silicon Valley at the Computer History Museum in Mountain View California for Cisco's DevNet Create 2018. I'm John Furrier with my co-host, Lauren Cooney. This week, our next guest is Paul Giblin, Senior Solutions Architect, Presidio. Welcome to the Cube. >> Thank you, thank you for having me. >> Cisco, Champion, Spark Master, you've written pretty much everything under the sun for Cisco? >> Paul: CCIE, yeah. >> Yeah. We've been following this story a long time, obviously, DevNet, really successful, almost a half a million developers in that community and growing. DevNet Create, kind of putting a forward flank on cloud kind of bringing that migration path, the connection between the developer programs, really, and the communities. >> Paul: Sure. >> They don't have a translation, I mean, what's your take on it as you look at it, I mean, some very relevant things, the programmable network is cool. What's your reaction to the direction, your thoughts, input? >> I think it's a fantastic program. I've mentioned it in several other interviews I've done over time. It's a great program, because it's about enablement. It's helping people get from where they used to be as CLI junkies and where we've been for the last 25 years, and moving them into a new space where they can now do much more with the network, and continue to remain relevant as well. >> What are some of the things that you see? Because we, I have a lot of friends who work at Cisco, worked there, back in the '90s, been the crew, and obviously, they ran the networks, it is well documented the historic nature of Cisco. But the debate internally has always been moving up the stack. At what point, Cisco is very cool about knowing their place in the stack, doing kickass things. But then as the market changes, now you have that stack change, certainly with DevOps, you now have abstraction layer, you've got Kubernetes. Now you have, now, the ability to take all the network stuff that was really enabling the apps to co-exist with apps sharing data, getting programmability. Where's the use cases? Where is the low hanging fruit for folks that are looking to put their toe in the water, and/or becoming more modern in that, in more of a fabric way, or however it's called, or what's your view on the use cases? >> They're still fuzzy, I'm still trying to figure that out myself. I've run into a lot, and most of them seem to be automation use cases, at least so far. My brain is wired to think from the perspective of the infrastructure engineer, and less so the developer. But as I continue to attend DevNet events and immerse myself in the community, I'm finding I'm starting to look at things through a new lens, and I think that's one of the big values of coming here. >> I think, too, when you take a look at coming from the application layer, where I come from, actually, and also from the infrastructure layer, you have these application developers that actually don't know the power of what they can get from the network. By offering up APIs, they can start to pull this data into their applications to make them run better, to have better uptime, to add more features, more data, whatever they may need from that network, if they have ability to understand the network to a certain perspective. >> I think one of the challenges you have there is very much like infrastructure folks, or traditional infrastructure folks don't really understand a lot of what's going on with the application. You have the converse as well, so a lot of folks who are working in the application space don't understand the infrastructure. Even though Cisco's exposing a lot of really cool functionality and capability, they might not necessarily understand how to leverage it, and I think that's where the value really exists in the market today, is for the people who can come from the infrastructure side and take on a little bit of the application and people who are on the application side who can really say they're going full stack including the infrastructure, right. >> On the network side, one of the things that have always been important is provisioning, configuration management, these are the tenets of a nice solid network. But now, when you talk about the DevOps, one of the things is, oh, yeah, just pull provision, they have some of there. Like, they want dynamic, right. Policy base has been around for a while, QoS, these are concepts. How do you view that? Because now this is an opportunity to bring a known network construct to apps. Now with decentralization in apps, network effect is a huge dynamic, you're seeing the notion of network effects, how people share, how apps are integrating. I mean, Facebook's trying to explain to the senators yesterday and then today how Facebook works. App services now are taking on a much more different look. But they're network apps, basically. This is really kind of coming to the forefront. I mean, how does a network guy get trained up on that? I mean, is there common threads that you see where people, as they learn more, where they can connect in? Do you have any thoughts on that? >> I wouldn't even know where to begin. When I look at this stuff, I think about how do I make the network so that it's available and rock solid and able to support whatever application may ride on top of it. I think the change, as you had mentioned, is really, now, how do I allow people who aren't necessarily going to be moving cables and getting deep with the network, interact with it in a safe, controlled way where they're not necessarily going to break anything, but they are able to affect some kind of change that helps their app run on the infrastructure it's sitting on top of. >> On the Spark side, you mentioned you're a Spark master. >> Paul: Sure. >> That's a collaboration app uses video and all kinds of stuff. How is that workload treated in the network? Is it much more locked down, is it more? I mean, because that's a dynamic app. How is that integrating on the Cisco on Cisco environment? >> I think that traditional roles for QoS still apply. I don't think trying to dynamically change QoS has ever been a good idea. I think it's a really dynamic thing, and it's very difficult to pin down because at any given point in time, I could be communicating with the cloud, I could be communicating with five other end points over here, I could be hitting an MCU, a data center somewhere, a video bridge that sits locally, kind of across the room. There's a lot of different ways to communicate. What makes that scary and difficult and hard to code for is, they're all different and it's not standardized. I think we're just getting to a place now where that may be a reality, but we're not there yet. >> Yeah, I mean, you bring up a good point. One of the things that jumps in my head immediately is like all this multicloud talk is a nightmare, because you think about just latency alone on interconnect between clouds. Even though they publish direct connections, I mean, you live in a world of latency. Like, it's so unknown, so I mean, there's a lot of real unknowns that are coming to the table that architects really got to figure out. I find that fascinating. Have you had a chance to play with the wireless stuff that's on the Cisco side? >> Paul: Sure. >> In terms of how that's planning out? How is that going, because that's an IoT enabler? >> Yeah, so there's all kinds of use cases around wireless. Location is a huge one. I think there was a gentleman who was presenting yesterday with a mapping application that shows how to get from point A to point B. I think there's been a couple of organizations have implemented that at a very large scale who had a lot of resources to put behind it. But I think your average consumer company or enterprise company is not really equipped to build things like that. I think Meraki is starting to try and make that easy. Stuff like that's really exciting. >> Yeah, I mean, I think it's got a lot of prospects. What are you working on now? What are the cool projects you're working on now? What are you digging your teeth into from a project standpoint? >> I've been working on an app for several months with a couple of co-workers of mine to start to automate switch migrations. In the infrastructure world, you're going to have switch refreshes every so often, and it's a difficult and manual process. We're working on a set of tools to automate that to get people who are really intelligent folks working on more creative things so that they're not doing rote labor nearly as much. I've been kind of building toolkits to help with automation of business processes that we go through at Presidio. >> Automation, dev, just automating the manual tasks, you mean, or is it more? >> Well, the manual tasks still need to happen, so your engineers still need to move cables from A to B. >> John: Yeah, obviously. >> But we're automating what happens logistically in terms of what you need to do to prepare for that migration, how that process is instrumented during actual execution. Then how it looks in terms of accountability and auditability after the job has been completed. >> That's a good point. In fact, let's bring that up, because we debate this all the time in the Cube in conversations, because someone, oh, you do something three times, you should be automating it. Not necessarily, the real human component, obviously, cable, you've got to move cable here, they don't just magically move, you can't automate that. But, and there's physics on the wireless side, too, you can't really change those things. But what is an ideal things to automate? You mention things that make sense. Hey, I'm doing this prep work and automate that. What are some of the things that you advise people to look to when they think about automation? What's the areas that kind of filter past you? >> I think the things that are ripe targets for automation are the things you don't like to do. If you can find something that somebody else is doing and doesn't want to do, automate that, and you've got a built in customer right there. >> Yeah, yeah, big ear. All right, cool, well, what do you think of the show here? Thoughts? >> I think the show's fantastic. I didn't get to attend last year and I really wish that I had, but this is my first one, and my experience here has been fantastic. >> John: Any sessions you like the best? Things you jumped on? >> I like the sessions I deliver the best. >> Well, thanks so much for coming on the Cube. >> Thank you. >> Excellent work, great job. >> Thank you much. >> The Cube, bringing all the action, Cisco Champions, getting down in the trenches and the practitioners doing all the work, really is the convergence of networks and the cloud and software DevOps coming together, really, with the two worlds coming together, it's certainly relevant, and this is what we're covering here on the Cube. More live coverage here in Mountain View, California after this short break. (busy music)