(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)