>> Live, from Barcelona, Spain, it's theCUBE, covering KubeCon and CloudNativeCon Europe, 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation and ecosystem partners. >> Welcome back. This is theCUBE at KubeCon CloudNativeCon 2019 here in Barcelona, Spain. I'm Stu Miniman, my co-host is Corey Quinn and welcoming back to the program, friend of the program, Brian Gracely who is the Director of Product Strategy at Red Hat. Brian, great to see you again. >> I've been, I feel like I've been in the desert. It's three years, I'm finally back, it's good to be back on theCUBE. >> Yeah well, I feel like we've been traveling parallel paths a lot. TheCUBE goes to a lot of events. We do a lot of interviews but I think when you go to shows, you actually have more back-to-back meetings than we even do, so we feel you in the jet lag and a little bit of exhaustion. Thanks for making time. >> Yeah, it's great. I had dinner with you two weeks ago, I did a podcast with Corey a week ago, and now, due to the magic of the internet, we're all here together in one place. It's good. >> Absolutely. Well Brian, as we know at a show like this we all want to hold hands and sing Kubernetes Kumbaya. It's wonderful to see that all of the old fights of the past have all been solved by software in the cloud. >> They're all good, it's all good. Yeah, somebody said it's a cult. I think I heard Owen Rodgers said it's now officially a cult. Corey, you called it the Greek word for spending lots of money. >> Uh yeah, it was named after the Kubernetes, the Greek god of spending money on cloud services. >> So, Brian, you talk to a lot of customers here. As they look at this space, how do they look at it? There's still times that I hear them, "I'm using this technology and I'm using this technology, "and gosh darn it vendor, "you better get together and make this work." So, open-source, we'd love to say is the panacea, but maybe not yet. >> I don't think we hear that as much anymore because there is no more barrier to getting the technology. It's no longer I get this technology from vendor A and I wish somebody else would support the standard. It's like, I can get it if I want it. I think the conversations we typically have aren't about features anymore, they're simply, my business is driven by software, that's the way I interact with my customer, that's the way I collect data from my customers, whatever that is. I need to do that faster and I need to teach my people to do that stuff. So the technology becomes secondary. I have this saying and it frustrates people sometimes, but I'm like, there's not a CEO, a CIO, a CTO that you would talk to that wakes up and says, "I have a Kubernetes problem." They all go, "I have a, I have this business problem, "I have that problem, it happens to be software." Kubernetes is a detail. >> Yeah Brian, those are the same people 10 years ago had a convergent problem, I never ran across them. >> If you screw up a Kubernetes roll-out, then you have a Kubernetes problem. But it's entertaining though. I mean, you are the Director of Product Strategy, which is usually a very hard job with the notable exception of one very large cloud company, where that role is filled by a post-it note that says simply, yes. So as you talk to the community and you look at what's going on, how are you having these conversations inform what you're building in terms of Openshift? >> Yeah, I mean, strategy you can be one of two things. You can either be really good at listening, or you can have a great crystal ball. I think Red Hat has essentially said, we're not going to be in the crystal ball business. Our business model is there's a lot of options, we will go get actively involved with them, we will go scratch our knees and get scars and stuff. Our biggest thing is, I have to spend a lot of time talking to customers going, what do you want to do? Usually there's some menu that you can offer them right now and it's really a matter of, do you want it sort of half-baked? Are you willing to sort of go through the learning process? Do you need something that's a little more finalized? We can help you do that. And our big thing is, we want to put as many of those things kind of together in one stew, so that you're not having-- Not you Stu, but other stews, thinking about like, I don't want to really think about them, I just want it to be monitored, I want the network to just work, I want scalability built in. So for us it's not so much a matter of making big, strategic bets, it's a matter of going, are we listening enough and piecing things together so they go, yeah, it's pretty close and it's the right level of baked for what I want to do right now. >> Yeah, so Brian, an interesting thing there. There's still quite a bit of complexity in this ecosystem. Red Hat does a good job of giving adult supervision to the environment, but, you know, when I used to think when row came out, it was like, okay, great. Back in the day, I get a CD and I know I can run this. Today here, if I talk to every Kubernetes customer that I run across and say okay, tell me your stack and tell me what service measure you're using, tell me which one of these projects you're doing and how you put them together. There's a lot of variation, so how do you manage that, the scale and growth with the individual configurations that everybody still can do, even if they're starting to do public clouds and all those other things? >> So, it's always interesting to me. I watch the different Keynotes and people will talk about all the things in their stack and why they had problems and this, that, and the other, and I kind of look at it and I'm like, we've solved that problem for you. Our thing is always, and I don't mean that sort of boastfully, but like, we put things together in what we think are pretty good defaults. It's the one probably big difference between Openshift and a lot of these other ones that are here is that we've put all those things together as sort of what we think are pretty good defaults. We allow some flexibility. So, you don't like the monitoring, you don't like Prometheus plugin splunk, that's fine. But we don't make you stand on your head. So for us, a lot of these problems that, our customers don't go, well, we can't figure out the stack, we can't do these things, they're kind of built in. And then their problem becomes okay, can I highly automate that? Did I try and make too many choices where you let me plug things in? And for us, what we've done, is I think if we went back a few years, people could say you guys are too modular, you're too plugable. We had to do that to kind of adapt to the market. Now we've sort of learned over time, you want to be immutable, you want to give them a little less choice. You want to really, no, if you're going to deploy an AWS, you got to know AWS really well. And that's, you know, not to make this a commercial, but that's basically what Openshift four became, was much more opinions about what we think are best practices based on about a thousand customers having done this. So we don't run into as many of pick your stack things, we run into that next level thing. Are we automating it enough? Do we scale it? How do we do statefulness? Stuff like that. >> Yeah, I'm curious in the Keynote this morning they called, you know, Kubernetes is a platform of platforms. Did that messaging resonate with you and your customers? >> Yeah, I think so, I mean, Kubernetes by itself doesn't really do anything, you need all this other stuff. So when I hear people say we deployed Kubernetes, I'm like, no you don't. You know, it's the engine of what you do, but you do a bunch of other stuff. So yeah, we like to think of it as like, we're platform builders, you should be a platform consumer, just like you're a consumer of Salesforce. They're a platform, you consume that. >> Yeah, one of the points made in the Keynote was how one provider, I believe it was IBM, please yell at me if I got that one wrong, talks about using Kubernetes to deploy Kubernetes. Which on the one hand, is super cool and a testament to the flexibility of how this is really working. On the other, it's-- and thus the serpent devours itself, and it becomes a very strange question of, okay, then we're starting to see some weird things. Where do we start, where do we look? Indeed.com for a better job. And it's one of those problems that at some point you just can't manage a head around complexities inside of complexities, but we've been dealing with that for 40 years. >> Yeah, Kubernetes managing Kubernetes is kind of one of those weird words like serverless, you're like what does that mean? I don't, it doesn't seem to, I don't think you mean what you want it to mean. The simplest way we explain that stuff, so... A couple of years ago there was a guy named Brandon Philips who had started a company called CoreOS. He stood up at Kube-- >> I believe you'll find it's pronounce CoreOS, but please, continue. >> CoreOS, exactly. Um, he stood up in the Seattle one when there was a thousand people at this event or 700, and he said, "I've created this pattern, "or we think there's a pattern that's going to be useful." The simplest way to think of it is, there's stuff that you just want to run, and I want essentially something monitoring it and keep it in a loop, if you will. Kubernetes just has that built in. I mean, it's kind of built in to the concept because originally Google said, "I can't manage it all myself." So that thing that he originally came up with or codified became what's now called operators. Operators is that thing now that's like okay, I have a stateful application. It needs to do certain things all the time, that's the best practice. Why don't we just build that around it? And so I think you heard in a lot of the Keynotes, if you're going to run storage, run it as an operator. If you're going to run a database, run it as an operator. It sounds like inception, Kubernetes running-- It's really just, it's a health loop that's going on all the time with a little bit of smarts that say hey, if you fail, fail this way. I always use the example like if I go to Amazon and get RDS, I don't get a DVA, there's no guy that shows up and says, "Hey, I'm your DVA." You just get some software that runs it for you. That's all this stuff is, it just never existed in Kubernetes before. Kubernetes has now matured enough to where they go, oh, I can play in that world, I can make that part of what I do. So it's less scary, it sounds sort of weird, inception-y. It's really just kind of what you've already gotten out of the public cloud now brought to wherever you want it. >> Well, one of the concerns that I'm starting to see as well is there's a level of hype around this. We've had a lot of conversations around Kubernetes today and yesterday, to the point where you can almost call this Kubernetes and friends instead of CloudNativeCon. And everyone has described it slightly differently. You see people describing it as systemd, as a kernel, sometimes as the way and the light, and someone on stage yesterday said that we all are familiar with the value that Kubernetes has brought to our jobs and our lives, is I think was the follow-up to that, which is a little strange. And I got to thinking about that. I don't deny that it has brought value, but what's interesting to me about this is I don't think I've heard two people define its value in the same terminology at all, and we've had kind of a lot of these conversations. >> So obviously not a cult because they would all be on message if it was a cult. >> Yeah, yeah yeah yeah. >> It's a cult with very crappy brand control, maybe. We don't know. >> I always just explain it that like, you know, if I went back 10 years or something, people... Any enterprise said hey, I would love to run like Google or like Amazon. Apparently for every one admin, I can manage a thousand servers and in their own data centers it's like well, I have one guy and he manages five, so I have cloud envy. >> We tried to add a sixth and he was crushed to death. Turns out those racks have size and weight limits. >> That's right, that's right. And so, people, they wanted this thing, they would've paid an arm and a leg for it. You move forward five years from that and it's like oh, Google just gave you their software, it's now available for free. Now what are you going to do with it? I gave you a bunch of power. So yeah, depending on how much you want to drink the Kool-Aid you're like, this is awesome, but at the end of the day you're just like, I just want the stuff that is available to, that's freely, publicly available, but for whatever reason, I can't be all in on one cloud, or I can't be all in on a public cloud, which, you believe in that there's tons of economic value about it, there's just some companies that can't do that. >> And I fully accept that. My argument has always been that it is, I think it's a poor best practice. When you have a constraint that forces you to be in multiple cloud providers, yes, do it! That makes absolute perfect sense. >> Right, if it makes sense, do it. And that's kind of what we've always said look, we're agnostic to that. If you want to run it, if you want to run it in a disconnected mode on a cruise ship, great, if it makes sense for you. If you need to run, you know, like... The other thing that we see-- >> That cruise ship becomes a container ship. >> Becomes a container ship. I had an interesting conversation with the bank last night. I had dinner with the bank. We were talking, they said, look, I run some stuff locally where I'm at, 'cause I have to, and then, we put a ton of stuff in AWS. He told me this story about a batch processing job that cost him like $4 or $5 million today. He does a variant of it in Lambda, and it cost him like $50 a month. So we had this conversation and it's going like, I love AWS, I want to be all in at AWS. And he said, here's my problem. I wake up every morning worried that I'm going to open the newspaper and Amazon, not AWS, Amazon is going to have moved closer into the banking industry than they are today. And so I have to have this kind of backup plan if you will. Backup's the wrong word, but sort of contingency plan of if they stop being my technology partner and they start becoming my competitor, which, there's arguments-- >> And for most of us I'd say that's not a matter of if, but when. >> Right, right. And some people live with it great. Like, Netflix lives with it, right? Others struggle. That guy's not doing multi-cloud in the future, he's just going, I would like to have the technology that allows me if that comes along. I'm not doing it to do it, I'd like the bag built in. >> So Brian, just want to shift a little bit off of kind of the mutli-cloud discussion. The thing that's interest me a lot, especially I've talked to a number of the Openshift customers, it is historically, infrastructure was the thing that slowed me down. We understand, oh, I want to modernize that. No, no wait. The back in thing or you know, provisioning, these kind of things take forever. The lever of this platform has been, I can move faster, I can really modernize my environment, and, whether that's in my data center or in one public cloud and a couple of others, it is that you know, great lever to help me be able to do that. Is that the right way to think about this? You've talked to a lot of customers. Is that a commonality between them? >> I think we see, I hate to give you a vendor answer, but we tend to see different entry points. So for the infrastructure people, I mean the infrastructure people realize in some cases they're slow, and a lot of cases the ones that are still slow, it's 'cause of some compliance thing. I can give you a VM in an hour, but I got to go through a process. They're the ones that are saying, look, my developers are putting stuff in containers or we're downloading, I just need to be able to support that. The developers obviously are the ones who are saying, look, business need, business problem, have budget to do something, That's usually the more important lever. Just faster infrastructure doesn't do a whole lot. But we find more and more where those two people have to be in the room. They're not making choices independently. But the ones that are successful, the ones that you hear case studies about, none of them are like, we're great at building containers. They're great at building software. Development drives it, infrastructure still tends to have a lot of the budget so they play a role in it, but they're not dictating where it goes or what it does. >> Yeah, any patterns you're seeing or things that customers can do to kind of move further along that spectrum? >> I think, I mean there's a couple of things, and whether you fit in this or not, number one, nobody has a container problem. Start with a business problem. That's always good for technology in general, but this isn't a refresh thing, this is some business problem. That business problem typically should be, I have to build software faster. We always say... I've seen enough of these go well and I've seen enough go poorly. There's, these events are great. They're great in the sense of people see that there's progress, there's innovation. They're also terrible because if you walk into this new, you feel like, man, everybody understands this, it must be pretty simple. And what'll happen is they start working on it and they realize, I don't know what I'm doing. Even if they're using Openshift and we made it easy, they don't know what they're doing. And then they go, I'm embarrassed to ask for help. Which is crazy because if you get into open source the community's all there to help. So it's always like, business problem, ask for help early and often, even if it embarrasses you. Don't go after low-hanging fruit, especially if you're trying to get further investment. Spinning up a bunch of web clusters or hello worlds doesn't, nobody cares anymore. Go after something big. It basically forces your organization to be all in. And then the other thing, and this is the thing that's never intuitive to IT teams, is you, at the point where you actually made something work, you have to look more like my organization than yours, which is basically you have to look like a software marketing company, because internally, you're trying to convince developers to come use your platform or to build faster or whatever, you actually have to have internal evangelist and for a lot of them, they're like, dude, marketing, eh, I don't want anything to do with that. But it's like, that's the way you're going to get people to come to your new way of doing things. >> Great points, Brian. I remember 15 years ago, it was the first time I was like wait, the CIO has a marketing person under him to help with some of those transformations? Some of the software roles to do. >> Yeah, it's the reason they all want to come and speak at Keynotes and they get at the end and they go, we're hiring. It's like, I got to make what I'm doing sound cool and attract 8,000 people to it. >> Well absolutely it's cool here. We really appreciate Brian, you sharing all the updates here. >> Great to see you guys again. It's good to be back. >> Definitely don't be a stranger. So for Corey Quinn, I'm Stu Miniman. Getting towards the end. Two days live, wall-to-wall coverage here at KubeCon, CloudNativeCon 2019. Thanks for watching theCUBE. (rhythmic music)

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

>> Narrator: From Copenhagen, Denmark, it's theCUBE, covering KubeCon, and CloudNativeCon Europe 2018. Brought to you by the Cloud Native Computing Foundation, and its ecosystem partners. >> Okay, welcome back, everyone, live coverage here in theCUBE, in Europe, at Copenhagen, Denmark for KubeCon Europe 2018. This is theCUBE. We have the CNCF, at the Cloud Native Computing Foundation, part of the Linux Foundation. I'm John Furrier, co-host of theCUBE, with Lauren Cooney, the founder of SparkLabs, new venture around open source and innovation. Our analysts here, today with theCUBE, and our two guests are Michael Hausenblas, who's the direct developer advocate at Red Hat. Diane Meuller's the director of community development at Red Hat, talking about OpenShift, Red Hat, and just the rise and success of OpenShift. It's been really well-documented here on theCUBE, but certainly, in the industry, everyone's taking notice. Great to see you again, welcome to theCUBE, good to see you. >> Thank you. >> And wonderful to be here again. >> So, first of all, a lot of big news going on. CoreOS is now part of Red Hat, so that's exciting. I haven't had a chance to talk to you guys about that yet here on theCUBE, but great, great puzzle piece from the industry there for you guys, congratulations. >> Yeah, it's been a wonderful collaboration, having the CoreOS team as part of the Red Hat, and the OpenShift team, it's just a perfect fit. And the team from CoreOS, they've always been my favorite people. Alright, and Brandon Philips and the team over there are just awesome. And to have the expertise from Tectonics, the operator framework, which you'll hear more about here at KubeCon EU this week, to have Quay under the wings of Red Hat now, and Quay is a registry with OpenShift or with any other Kubernetes, you know, the stuff that they brought to the table, and the expertise, as well as the wonderful culture that they had, it was such a perfect fit with OpenShift. >> And you know, you guys bring a lot to the table, too. And I was, I mean, I've been kind of critical of CoreOS in the past, in a good way, 'cause I love those guys. I had good chats with them over the years, but they were so pure open-source guys, like Red Hat. >> Diane: Well, there's nothing wrong with being pure open-source. (laughing) >> No, no, I'm cool with that, but you guys have perfected the business more, you have great customers. So one of the things that they were always strong at was the open-source piece but when you start to monetize, and you start to get into the commercialization, it's hard for a start-up to be both, pure open-source and to monetize. You guys now have it together, >> Yeah. >> Great fit. >> So, it's a wonderful thing. We, on the OpenShift side, we have the OpenShift Commons, which is our open-source community, and we've sort of flipped the model of community development and that's at Red Hat. And one of the things is, they've been really strong, CoreOS, with their open-source projects, whether etcd, or you know, a whole myriad of other things. >> Well, let's double down on that. I want to get your thoughts. What is this OpenShift Commons? Take a minute to talk about what you guys had. You had an event Monday. It was the word on the streets, here in the hallways, is very positive. Take a minute to explain what happened, what's going on with that program? >> So OpenShift Commons is the open-source community around OpenShift Origin, but it also includes all the upstream projects that we collaborate with, with everybody from the Kubernetes world, from the Promytheus, all the CNCF project leads, all kinds of people from the upstream projects that are part of the OpenShift Ecosystem, as well as all the service providers and partners, who are doing wonderful things, and all the hosts, like Google, and you know, Microsoft Azure folks are in there. But, we've kind of flipped the model of community development on its head. In the past, if you were a community manager, which is what I started out as, you were trying to get people to contribute to your own code base. And here, because there's so much cross-community collaboration going on, we've got people working on Kubernetes. We got Kubernetes people making commits to Origin. We work on the OCI Foundation, trying to get the container stuff all figured out. >> So when you say you flipped the model, you mean there's now multiple-project contributions going on, or? >> Yeah, we've got our fingers in lots of pies now, and we have to, the collaboration has to be open, and there has to be a lot of communication. So the OpenShift Commons is really about creating those peer-to-peer networks. We do a lot of stuff virtual. I host my own OpenShift Commons briefings twice a week, and I could probably go to three or four days a week, and do it, because there's so much information. There's a fire hose of new stuff, new features, new releases, and stuff. Michael just did one on FAS. You did one before for the machine-learning Saigon OpenShift on Callum. >> Hold on, I want to just get your thoughts, Michael, on this, because what came up yesterday on theCUBE, was integration glue layers are really important. So I can see the connection here. Having this Commons model allows people to kind of cross-pollenate, one. Two, talk about integration, because we've got Promytheus, I might use KubeFlow. So there's new things happening. What does this mean for the integration piece? Good for it, or accelerating it? What's your thoughts? >> Right, right, right. So, I mainly work upstream which means when it is KubeFlow and other projects. And for me, these kind of areas where you can bring together both, the developers, and the end users, which is super important for us to get the feedback to see where we really are struggling. We hear a lot from those people that meet there, what their pinpoints are. And that is the best way to essentially shape the agenda, to say, well, maybe let's prioritize this over this other feature. And as you mention, integration being one big part, and Functions and Service being, could be considered as the visual basics of applications for Cloud Native Computing. It can act as this kind of glue between different things there. And I'm super excited about Commons. That's for me a great place to actually meet these people, and talk with them. >> So the Commons is almost a cross-pollination of folks that are actually using the code, building the code, and they see other projects that makes sense to contribute to, and so it's an alignment where you allow for that cross-pollination. >> It's a huge series of conversations, and one of the things that is really important to all of the projects is, as Michael said, is getting that feedback from production deployments. People who are working on stuff. So we have, I think we're at around 375 organizational members, so there's... >> John: What percentage of end-user organizations, do you think? >> It's probably about 50/50. You know, you can go to Commons.OpenShift.org, and look up the participants list. I'm behind a little bit in getting everybody in there, but-- >> John: So it's a good healthy dose of end-users? >> It's a good healthy dose of end-users. There's some special interest groups. Our special interest groups are more around used cases. So, we just hosted a machine-learning reception two nights ago, and we had about 200 people in the room. I'd say 50% of them were from the KubeFlow community, and the other 50% were users, or people who are building frameworks for our people to run on OpenShift. And so our goal, as always, is to make OpenShift the optimal, the best place to run your, in this case, machine-learning workloads, or-- >> And I think that's super critical, because one of the things that I've been following a little bit, and you know, I have your blog entry in front of me, is the operator framework, and really what you're trying to do with that framework, and how it's progressing, and where it's going, and really, if you can talk a little bit about what you're doing there, I think that would be great for our viewers. >> So what I'm going to do is I'm going to make sure you get Brandon Philips here, on your KubeFlow, sometime this week, 'cause I don't want to steal the thunder from his keynote tomorrow morning-- >> Lauren: Well, drop a couple hints. (laughs) >> John: Share a little bit, come on. >> So the operator stuff that CoreOS, and they brought it to the table, so it's really their baby. They had done a lot of work to make sure that they had first-class access to be able to inject things into Kubernetes itself, and make it run. And they're going to do a better technical talk on it than I am, and make things run. And so that what they've done is they've opened up and created an STK for operators, so other people can build more. And we think, this is a tipping point for Kubernetes, and I really don't want to steal any thunder here, or get in over my head, is the other part of it, too. >> I think Brandon is the right person to talk about that. >> Brandon, we'll drag Brandon over here. >> I'm super excited about it, but let's-- >> Yeah, let's talk about why you're super excited about it. Is there anything you can kind of tell us in terms of what? >> Enables people to run any kind of workload in communities, in a reliable automated fashion. So you bring the experience that human operators have into software. So you automate that application, which makes it even more suitable to run your enterprise application that so far might have not been the best place to run. >> Lauren: That's great, yeah. >> And yeah, I'm also looking forward to Brandon explaining the details there. >> So I think it's great hearing about that, and we talk a lot about how it's great for users. It's great, you know, operators, developers, how they're building things out, and things along those lines. But one of the things that we are not hearing a ton about here, and we want to hear more about, is security. Security is increasingly important. You know, we're hearing bits and pieces but nothing's really kind of coming together here and what're your thoughts on that? >> Security, I was recently, when I blogged about it, and people on Twitter said, well, is that really true that, you know, couldn't this secure body fall? It's like, well, all the pieces are there. You need to be aware of it. You need to know what you're doing. But it is there, right? All the defaults might not be as you would expect it, but you can enable it. And I think we did a lot of innovations there, as well. With our back, and security context, and so on. And, actually, Liz Rice and myself are working on putting the security cookbook, and for a variety that will come out later this year. We're trying to document the best practice, because it is early days, and it's quite a range of things. From building container images in a secure way, to excess control, and so on, so there's a lot of stuff (mumbles). >> What're some of the end-user feedback sessions, or feedback data that you're getting from these sessions? What is some of the things you guys are hearing? What's the patterns? What's the things that are boiling up to the top? >> Well, there's so many. I mean, this conference is one of those ones where it's a cornucopia of talks, and trying to, I just wrote a little blog post called, The Hitchhiker's Guide to KubeCon. It's on blog.openshift.com. And because, you could spend all of your time here in a different track, and never leave it, like Security 1, or in Operations 1, or-- >> John: There's a lot of great content. >> I think the Istio stuff is probably the hottest thing I'm hearing people going to. There was a great deep-dive training session, hands-on on Monday, here, that got incredible feedback. IBM and Google did that one. We had a lot of customer talks and hands-on training sessions on Monday. Here, there are pretty much, there's a great talk coming up this afternoon, on Kube Controllers that Magic... I think that's at 11:45-ish. There are a lot of the stuff around Service Fish, and service brokers, is really kind of the hot thing that people are looking for to get implemented. And we've got a lot of people from Red Hat working on that. There's, oh man, there's etcd updtes, there's a bazillion things going-- >> John: It's exploding big time here. >> Yeah. >> No doubt about it. >> The number one thing that I'm seeing last couple of months, being onsite with customers, and also here, is that given that Kubernetes is now the defective standard of container authorization, people are much more willing to go all-in, you know? >> Yeah. >> A lot of folks were on the fence, for a couple of years, going like, which one's going to make it? Now, it's kind of like, this is a given. You couldn't, you know, just as Linux is everywhere on the servers, that's the same with Kubernetes, and people are now happy to really invest, to like, okay, let's do it now, let's go all in. >> Yeah, and, what we're hearing, too, just stepping back and looking at the big picture is we see the trend, kind of hearing and connecting the dots, as the number of nodes is going to expand significantly. I mean, Sterring was on stage yesterday, and we heard their, and still small, not a lot of huge, not a lot on a large scale. So, we think that the scale question is coming quickly. >> Well, I think it already came, alright? In the machine-learning reception that we had at night, one of the gentleman, Willem Bookwalter, from Microsoft, and Diane Feddema, from Red Hat, and a whole lot of people are talking about how do we get, because machine-learning workloads, have such huge work, you know, GPU, and Google has their TPU requirements to get to scale, to run these things, that people are already pushing the envelope on Kubernetes. Jeremy Eater from Red Hat has done some incredible performance management work. And on the CNCF blog, they've posted all of that. To get the optimal performance, and to get the scale, is now, I think, one of the next big things, and there's a lot of talks that are on that. >> Yeah, and that's Istio's kind of big service mesh opportunity there, is to bring that to the next level. >> To the next level, you know, there's going to be a lot of things that people are going to experience trying to get the most out of their clusters, but also, I think we're still at the edge of that. I mean, someone said something about getting to 2,500 nodes. And I'm like, thinking, that's just the beginning, baby. >> Yeah, it's going to be more, add a couple zeroes. I got to ask you guys, I got to put you both on the spot here, because it's what we do on theCUBE. You guys are great supporters of theCUBE. We appreciate that, but we've had many conversations over the years with OpenShift, going back to OpenStacks, I don't know what year it was, maybe 2012, or I don't know. I forget what year it was. Now, the success of OpenShift was really interesting. You guys took this to a whole 'nother level. What's the reaction? Are you, as you look back now on where you were with OpenShift and where you are today, do you pinch yourself and say, damn? Or what's your view? >> Red Hat made a big bet on Kubernetes three years ago, three and a half years ago, when people thought we were crazy. You know, they hadn't seen it. They didn't understand what Google was trying to open-source, and some of the engineers inside of Red Hat, Clayton Coleman, Matt Hicks, a lot of great people, saw what was coming, reached out, worked with Google. And the rest of us were like, well, what about Ruby and Rails, and Mongo DB, and you know, doing all this stuff? And like, we invested so much in gears and cartridges. And then, once they explained it, and once Google really open-sourced the whole thing, making that bet as a company, and pivoting on that dime, and making version 3.0 of OpenShift and OpenShift Origin, as a Kubernetes-based platform, as a service, and then, switching over to being a container platform, that was a huge thing. And if you had talked to me back then, three years ago, it was kind of like, is this the right way to go? But, then, you know, okay. >> Well, it's important to history to document that point, because I remember we talked about it. And one of the things, you guys made a good bet, and people were scratching their head, at that time. >> Oh yeah. >> Big time. But also, you've got to give credit to the community, because the leaders in the community recognized the importance of Kubernetes early on. We've been in those conversations, and said, hey, you know, we can't screw this up, because it was an opportunity. People saw the vision, and saw it as a great opportunity. >> I think, as much as I like the technical bits, as an engineer, the API being written and go, and so on, I really think the community, that is what really makes the difference. >> Yeah, absolutely does. >> If you compare it with others, they're also successful. But here with CNCF, all the projects, all the people coming together, and I love the community, I really-- >> It's a case study of how to execute, in my opinion. You guys did a great job in your role, and the people didn't get in the way and try to mess it up. Great smart people understood it, shepherded it through, let it grow. >> And it really is kudos to the Kubernetes community, and the CNCF, for incubating all of this wonderful cross-community collaboration. They do a great job with their ambassadors program. The Kubernetes community does amazing stuff around their SIGs, and making sure that projects get correctly incubated. You know, they're not afraid to rejig the processes. They've just done a wonderful thing, changing the way that new projects come into the Kubernetes, and I think that willingness to learn, learn from mistakes, to evolve, is something that's really kind of unique to the whole new way of thinking about open-source now, and that's the change that we've seen. >> And open-source, open movements, always have a defining moment. You know, the OSI model, remember? That stack never got fully standardized but it stopped at a really important point. PCPIP, IP became really important. The crazy improbability world, CISCO, as we know, and others. This is that kind of moment where there's going to be a massive wealth creation, value creation opportunity because you have people getting behind something, as a de facto standard. And then, there's a lot of edge work around it that can be innovated on. I think, to me, this is going to be one of those moments we look back on. >> Yeah, and I think it's that willingness to adjust the processes, to work with the community, and you know, that Kubernetes, the ethos that's around this project, we've learned from a lot of other foundations' mistakes. You know, not that they're better or worse, but we've learned that you could see the way we're bringing in new projects, and adding them on. We took a step back as a community, and said okay, this is, we're getting too many, too soon, too fast. And maybe, this is not quite the right way to go. And rather than doing the big tent umbrella approach, we've actually starting doing some really re-thinking of our processes, and the governing board and the TOC of the CNCF, have done an awesome job getting that done. >> When you got lightning in a bottle, you stop and you package it up, and you run with it, so congratulations. Red Hat Summit next week, we'll be there, theCUBE. >> Oh yeah. >> Looking forward to going deep on this. >> Well, the OpenShift Commons Gathering is the day before Red Hat Summit. We've completely sold out, so sorry, there's a waitlist. We've gone from being, our first one, I think we had 150 people come. There's over 700 people now coming to the Gathering one, and 25 customers with production deployments speaking. This is the day before Red Hat Summit. And I lost count of how many OpenShift stories are being told at Red Hat Summit. It's going to be a crazy, jetlag-y week, next week, so-- >> Congratulations, you guys got a spring in your step, well done. OpenShift going to the next level, certainly the industry and Kubernetes, a service mesh as Istio. Lot of great coverage here in theCUBE, here in Europe for KubeCon 2018 in Copenhagen, Denmark. I'm John Furrier, and Lauren Cooney, the founder of SparkLabs. I'm with theCUBE, we'll be back with more live coverage. Stay with us! Day Two, here at KubeCon, we'll be right back. (upbeat techno music)