 Live from Barcelona, Spain, it's theCUBE, covering KubeCon CloudNativeCon Europe 2019, brought to you by Red Hat, the CloudNative 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 welcome back to the program, friend of the program, Brian Graceley, who is the director of product strategy at Red Hat. Brian, great to see you again. I have been, I feel like I've been on like in the desert. It's three years, I'm finally back. It's good to be back on theCUBE. Yeah, well, you know, and we feel like we've been traveling, you know, 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. Yeah, 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. Yeah, somebody said it's a cult. I think I heard Owen Rogers said it's now officially a cult. But Corey, you called it the Greek word for spending lots of money. Yeah, it was named after the Kubernetes, the Greek god of spending money on cloud services. So Brian, you talked 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 a 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 companies that 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. Like I have this saying and it frustrates you but I'm like, there is 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 this business problem, I have that problem, it happens to be software. Kubernetes is a detail. Yeah, Brian, those were the same people 10 years ago had a convergence problem. I never ran across them. If you screw up a Kubernetes rollout, 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 like, we're not going to be in the crystal ball business. It's our business model is there's a lot of options. We will go get actively involved with them. We'll 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 like, 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 stew, 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 like 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. So Brian, 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 when I used to think, when Well 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, you know, 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? It's always interesting, 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, right? Our thing is always, and I don't mean that like 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 plug-in splunk, that's fine. But we don't make you stand on their head. So for us, a lot of these problems that like 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 pluggable. We had to do that to kind of adapt to the market. Now we've sort of learned over time like you want to be immutable, you want to give them a little less choice, you want to really know if you're going to deploy in AWS, you got to know AWS really well. And that's, not to make this a commercial, but that's basically what OpenShift 4 became, was much more opinions about what we think our best practice is based on about a thousand customers having done this. So we don't run into as many of like 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 Kubernetes is a platform of platform. That messaging resonate with you and your customers? Yeah, I think so. I mean, you know, 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, 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 of 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 Phillips who had started a company called CoreOS. He stood up at Kubernetes. I believe you'll find it's pronounced CorioS, but please continue. Corios, exactly. He stood up in the Seattle one when there was 1,000 people at this event or 700. And he said, I've created this pattern and 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 into 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, but 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 DBA. There's no guy that shows up and says, hey, I'm your DBA. You just get some software that runs it for you. That's all this stuff is. It just never existed in Kubernetes before. Kubernetes is 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. 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 could almost call this Kubernetes and friends instead of cloud native, cloud native com. And everyone has described it slightly differently. You see people describing the system D as a kernel, sometimes as the way in 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 as I think was the follow up to that which is a little strange. And I got to thinking about that. And it's, 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 defund and it's value in the same terminology at all. And we've had kind of a lot of these conversations. Obviously not a cult because they would all be on message if it was a cult. Yeah, yeah, yeah. It's a cult with very crappy brand control, maybe. We don't know. Yeah, I always just explain it that like, you know, if I went back 10 years or something, you know, people, any enterprise said, hey, I would love to run like Google or like Amazon, right? Apparently for every one admin, I can manage a thousand servers and in their own data center, it was 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 you know, so people, they wanted this thing, they would have 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 know 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 me, you know, that's freely, you know, publicly available. But for whatever reason, I can't be all in on one cloud or I can't be all in on the public cloud, which I know 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 absolutely perfect sense. It makes sense to 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 the 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 because I have to. And then, you know, we put a ton of stuff in AWS. He told me this story about a batch processing job that cost him like four or five million bucks today. He does a variant of it in Lambda. And it cost him like 50 bucks a month. You know, so we had this conversation and it's going like, I love AWS. I want to be all in AWS. And he said, and 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 is the wrong word, but sort of contingency plan of like, if they stop being my technology partner and they start becoming my competitor, which there's- 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. So that guy is not doing multi-cloud in the future. He's just going like, I would like to have the technology that allows me if that comes along, right? I'm not doing it to do it. I'd like the back, you know, that built in. So Brian, I just want to shift a little bit off of kind of the multi-cloud discussion. The thing that's interest me a lot, and 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 backend thing or provisioning and 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 great lever to help me be able to do that. Is that the right way to think about this? Is, you know, you 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, when the infrastructure people realize they're, in some cases, they're slow. In a lot of cases, the ones that are still slow, it's because of some compliance thing. So I can give you a VM in an hour, but I got to go through a process. They're the ones that are saying, like, look, my developers are putting stuff in containers or we're downloading, like 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. So it's the 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? Yeah, I think, I mean, there's a couple of things in whether you fit in this or not it. Number one, nobody has a container problem, right? Start with a business problem, right? 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. 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 like, 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, like the community is kind of all there to help. So it's always like business problem, ask for help early and often, even if it embarrasses you. Build, 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 world, 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 evangelists. And for a lot of them, they're like, dude, marketing, 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. Yeah, no, great points, Brian. I remember 15 years ago as the first time I was like, wait, the CIO has a marketing person under him to help with some of those transformations. So some of the software roles they're doing. 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 sharing all the updates here. Yeah, great to see you guys again. It's good to be back. And yeah, 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.