 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 Shafi, who is the VP of Platform Services at Red Hat, former CoroS guy, and Stu actually has his CoroS socks on. He told me. Today, yeah, so he came dressed for the occasion. I can't see those on camera, John. I know. I can't be wearing better gear. I was going to say don't show it to the camera. They're cool, they're cool. Glad to have you with us, Reza. And first off, just your impression, 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 CoroS leadership team and the Red Hat leadership team and when the acquisition was closed. And we planned this out, I remember a meeting we had on the whiteboard, we planned this out in terms of bringing the best of OpenShift and CoroS technology together. And it's really great to see it out there on the keynote and actually all demoed and working. And working, right? Yeah. Reza, I'd like to dig in for us a little bit here because it's one thing to say, okay, we got a whiteboard and we put things together. When I looked at both companies, I mean first, both CoroS before the acquisition and Red Hat, I mean, open source. Absolutely as it's core. I remember talking to the CoroS team, I'm like, you guys are going to be able to hold a bunch of really cool tools but what's the business there? You guys think you're going to 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. CoroS 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 created really nice, comfortable surface area for the dev teams. The dev teams can go in and start pushing their applications and it just ensures that it's running those applications in the right way. The CoroS roots came from the operations perspective and the administrators, system administrator. Like we always looked at the world from a system administrator. Yes, you're right. CoroS had a number of technologies they were working on. HCD, Rocket, Clare. You know, 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 you know, 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 differentiator was automated operations. The core tenets of what Alex Polvian, Brandon Phillips, set into the mindset of the company was, we are 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 CoroS, 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 at the foundation of OpenShift 4, so all capabilities of running Kubernetes are automated with 20 plus operators now. But you see that applied to all the other value-add capabilities that are on top of OpenShift as well and we're bringing that to ISVs. If I was walking around and a number of ISVs 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 the foundation for them. You talk about operations or operators, you have Operation, or Operator Hub that was launched earlier this year. What was the, I guess, 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's worth 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 is a lot of demand for this pattern. We started documenting it, describing it better and so on. But then we realized, okay, there's a good case for a framework to help people build these automations. Therefore, we announced the Operator Framework at KubeCon. 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 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 an initiative, 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? Yeah, well, 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 want to have, it's RedHatch 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, that as part of the vetting process, we make sure that that's the case. And then on the certification that 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, Rails 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? I mean, 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 story they get three things, right? 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 know, you're going to be able to update the Redis operator through the same cluster administration mechanism that you would apply it to the entire cluster itself. You see updates from Redis come in, you can put it through the same approval workflow and 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're past certain checks. And actually one last one, they also get rel as the basis of the operator. So, yeah. All right, so Reza, you know, help bring us into the customer point of view. What does all of this mean to them? You know, one of the big challenges, you know, 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 or 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 provision. To go ahead and configure, for example, a sharded MongoDB database on a Kubernetes cluster, you have to create something like 20 different objects. And then to update that to change the shards, you have to go and modify all those 20 different objects. Just, let's just stay at that level alone. An operator makes that be four 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 operator, human operators, infrastructure administrators are one of the least appreciated personas right now that we have out there. One of the most important ones, but there is a lot of pain points and challenges that they have that we're not really thinking about too much. And I think OpenShift 4 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 the reaction was this morning when they're looking at the first off, the general announcement, right? And then some of the demonstrations and all those things that are occurring is there, I mean, do you have or are you talking to customers? Are you getting a sense of relief or of anticipation or expectation? I mean, how would you characterize that? I think they're falling into a couple of different buckets. There's the customers we've talked to for a while now that know this stuff. So, this is not super new to them, but they're very happy to see this. So, there is one big automaker that is a customer of us and the main human operator was telling me a while 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 I want... And we, CoreOS, were too small to try to build that ourselves. Obviously, that's not... We can't maintain a Kafka operator in a CoreOS one. Now, he is able to go to operator hub. He's going to be able to get a Kafka operator that's maintained by Kafka experts. He's going to be able to get a Redis operator that's maintained by Redis expert. So, that bucket of customers, super happy. And then there's another one that's, just starting to understand the power of all this. And I think that's, they're just starting to kick the tires and play around with this. And so, hopefully, they will get to the same point as the first bucket of customers and be asking for everything to be operated based on. Yeah, convert the tire kickers, you're going to be okay, right? That's right. Thank you for the time. Oh, 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.