 Let me check. From San Francisco, it's theCUBE, covering Red Hat Summit 2018. Brought to you by Red Hat. Hey, welcome back everyone. We are live here with theCUBE in San Francisco, Moscone West for Red Hat Summit 2018. I'm John Furrier, the co-host of theCUBE, with John Troyer, co-host, analyst this week with Tech Reckoning Co-Founder. Our next two guests are Shesh Bhande and vice president general manager of OpenShift Platform and Alex Holvy, CEO of CoreOS, interview of the week because CoreOS now part of Red Hat. Congratulations, good to see you again. Thanks for coming on theCUBE. Thanks for. So I'll say this is, for us, we've been covering both of you guys pretty heavily. We've been commenting very positively around the acquisition of CoreOS. Two great companies that no open source, pure open source. You guys got the business model nailed down. These guys got great tech. You bring it together. So the first question is, how's everyone doing? How's everyone feeling? And where's the overlap? If anyone, where's the fit? Explain the true fit of CoreOS. So why don't I start, Alex, if you want to jump in after? We're very excited, right? So when we first had interactions with CoreOS, we knew this was going to be a great fit, right? The conversation we had earlier, both companies that delivers in open source, delivers in the mission to take us forward with regard to Kubernetes as the container orchestration engine and then being able to build out value for customers around it. I think from our perspective, the work that both CoreOS did in advancing the community forward, but also the work they've done around automation over the air upgrades, management, monitoring, charge back, and so on. Being able to bring all those qualities into Red Hat is incredible. So I think the fit's been good. It's been three months. I'll let Alex comment some more on that, but we've been doing a lot of work from an integration perspective, around engineering, around product management. At Red Hat Summit this week, we've revealed details around some of the Converged Roadmap, which I can talk about some more as well. So we're feeling pretty good about it. Alex, your reaction? Yeah, so it's been three months. If you've studied CoreOS at all, you know kind of everything that we do really centers around this concept of automated operations. And so by being part of Red Hat, we're really starting to bring that to market in a much bigger and faster way, or really accelerating it. I mean, the way the acquisitions are really successful is if they're mutually beneficial to both companies and they accelerate the adoption of technology, and that's definitely happening. We had the announcement yesterday with Red Hat CoreOS around the Linux distribution. Last week, we did the operator framework, was very central to the work that we've been doing as part of CoreOS. And then as companies, in a lot of ways, now being part of Red Hat for three months now, it's just like this is what our company would've looked like if we were just, you know, another 10 years along, or whatever, very similar. We're like a mini Red Hat, and now we were just leaped ahead in a big way. And you guys, you guys done a good work. We've documented on theCUBE many times. We were in Copenhagen last week now covering the operator framework. But I want to get your reaction because you guys did a lot of great work on the tech side. Obviously, it's documented, you can go into more detail. But we've always been saying on theCUBE, if you try to force monetization in these emerging markets, you're optimizing behavior. And this was something that's gone on. We've seen containers, it's still well documented. Obviously, what's happened, it's certainly a beautiful thing. You've got Kubernetes now on top, working together with that. As an entrepreneur out there that are building companies, if you try to force the monetization too early, you're really kind of thinking differently. You guys stayed true to it, and now we've got a good home at Red Hat. Talk about that dynamic, because that was something that I know you guys faced at CoreOS and you managed through it, tempted probably many times to do something. Talk about the mission that you had, staying true to that, and it's just that dynamic. It's challenging. Yeah, so as set out to build a company in general, there are really like three operating principles. There is build, great technology to solve our mission, which is to secure the internet, through automated operations. Build a great place to spend our days, which is really about the people and the culture, and so on, and you know, why are we doing this? And the third was to make it sustainable. And by that, I mean like, you know, build our own money fountain, spewing out of the middle of our campus. And so by joining Red Hat, it's like we just, you know, we have a money fountain sitting there. It's spewing off a ton of cash flow every single quarter that allows us to continue to do those first two things and for opportunity. And that third one is something every company needs in order to continue to execute towards a mission. And the thing that's so awesome about working with Red Hat is we're very much aligned and compatible. You know, Red Hat's mission isn't exactly the same thing we were working on, but it is definitely compatible. It's like Apache and GPL are compatible. You know, it's like that type of compatible. You both believe in open source in a big way. Talk about the Red Hat perspective. Now you got like a kid in the cany, so your open shift was made a big bet with Kubernetes. You see now you got the CoreOS. How has it changed in Red Hat internally? Things move around. Obviously accelerates the game a bit for you guys and you're seeing new life being pumped into OpenStack. You're seeing clear line of sight with the Kubernetes on the app side. We were just at KubeCon. A lot of people are pretty excited. There's clear lines of sight on what's de facto, what people are going to build around and also differentiate. Right. So I'll start off by saying, I really hope RCE or Jim Wighters doesn't see this interview. Oh. Because if it goes off and here's a money fountain I'm going to go on to make budget requests. I think I know what's going on. I think it's a balance sheet in cash flow standards with the public filings. And I see a fountain of money spewing off the thing. The ability to reinvest. This is a really good thing. The way to say it is that they have a great business model. Yeah, great business model. Some of us will make money, some of us will spend the money to work out well. It's a great win. It's a great win. Obviously it accelerates the plans. The commercialization is already there with Red Hat. This is just a good thing for everybody. But the impact to you guys accelerates, you can boil it down to the impact to Red Hat. What is the impact? So in all seriousness, I think the focus for us really has been about there is so much complimentary work that's been going on with the CoreOS team that we're bringing in to OpenShift and to Red Hat in general that accelerates everything that you're seeing. You saw some amazing announcements happen this week right with regard to our partnership with Microsoft and getting OpenShift out in Azure as a joint support offering. The work we're doing with IBM to get IBM Middleware as well as IBM Cloud Private supported and integrated with OpenShift. The work that Alex referred to around automation, being able to bring that to our customers, we see a lot of excitement around that front as well. So we want to take all the tectonic work that has been going on at CoreOS, converge that into OpenShift, carry forward the community that CoreOS built around container Linux and actually inject a lot of those ideas into Red Hat and Press Linux, our flagship technology. Bring that passion and energy to bear there as well. And then carry forward a lot of the other projects that they had. For example, the Quake Container Registry is extremely popular, carry that forward to support our customers to use that both standalone integrated with the OpenShift platform. Other projects like HCD that Alex has been talking about which is the underpinnings of Kubernetes clusters running worldwide. So all of those things we can bring forward and then all the advancements that were made in place by CoreOS as they're working towards their money fountain, just plug that right into. And just as a point of reference, Brendan Burns flew in yesterday. Microsoft Build is going on. So he left their own conference, come down here. That's a real- As did Scott Guthrie, right? That's a great testament. This is the testament. They're coming down, really laying down support. This is like a real big deal. It's not like a fake deal. It's real. I want to talk a little bit about specifics of the timeline and the roadmap. Sometimes with these mergers or acquisitions, right? It's like, well, the technology will be incorporated at some point and then it goes away to die and you never see it again. And then the people all leave and then you ask what was going on. But here you actually have, I was great. You were talking, we have actually some specific timelines and we'll start to see some of the tectonic stack in OpenShift fairly soon. Yeah, absolutely. So the acquisition was announced about three months ago and we said at that time that my Red Hat Summit will lay out for you a roadmap. And so we're now starting to do that. We put out, you know, a release and some material around some details with regard to how that's coming out. We have detailed sessions going on at Red Hat Summit around, you know, the integration plans between Red Hat, OpenShift and CoreOS. But a few specific areas, you know, with regard to OpenShift, you'll start seeing the earliest versions, if you will, of the work that's being done this summer. We'll deliver the full roadmap to you there by the end of this calendar year. With regard to, for example, pieces like the Quake Container Registry, right? That's being made available and being sold now as we speak, customers can go get that. And we want to make sure no customers left behind, right? And with regard to supporting any existing customers on Tectonic or the Container Linux piece, we're doing that as we're working to integrate them into the Red Hat portfolio. Can you talk a little bit about the decision for Red Hat's Atomic Coast and Container Linux now renamed again, CoreOS? I mean, that was one of the seminal inventions that you all made as you started the company. I think it had some brilliant ideas, again, about security and operational, the operational aspects. But can you talk about some of that at those technologies and the decisions that made there? Yeah, so, like I said, the acquisition of CoreOS by Red Hat was about saying, look, what can we take that CoreOS has been doing to accelerate both work in the community but also work that they've been doing to deal with technology to customers? So the goal was, we'll take Project Atomic and the work that's been going on there had that be superseded by the work that's coming out of CoreOS Container Linux, carry the community forward, release a version of that called Red Hat CoreOS and in its initial form make that actually an underlying environment to run OpenShifting. So for customers who want the automation that Alex talked about earlier, make that available both at the underlying platform, make it available in OpenShift, the platform itself, via the work that's coming from Tectonic, and then ultimately, Alex will talk about this some more through operators. So trusted operations from ISV or third-party software that will run in the platform. And now, if you will, we'll have full-stack automation all the way through. OpenShift will also support REL, Red Hat and Press Linux, our traditional environment for the thousands of customers that we have globally. Over a period of time, you should expect to see much of the work that's going on in Red Hat CoreOS find its way into REL. So I think there's just benefits all around for us, both in the near term as well as long. And Red Hat Container Certification, where's that fit into all this? Yeah, great question. So what we announced maybe it was two years, actually it was two years ago, was a container certification program. Last year, we spent some time talking about the health of those containers and being able to provide that to customers. And this year, we're talking about trusted operations around those containers. That carries forward. We've got hundreds of ISVs that have built certified containers around it. And now with the operator framework, we've had, I think it's four ISVs demonstrating previews of their operators working with our platform, as well as 60 more that are committed to building ISV operators that will be certified against them. So people are excited in general, pretty much. I think we were very excited, right? The fact that we went to KubeCon last week, announced the operator framework that's been based on the ideas that the CoreOS team's been working on for at least two years, making that available to the community, and then saying, for the ISVs that want a path to market, going back to the Money Fountain again, for the ISVs that want a path to market, which is pretty much all of them. We also have an ability to do that. So give them an opportunity to make sure they have as wide a possible set of adoption of their software at the same time, help the commercialization. Can you guys share your definition of operator? Because I saw the announcement, but we were in a little broader definition when we see the DevOps movement going to the next level. It's all about automation, right? And security mentioned that. Admin roles are being automated in a way you start to see more of an operator function within enterprise and emerging service providers. So the role operator now takes on two meanings. It's a software developer, it also has a network operator, it's also a service provider. So what is that, how do you guys view that role? Because if this continues, you're going to have automation, more administrative, it's going to be self-healing, all this stuff's going to go on. Essentially, operations is now the developers, NIT, all kind of blurring together. How do you guys define the word operator in the future? Alex, you want to talk about that? I know it's an area of great interest to you. So operator is the term for the piece of software that implements the automated operations. Okay, and so automated operations, what is that? Well, that's what sets apart, the way I think about it, it's what sets apart a cloud provider versus a hosting provider. It's that set of software that really, you know, runs the thing for you. And so if we were to get into specific Kubernetes lingo, it would be an application specific controller. That's a piece of software that implements the automated operations. Automated operations is a software that gives you that simplicity of cloud. You know, it's like at the core of like a database as a service is both hosting, but also automated operations. Those two things together make up a cloud service. And that software piece is what we're decoupling from the hosting providers for the first time and allowing any open source project or ISV to bring the simplicity of cloud, but in any environment. And that's what the operator is a piece of software that actually goes and implements that. So a microservices framework, this fits in pretty nicely. How do you see, you know, obviously. Microservices is, you know, there's all these terms. Microservice is more of a architecture than anything, but it's saying, look, there's these basic things that every operations team has to go and do. You have to install something. You have to upgrade it. You have to back it up. You have to, when it crashes in the middle of the night, get it going again. A lot of these things, the best practices for how you do them are all common. I mean, there's no like ingenuity in it. And for those things, we can now, because of Kubernetes, write software that just automates it. And this was not possible like five years ago. You couldn't write this software. There were things like configuration management systems and stuff like that that would allow companies to sort of build their own custom versions of this, but to build a generic piece of software that knows how to run, you know, an application like Hermitius or a database or so on, just it wasn't possible to write that. And that's what the first sort of four or five years of CoreS was, was making it possible. That's why you saw all these net new open source projects being built. But once it was possible, it was like, let's start leveraging that. And you saw the first operator come out about a year ago. I think it was our NCD operator was the first one. And when we kind of started talking about this as a concept, and now we're releasing Operator Framework, which is the, from all the learnings of building the first couple, we now made a generic such that anybody can go into it. And as part of Red Hat, we're not bringing it to the whole ISV ecosystem. So the whole plan to make automated operations ubiquitous is, you know, still well underway. I'd love to extend that conversation though to the operator, the person, right? I think you and your team brought the perspective of the operational excellence, right, to the table. A lot of cloud has been driven by the role of developer, right, and dev ops. But I've always felt like, well, wait a minute, operators, the people who used to be known as IT and SysAdmin, they had a lot to bring to the table too about security and about keeping things running and about compliance and about all that good stuff. So can you talk a little bit, as you see the community emerging and as you see all these folks here, how do you talk to people who want to understand what their role is going to be with all this automation in keeping the clouds running? So computers used to be people too. But we're not going to completely automate away everything because there's still parts of this wildly complex system that justifies whole conferences of thousands of people that require a whole lot of human ingenuity. What we're doing is saying, let's not like do the part that is the fire drill in the middle of the night that keeps you from making forward progress. Like the typical role of an operations person today is just fighting fires of mundane things that don't actually like add a lot of value to the business. In fact, being an ops guy is really difficult because you only get brought up when things are on fire. You never get any praise of when things are going well. And so what we want to do is help the operations folks put out those fires, like the security updates, like let's just roll those out automatically. The way you do those across all organizations does not need to be special and unique, but they're really critical to do right. So let's just like automate that stuff away and let the operations team focus on moving the business forward. The parts that require like the human spirit to actually go and do. And if we get to a point where you have a company is like, wow, I cannot come up with a new business initiative because my operations teams are just so fast at implementing them. Like then we'll know, then we have to start worrying about operations people's jobs. But I don't see that happening for a very long time. And no one's going to be idle either. No one's going to be sitting around fiddle in their thumbs either. Let me extend that point a little bit right because the whole point of operators is to encapsulate human knowledge that ISPs have and bring that into the platform and automate it, right? So the challenge that we've had is an operations person is required to know a lot about a lot, right? So the question then really is how can we at least take some of what's already known by people and be able to replicate that, right? And that allows for everyone to move forward. I think that's just forward progress. There was a bigger picture beyond that, so I agree. But there's also scale too. With cloud you have scale issues, so it would scale. Automation is a beautiful thing because the fires also grow exponentially too, right? So you can't be operating like this. Exactly. Scale is matters. Super. The reason that this stuff was invented at Google initially was not because of Google's high query per second. It's that they were, to build the application they're building required so many servers that you couldn't hire enough operations people without writing software to automate it. So they were forced to custom design the system because they had so many servers to run to build the software that they wanted to build. And other companies are just now getting to that point because every company's going through a digital transformation, that they have to have like thousands of servers just to run their applications. And there's no way you're just going to hire the operation staff to go and do it all by hand. You have to write software to turn the operations people into like mech warriors of running servers. You know, you need to like wrap them in automation in order to scale them. Well I interviewed Aparna at KubeCon and she made a comment that all those operations folks at Google are software developers. They're engineers, they're software engineering. So they're not ops guys just pushing buttons and provisioning gear and whatnot. They're actually writing code. You bring up the Google piece, the other piece that we heard at the KubeCon we hear this consistently that this is now a new way to do software development. So what when a former Googler went out and went and worked for another company left Google she went in and she said, oh my God, you guys don't do, you don't use Borg? Like so she, to her she was like, how do you write software? So she was like young and went out to the real world and was like, wait a minute, you don't do this? So this is a new model in software development at scale with these new capabilities. I think so and I think what's really important is the work we're doing with regard to an ecosystem perspective to help folks. So one of the top things I hear from customers all the time is this sounds fantastic. Everyone's talking about DevOps or microservices or wanting to run Kubernetes at scale. Do I have the skills? Can I keep up with the change that's in place? And how do I kind of continue moving forward around that? So we announced at Red Hat Summit managed offerings from let's say ATOS and DXC where you've got global system integrators helping folks or companies like Accenture T-Systems, the CEO came and spoke today about the work we're doing with them to help connected cars and those applications be rolled out quicker and faster. So I think it's going to take a village to get us to where we want to because the rate of change is so fast around all of these areas and it's not slowing down that we'll have to ensure there's more automation and then there's more enablement that's going on for our customers. Also there's some clarity. Can you guys comment on your reaction to obviously we've seen open stack has done over the years and now with Kubernetes, well containers now Kubernetes, you're seeing at least two ecosystems clearly identified. Application developers, cloud native and then I would call under the hood infrastructure guys open stack. Almost it kind of clarifies where people can actually focus on real problems that they communities need. So how has the container of maturation of containers and Kubernetes clarified the role of the community? Because if this continues with automation, you can almost argue that the clarity happens everywhere. Can you comment on how you see that happening? Is it happening or is that just observation that's misguided? I think we're getting better with regard to fit for purpose or fit for use case, right? So if you start thinking about the earliest days of open stack, open stack is going to be AWS in a box. Then you realize, well that's not a practical way of thinking about what a community can do or build depending on for your scale. And so when you start thinking about what are the appropriate use cases for this, now you start getting, if you will, a set of skills, have expectations around how to make that successful. I think we'll go through the same if we haven't already been going through it with regard to Kubernetes, right? So not every company in the world can run and manage what are called DIY Kubernetes, right? So many companies will start with that. And so the question is, how do we get to the point where there's balance around it and then be able to take advantage of the work, for example, companies like Red Hat, what Coros was doing to help accelerate that path? Because to the point Alex was trying to make, right? Is the value for them being able to keep up with a quarterly release of Kubernetes, right? And every time a bug shows up to go off and be able to fix and patch it and watch that or is the value building the next set of application service on top of the platform. That's great. Well, congratulations guys. Thanks for coming on theCUBE. Appreciate the insight. Congratulations on the three months into Red Hat. Good fit. And enjoy the rest of the show. Thanks for coming on. Appreciate it. Live from Red Hat Summit, it's theCUBE's coverage here of Red Hat and all the innovation going on out of the open. We're here in the middle of the open the floor of Moscone West with live coverage. Stay with us for more after this short break.