>> Announcer: Live from San Francisco, it's theCUBE,
covering Red Hat SUMMIT 2018,
brought to you by Red Hat.
>> Okay welcome back everyone.
We are here live in San Francisco at Moscone West.
This is theCube's exclusive coverage of Red Hat SUMMIT 2018.
I'm John Furrier, co-host of theCube.
This week John Troyer, guest analyst,
he's the co-founder of TechReckoning,
an advisory and consulting firm around community.
Our next guest Matt Hicks,
Senior Vice President of Engineering at Red Hat.
He's going to give us all the features,
and specs of the road map, and all the priorities.
Thanks for coming on.
>> Hey, thanks guys.
>> John: He's like, "I'm not."
>> So thanks for comin' on,
obviously a successful show for you guys, congratulations.
>> Matt: Thank you
Paul Cormier was on earlier talking about
some of the bets you guys made
and it's all open source,
so those bets are all part of the community,
with the community.
But certainly there's a big shift happening,
we're seeing it now with containers,
and Kubernetes really showing the way,
giving customers clear line of sight
of where things are startin' to fall in the stack.
Obviously you got infrastructure and application development
all under a DevOps kind of concept, so congratulations.
>> Thank you, thank you, it's been fun, it's been,
I think Paul shared this a couple weeks,
we started OpenShift in 2011,
so it's pretty cool to be here now, 2018,
and just see how far that's come
in terms of how many customers using it,
how successful they've been with it.
So that's, it's been great.
>> Yeah we always like to talk on theCube,
we love talkin' to product people and engineers
because we always say the cloud is like an operating system.
It's just all over the place,
decentralized network, distributing computing,
these are concepts that have been around.
A lot of the Red Hat DNA comes from systems,
you have SELinux operating system,
that you offer for free but also have services around it.
It's a systems problem
as we look at the cloud, cloud economics.
So when you go look
at some of the product and engineering priorities,
how do you guys keep that goin'?
What are some of the guiding principles
that you guys have with your team?
Obviously open-source, being in up-stream projects,
but as you guys have to build this out in realtime,
what are some of the principles that you guys have?
>> That's a great,
that's a great question.
I'll try to cover it on two areas.
I think the first for us is workload compatibility,
where you get down into the,
building that new apps is great, it's fun,
a lot of people can do it, and that's an exciting area.
The customers also, they have to deal
with apps they built over 10 plus years,
and so in everything we design,
we try to make sure we can address both of those use cases.
I think that's one of the reasons,
yeah we talk about OpenShift
and how coupled it is to RHEL and Linux.
It's for that you can take anything that runs on RHEL,
run it in a container on OpenShift, stateful, not stateful.
That's one really key design principle.
The other one,
and this we've actually experienced ourselves,
of the roles and responsibilities separation.
We run an OpenShift host environment publicly,
I joke, like anyone that gives me an email address,
I'll run their code and my operations team
doesn't have to know what's inside of the containers.
They have a really clear boundary which is
make the infrastructure infinitely available for them,
and know that you can run anything on that environment.
So that separation,
you know when customers talk about DevOps,
and getting to agile, I think that's almost as critical
as the technology itself,
is letting them be able to do that.
>> Yeah, that's been a real theme here at the show,
I've certainly noticed.
Sure there were technology demos up on stage,
but also a lot of talk about culture,
about process or anti-planning maybe,
or you know helping people.
The role of Red Hat with OpenShift
and the full stack all the way down is bigger now
than it was, just when it was just Linux.
So I mean, is it you and your team,
I mean your in engineering
as you work with the open source communities,
surely it seems like you're having to deal
with a much broader scope of responsibilities.
>> Yeah, that's true.
I started in Red Hat when it was just Linux
and part of it is, you know Linux is big, and it's complex,
and that in and of itself is a pretty broad community.
But these days it is,
we get to work with customers that are transforming
their business and that touches everything
from how they're organizationally structured,
how we make teams work together,
how I make the developers happy
with their rate of innovation
and the security team still comfortable
with what they're changing.
I love it, like it is,
you know and we open source at our core,
so I fell like, I'm an open source guy.
I always have been.
You're seeing open source drive a much wider scope of change
then I ever have before.
>> Let's talk about functionality product-wise,
'cause again we interviewed Jim Whitehurst yesterday
and we had Denise Dumas on as well, on the RHEL side,
and we talked about security.
These things going on, and with OpenShift,
and with Kubernetes, and containers,
it makes your job harder.
You got to do more right?
So talk about what does that mean for you guys
and how does that translate to the customer impact
because it's more complicated.
There's abstraction layers
that are abstracting away the complexity.
The complexity is not going away,
it's just being abstracted away.
This is harder on engineering.
How are you handling that and what's your approach?
>> So I've looked at it as a great opportunity for us.
I've been working with Linux for a long time
and I was a big fan when we introduced SELinux,
and for a long time moving from traditional Linux hosting
to operations teams wanting to turn on SELinux,
it's been a really tough climb.
It's, it'll break things,
and they're not comfortable with it.
They know they need that layer of security,
but turning it on has been a challenge.
Then go to cgroups, or different namespaces,
and they're not going to get there.
With OpenShift, the vast majority of OpenShift deployments,
under the covers we run with SELinux on by default,
customize policies, everything's in control groups,
containers uses Linux namespaces.
So you get a level of workload isolation
that it was unimaginable you know five, 10 years ago,
and I love that aspect,
'cause you start with one aspect of security,
you get much, much stronger.
So it's our ability to,
you know we know all the levers and knobs in Linux itself,
and we get to turn 'em all and pull 'em all so,
>> I want to put you on the spot, I want to,
and it's not an insult to you guys at all.
But we've heard some hallway conversations.
You know just in a joking way 'cause everyone loves Linux,
open source, we all love that.
But they say, nothings perfect either.
No software actually runs all the time great.
So one customer said, I won't say the name,
"When OpenShift fails, it fails big."
Meaning there's, it's very reliable
but it's taking on a lot of heaving lifting.
There's a lot of things going on in there, 'cause that's,
'cause it's Linux, when it breaks, it breaks a lot,
and I know you're tryin' to avoid that.
But my point is,
is that just as these are important components.
How do you make that completely bullet proof?
How do you guys stay on top of it
so that thinks don't break?
I'm not saying they do all the time.
I'm just saying it's common.
It was more an order of magnitude kind of thing.
>> Yeah, yeah, no,
well I think it's a coupla things.
So we invested in OpenShift Online and OpenShift Dedicated
and those were new for Red Hat,
and for running hosting environments,
so we could learn a lot of the nuances of how do you,
OpenShift Online is roughly a single environment,
how do we make that never break as a whole.
A user might do something in their app
and make their app break.
How do we not make the whole break?
The second challenge I think we've hit is just skills
in the market of it's not necessarily an easy system
there are lots of moving pieces there.
The deal with Azure and the partnership there,
having managed service offerings
I think is really going to help users get into,
I have a highly available environment,
I don't have to worry about SED replication
or those components but I can still get the benefits.
And then I think over time as people learn the technology,
they know how to utilize it well, we'll see,
we'll see less and less of the it catastrophically failed
because I didn't know that I could make it highly available.
Those are always painful to me, where it's you know,
>> John: That's education. >> Yeah
>> So Matt, there's a clear conversation here.
Very clarity of roles and responsibilities
even in the stack.
I think even as recently as a year or two ago,
people were having conversations
about the role of OpenStack, versus Kubernetes,
and you were getting kind of weird,
like what's on top of what?
And even in terms of, you know other parts of the stack,
I mean here it's clear, very clear,
you know OpenStack is about infrastructure,
OpenShift you know on top of it,
and even in terms of virtualization, containers versus VMs.
The conversation this year seems more clear.
As an engineer, you know and an engineering leader,
were the, did the engineering teams rolling their eyes
going well we knew how this was going to work out all along,
or did you all also kind of come along on that journey
the last couple years?
>> I think seeing the customer use cases refined a little bit
while education builds those has been great.
We always, like we're engineers,
we like clear separation and what each products good at,
so for us it's fantastic.
You know OpenStack is great at managing metal.
One of my favorite demonstrations
was using OpenStack Director to on a,
you know boot machines, put OSs on 'em,
and leave OpenShift running,
and be able to share network
and storage clients with OpenStack.
Those things are, you know they're great for me
as an engineering lead because we're doing that once
as well as we can, but it's nice in engineering
if you get to optimize each side of the stack.
So I think I have seen the customers understanding,
as they've done more with OpenStack,
and they've done more with OpenShift,
they know which product they want to use, what for.
That has helped us accelerate
the engineering work towards it.
>> You mention skills, skills gaps, and skills in general.
How is the hiring going?
Is there a new kind of DevOps rockstar out there?
Is there a new kind of profile?
Is there pieces of the stack
that you want certain skills for?
Is there generalism?
Are the roles in engineering changing?
If you could just add some color
to that conversation around,
you know cause we're talkin' about engineering now.
It used to be called software engineering when I graduated,
and then you became a developer.
I don't know which ones better,
but you know to me this is real engineering going on,
which is using software development techniques.
So what's the skills situation?
>> For us I think,
it is nice that you're seeing a lot of gravitation to Linux
at the host level, and Kubernetes has helped,
just at the distributed system level,
so obviously skills there play pretty well in general.
I would say what we have seen is there has been
a stronger increase in having operational skills
as well as development skills, and it's a spectrum.
You're still going to have operational experts
and algorithmic experts, but the blended role
where you do know what it takes to run an application
in production to some extent,
or you do know something
about infrastructure and development.
I certainly look for that on our teams because that's,
where customers I've seen struggle for years and years
is in the handoff in the shift between,
everyone can write functional apps,
they usually struggle getting them into production.
And it's really neither teams fault,
it's in that translation
and these platforms help bridge that.
People that have some skills on either side
have become incredibly valuable in that.
>> John: So that's were the DevOps action
is right, the overlay.
>> It really is yeah.
>> So thinking about network
as the networking growth with DevOps.
DevOps has always been infrastructure as code.
And it all comes to, there's to many, many,
I don't want to talk about it.
It's always the network that gets beat on the most,
I need better latency.
And so networking software to find networking
is not a new concept,
self-defined data centers are out there.
What's new in networking that you could point to
that's part of this new wave?
>> Two geeky things that might not have been noticed.
One is the work we've done on Ansible networking
has been stunningly popular to me,
and that was just this simplicity
of Ansible just needs us
to sage in a minimal set of dependencies.
Most switches out there can actually,
they have SSH running, and having automation of switches
in the actual gear itself was surprisingly not unified.
And Ansible was able to fit that niche
where you could remotely configure switches
and that has grown and exploded.
Because if you think of the,
I'm going to do a DevOps workflow
but now I need to actually change routing
or bleed something, you're often talking to switches,
and being able to couple that in has been,
it has been fun to watch, so I've loved that aspect.
The other portion when we combine OpenShift on OpenStack
the courier work which we've talked about some, is,
you know OpenShift often described
as it consumes infrastructure that OpenStack provides,
and the one exception was usually the networking tier.
It was like we have to run an overlay network on it.
When we run OpenShift on OpenStack
it can actually utilize OpenStack's networking
to be able to try that instead of doing it's own overlay.
That is critical at the larger scale.
>> John: So the policy comes in handy there is that,
or configurations, where's the benefit?
>> Both on network topology, which do you have two teams
that are building different structures
that may collide in the night.
So it gets it from two teams down to one,
and then the second is just the knock controls
in isolation, it's done once.
It's been nice for me on the engineering side
where we'd put a ton of effort in the OpenStack community,
we put a ton of effort
in Kubernetes and the OpenShift communities,
and we're able to pretty nicely combine those.
We know 'em both really well.
>> So take us through some inside baseball at Red Hat.
What's going on internally within' your group.
I want to probe on developer
and software engineers productivity.
If the quote DevOps works,
the test is the freeing up their time
from doing mundane tasks, and you got cool things
like you said about the network things, pretty positive.
This is going to free up
some intellectual capital from engineering.
So okay if that's true, I'm assuming it's true,
if it's not then say it's not true,
but it sounds like it's probably going to be true for you.
What are your guys working on, what's next?
So can you share some of what,
'cause you guys are doing your own thing,
you're using your own software.
Is that intellectual capital
being freed up on the developers side?
Are they doing some more programming?
Are you seeing some more creativity?
What are they doing with that free time,
free time, extra intellectual cycles?
>> All our excesses, I'll tell Paul that.
He was up before me.
Like, Ops team barely has to work anymore.
>> There in there clipping coupons
at the beach you know.
It's all running, we're busy.
>> So a good creative example,
and this was I think the second demo we showed.
Red Hat Insights has been in the market for a while
and that was our,
can we glean enough information from systems
to get ahead of a support issue,
and this year we showed the,
it's not just known fixes,
you know we match it to a knowledgebase article.
But can we interpret fixes from peer analysis
and you know machine learning type techniques?
That's a classic example
where we use the creativity and free time,
and say you know what that stack internally runs
on OpenShift, running on OpenStack,
using Red Hat storage, and we're applying some of,
you know TensorFlow and other capabilities to do that.
That was probably my favorite example at SUMMIT
where if we weren't getting more efficient
at what we worked on,
we wouldn't of been able to stand up that stack ourselves,
much less execute to it, and show it live in SUMMIT,
doing the analysis across a hybrid cloud.
>> But this is the whole point of DevOps.
This the whole purpose, being highly productive,
to use those intellectual cycle times
to build stuff, solve problems.
>> Yeah absolutely.
>> Not provision servers or networks.
Awesome, well thanks for coming on theCUBE,
really appreciate it. >> Matt: Thank you guys.
>> What's the priorities for you guys this year?
What's the focus?
Share your plans for the year.
>> You know I think it's similar
to the last thing we showed today.
We really want to make customers
feel like they can deploy hybrid cloud.
Whether it's compute, applications,
they have the services they need, down to storage, it works.
They're on premise.
They know we're going to have the best combination we can.
This year is a stay ahead of people on that path,
make sure their successful with it.
>> We'll see you guys at OpenStack SUMMIT, Vancouver.
Thanks for comin' on, Matt Hicks,
Senior Vice-President of Engineering at Red Hat.
I'm John Furrier, John Troyer,
Stay with us, we're day three of three days of live coverage
here in San Francisco, Red Hat SUMMIT 2018.
Stay with us, we'll be right back after this short break.
(digital music)