>> Announcer: Live from Boston, Massachusetts,
it's theCUBE.
Covering Red Hat Summit 2019.
Brought to you by Red Hat.
>> Good to have you back here on theCube
we are live in Boston at the Convention Center here.
Along with Stu Miniman, I'm John Walls
and on theCUBE we're continuing our coverage
of Red Hat Summit 2019 in Boston, as I said.
Joined now by Reza Shafii,
who is the VP of Platform Services at Red Hat.
Former CoreOS guy >> That's right.
>> Stu actually has his CoreOS socks on,
>> He told me.
>> Today, yeah, so he came dressed for the occasion.
>> Shh, can't see those on camera, John.
I can't be wearing vendor here.
>> Don't show it to the camera.
>> Well I just say they're cool!
They're cool.
Glad to have you with us, Reza.
And first off, your impression, you have a big announcement,
right, with OpenShift.
OpenShift 4 being launched officially
on the keynote stage today.
That's some big news, right?
>> It's a big deal, it's a big deal.
The way I think about it is that it's really a culmination
of the efforts that we planned out when we sat down
between the CoreOS leadership team
and the Red Hat leadership team,
when the acquisition was closed.
And we planned this out,
I remember a meeting we had in the white board room.
We planned this out.
In terms of bringing the best
of OpenShift and CoreOS technology together.
And it's really great to see it out there on the keynote,
and actually all demoed and working.
>> And working, right?
Key part.
>> Reza, dig in for us a little bit here,
because it's one thing to say okay, we got a white board
and we put things together.
You know, when I looked at both companies, at first both,
CoreOS before the acquisition and Red Hat, I mean
open source, absolutely as its core.
I remember talking to the CoreOS team, I'm like,
you guys are gonna build a whole bunch of really cool tools,
but what's the business there?
Do you guys think you're gonna be the next Red Hat?
Come on.
Well, now you're part of Red Hat.
So, give us a little bit of the insight as to what it took
to get from there to the announcements, CoreOS infused in
many of the pieces that we heard announced this week.
>> Yeah, so the way I like to think about it is that
Red Hat's OpenShift's roots,
it started with making sure that they create a really nice
comfortable surface area for the deaf teams.
The deaf teams can go in and start pushing the applications
and it just ensures that it's running those applications
in the right way.
The CoreOS roots came from the operations perspective
and the system administrator.
We always looked at the world from the system administrator.
Yes, you're right, CoreOS had a number of technologies
they were working on, etcd, Rocket, clair.
I used to joke that there's a constellation of
open source services that we're working on,
but where is the one product?
And, towards the end, right before the acquisition,
the one product I think was pretty clear is Tectonic,
the Kubernetes software.
Now, if you look at Tectonic,
the key value difference was automated operations.
The core tenants of what Alex Polvi and Brandon Philips said
into the mindset of the company was
we're outnumbered, the number of machines out there
is going to be way more than we can handle,
therefore we need to automate all operations.
They started that on the operating system itself,
with CoreOS, the namesake of the company.
And then they brought that to Kubernetes.
What you see with OpenShift is, OpenShift 4,
you see us bringing that to, not only the Kubernetes core,
that's the foundation of OpenShift 4,
so all capabilities of running Kubernetes are automated with
20 plus operators now.
But you see that apply to all the other value capabilities
that are on top of OpenShift as well,
and we're bringing that to ISV.
I was walking around and a number of ISV's have
their operators as the number one thing they're advertising.
So you're seeing automated operations really take hold
and with OpenShift 4 being a foundation for that.
>> You talk about operations or operators,
you have Operator Hub that was launched earlier this year,
what was the driving force behind that?
And then ultimately what are you trying to get out of that
in terms of advancement and going forward here?
>> Right, I think it means it's worked.
Going back a little bit of history on this,
the operator pattern was coined at CoreOS as a way
to do things on a Kubernetes cluster to automate operations.
The right way.
You have to expose it as a proper API,
you have to use a controller, so on and so forth.
Then as the team started doing that we realized
well there's a lot of demand for this pattern,
we started documenting it, describing it better and so on.
But then we realized there's a good case for a framework
to help people build these automations.
Therefore we announced the operator framework at Cubeacon.
I think it was a year and a half ago.
What happened then was interesting,
suddenly we started seeing hundreds plus
operators being built on the operator framework.
But, it was hard because you could see five Redis operators,
10 MySQL operators.
It was hard for our customers to know where can I find
the right set of operators that have the right functionality
and how do they compare to each other?
OperatorHub.IO is a registry that we launched together
with AWS, Google and Microsoft to solve for that problem.
Now that we have a way to create operators easily
and capture that automated operations,
we have sort of created a pattern and a framework around it,
where do you go to find the right set of operators.
>> It's an interesting point
because if you look in the container space,
especially Kubernetes, it's like, okay well
what's standardized,
what works across all of these environments?
We always worry, I've probably got some pain from
previous projects and foundations as to well
what's certified and what's not and how do we do that?
So, did I see there's a certification now for operators
and how do you balance that we need it to work everywhere,
we don't wanna have it's Red Hat's building
an open ecosystem not something that's limited to only this?
>> Yes. So OperatorHub.IO is a community initiative.
And, every operator you find on there
should work on any Kubernetes.
So in fact as part of the vetting process
we make sure that that's the case.
And then on the certification we launched today, actually,
and you can see a number of, we have already 20 plus
operators that are certified.
This is where we take it a step further
and we work with the vendors to make sure that it works
on OpenShift.
It's following a number of guidelines that we have,
in terms of using, for example, Rail as the basis.
They work with us to run the updates
through security checks and so on.
And that's just to give our enterprise customers more
levels of guarantees and validation, if they would like to.
>> So what are they getting out of that,
out of the certification system?
What, I guess, stability and certainty
and all those kinds of things that I'm looking for,
standardization of some kind, is that what's driving that?
>> It's simple, at the end of the day they got three things.
They get automated updates that are pushed through
the OpenShift update mechanism.
So if you are using the Redis one, for example,
and it's certified, you're gonna be able to update
the Redis operator through the same
cluster administration mechanism,
then you would apply it to the entire cluster itself.
You see updates from Redis come in,
you can put it through the same approval work so on, so on.
The second is they get support.
So they get first line of support from Red Hat.
They can call Red Hat, our customers and actually
we work with them on that.
And the third is that they actually get that security
vulnerability scans that we put them through
to make sure that they pass certain checks.
And actually one last one, they also get Rail
as the basis of the operator, so, yup.
>> Reza, help bring us into the customer point of view.
What does all this mean to them,
what are the big challenges,
how do they modernize their applications
and get more applications moving along this path?
>> Yeah, in this case the operator customer
is mainly the infrastructure administrators.
It's important to point that out.
The developers will get some benefit on that in that
it's self service, so the provision,
but there's other ways to do that as well.
You can go to a Helm chart, deploy that Helm chart,
you get that level of self service automated provisioning.
To go ahead and configure for example,
a charted MongoDB database on a Kubernetes cluster,
you have to create something like 20 different objects.
And then to update that to change the charts,
you have to go and modify all those 20 different objects.
Let's just stay at that level alone.
An operator makes that before different parameters
on a yaml file that you change.
The operator takes that
and applies all these configurations for you.
So, it's all about simplifying the life
of the infrastructure administrators.
I truly believe that operators, human operators,
infrastructure administrators are one of the least
appreciated personas right now that we have out there.
They're not the most important ones,
but there is a lot of pain points and challenges
that they have we're not really thinking about too much.
And I think OpenShift goes a long way and operators go a
long way to actually start thinking about their pain point
as well.
>> So what do you think their reaction was this morning
when they're looking, first off, the general announcement,
right?
And then some of the demonstrations
and all those things that are occurring?
Is there, do you have or are you talking to customers?
Are you getting the sense of relief
or of anticipation or expectation?
I mean, how would you characterize that?
>> Think they're falling into a couple of different buckets.
There's the customers we've talked to, for awhile now,
that know this stuff, so this is not super new to them,
but they're very happy to see it.
There's one big automaker that's a customer of us
and the main human operator was telling me awhile ago
that he does not want any service on the cluster
unless it has an operator, this is a year and a half ago.
And he kept pushing me well I want a Kafka one
and I want an Elasticsearch one, and you know.
And we, CoreOS, were too small
to try to build that ourselves.
Obviously that's not, we can't maintain a Kafka operator
and a CoreOS one.
Now, he's able to go to our operator APP,
he's gonna be able to get a Kafka operator
that's maintained by Kafka experts.
He's gonna be able to get a Redis operator
that's maintained by Redis experts.
So that bucket of customers are super happy.
And then there's another one
that's just starting to understand the power of all this.
And I think they're just starting to kick the tires
and play around with this.
Hopefully they will get to the same point
as the first bucket of customers,
and be asking for everything
to be operator based all the time.
>> Convert the tire kickers, you're gonna be okay, right?
>> That's right.
>> Thank you for the time.
>> Thank you.
>> We appreciate that and continued success at Red Hat,
and, once again, good to see you.
>> Thank you, always a pleasure.
>> You bet.
Live, here on theCUBE, you're watching Red Hat Summit 2019.
(upbeat music)