Making Kubernetes Enterprise Ready - OpenShift CTO Advisor 104

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're listening to episode 104 of the CTO Advisor, I promise as I make the transition to doing the CTO Advisor back full-time versus working at VMware, I will be a lot more consistent with these things. But to make up for not having a CTO Advisor podcast in a while, I do have a special guest. I have a bit of a celebrity in the podcasting world, at least in our world, right, Brian? You guys over at the Cloudcast do some good work and probably one of the most popular enterprise IT podcasts out there.

I see you're just over 400 episodes now. Hey, Keith, great for having me on. Yeah, we try and get one out every week. We've been going for, I don't know, eight and a half, nine years now. So yeah, it's, you know, I don't know what the popularity is, but we have a lot of fun doing it and people seem to keep coming back. So it's fun for us to do. So this is something that we haven't done. I've been on the Cloudcast a couple of times, more than a couple of times.

You know, you kind of have an open invitation for me to, when I, you know, I want to have some of my crazy theories out to the broader population you invite me on. But I wanted to invite you on. We've had some, you know, in-person conversations around Kubernetes and I wanted to talk to you as your day job director of product strategy at Red Hat. And of course, your role is the Cloudcast host about Kubernetes. So first off, Red Hat is probably the most famous open source software company in the world.

If I have to put on my enterprise IT hat and make up a weird Internet stat, this is just a weird stat that I'm making up. I don't know if it's true, but my anecdotal impression is that. Ninety percent of the most popular open source projects, companies are unknown to the enterprise IT architect, like we know the big ones, Red Hat, Cloudera, MongoDB, and then it starts to taper off. Can you talk about a little bit of, you know, kind of why you, because you're coming from a more traditional, you know, you, you know, you spent some time at EMC, Cisco, some of the biggest IT providers in the world.

Why did you go to Red Hat, an open source software company? Yeah, it's a good question. Like, yeah, like you said, I spent a lot of time early part of my career at what would be considered, you know, proprietary companies. So Cisco and NetApp and EMC and a few others. You know, I think for me it changed probably around 2008, 2009 time frame. OpenStack as a project had gotten announced and I was working in the CTO's office at Cisco at the time.

And, you know, I started to realize how communities worked. It was weird because I live here in Raleigh, so Red Hat's always been in my backyard. We always knew about Red Hat, but wasn't always top of mind. But I started to kind of really see the power of what happened with communities. You know, I started to get a sense of what happens when you have a lot of people who have an interest in making an alternative to some popular solution. So, you know, OpenStack at the time was sort of structured to be an alternative, somewhat to VMware and somewhat to AWS.

And, you know, people can have opinions about it. But I got to know a lot of it then. And then I had an opportunity when I was at EMC to actually start their first open source group. So we created a thing that was called EMC Code at the time. And it was funny because the way the origin of that thing got started was I literally got a call from the CMO one day on a Friday afternoon and he said, hey, I just got done with an executive briefing with a large company.

And they basically said, we're not going to buy any more of your proprietary technology anymore. We're going to buy all these open source things. So, you know, you mentioned Cloudera and Hadoop and Mongo and some stuff. And that was kind of all out there. And he basically said, you know, how in the world are we going to deal with open source? Because it seems like it's a big deal. And so, you know, that was another one of those light bulb moments for me when I was like, OK, the the proprietary vendors are going to struggle with this somewhat.

They may not be displaced by any means, but they're struggling to figure out what do they do when, you know, big companies, real companies want to use this technology. And then the last piece of it is sort of a funny thing, you know, kind of one of those, you know, don't burn too many bridges stories. I was actually working. I did I did a short stint for an analyst from Wikibon, who, you know, and they run the cube. And my first project there was to write an analysis of all the different paths platforms at the time.

So, you know, Pivotal, Cloud Foundry at the time, a company called Apprenda and Red Hat OpenShift was in there and a few others were in there. And at the time, this was the 2014, 15 sort of time frame. You know, I sort of wrote, you know, Cloud Foundry is really kind of the the most mature platform. If you're looking for this sort of technology, this is probably your best choice. And at the time, Red Hat OpenShift was just transitioning to Kubernetes.

So it was really new. Kubernetes was really new. Nobody really trusted Google. And, you know, I wrote a kind of a nice enough summary of what they did, but I didn't recommend it. I was, you know, kind of hesitant about it. And six months later, I got a call from Red Hat and they said, hey, we didn't really love your report because we'd like to win, but we like the way you structured it. We like the way that you think about the industry.

We think you've got, you know, sort of interesting knowledge in this space. Would you like to come help us, you know, get actually, you know, could you help us get higher up in the rankings if you happen to write a new report? And they said, you know, we'd love you to come over and work for us directly. And I think it was one of those things where I was like, wow, I'm not going to be able to do that. But it was one of those things where I was like, wow, working in open source for a proprietary company was really hard because essentially you were trying to change the DNA of the company.

Red Hat's DNA is fundamentally open source. I mean, the company is, you know, the blurring of the line between the company's DNA and open source community DNA is very gray. I mean, it's hard to sometimes tell the difference. And I thought if, you know, if this is one of the trends that I think is going to be you know, this was a really good opportunity to get involved with early technology at a company that, you know, wasn't going to fight itself to do open source.

Yeah, I remember the EMC open source days and you know what? That was some tough going. That was pretty brave of you to, you know, lead a group of open source proponents inside of EMC. EMC and open source is not like two things that were synonymous with each other or it is today. So Red Hat seems like a much better place, obviously, if you're into open source. But you said something that actually I was planning on asking. The OpenShift brand predates Kubernetes.

Yeah, you know, I think today OpenShift and Kubernetes are kind of, you know, when they equate to one another in most people's minds. But OpenShift itself has, you know, you mentioned OpenStack. I remember the early days of OpenStack and everyone's trying to figure it out and OpenShift brand kind of appearing during the OpenStack days. Obviously, OpenShift is much bigger than Kubernetes itself. Can you explain to me kind of in a nutshell what OpenShift is? Yeah. So, you know, you're right to point out that the brand has been around for a little while.

It's actually been around since 2011, I think commercially since 2011. So it got started in the same timeframe as Cloud Foundry. There was a whole bunch of projects and products at the time and cloud services at the time that were all going after what used to be called PaaS. I guess it's still called PaaS. You know, the goal of it was always how do we make developers productive and as much as possible, try and hide the complexities of the infrastructure. So, you know, back in 2011, OpenShift tried its hand at being an open source PaaS.

It was trying to replicate what Heroku and some others were doing. And quite honestly, it struggled. And I would say to a certain extent, all of the PaaSs sort of struggled because they had a couple of flaws. They all had a flaw somewhere in there. The biggest flaws in that whole space was there was no commonality of how applications were packaged. So every platform had their own way of packaging an application. And then the second thing was every platform, whether they were considered open source or they were cloud service or something, were all building their own scheduling system.

And so when you have sort of fragmentation of all the things, you don't get any of the benefits of open source. You have either competing communities or you have, you know, small teams all working on basically the same problem. And what happened with OpenShift was they kind of came to this realization of, you know, Red Hat has a certain model that they know works. And it's, you know, how much do we contribute to a community? How healthy is a community? And what they saw was they saw the Docker project take off.

And so they got heavily invested around that. And that was going to be the standard way to package an application. And then they were looking at, you know, which of these orchestrators, whether it was Kubernetes or Mesos or Docker Swarm was going to win. And they kind of made a big bet. It was kind of maybe considered a crazy bet at the time in 2014, 2015. And they said, you know, we're going to bet on Kubernetes. We're going to help Google make a market out of this or make a community out of this.

We're going to help them open source it. We're going to bring enterprise smarts to it. And so the bet was ultimately on the Docker format for standardizing how to package applications. And then the Kubernetes scheduler for being able to orchestrate and coordinate a lot of applications. And so in 2015, with OpenShift 3, you know, OpenShift essentially became probably the first commercial enterprise Kubernetes offering in the market. And Red Hat has continued to be, you know, the number two contributor to the Kubernetes project only behind Google.

So right now, you know, OpenShift is Kubernetes. You know, the engine underneath the covers is Kubernetes. And then what we add to it is, you know, we bring a lot of that developer experience to the platform as well. So we try and bring flexibility about how developers can bring applications to the platform, right to the platform, and hopefully, you know, hide a lot of the complexities of Kubernetes and containers from them if they don't really want to see it. They just want to be productive developers.

So when you look at Red Hat, you know, obviously, the most famous product within Red Hat is Linux. Sure. I don't know if I've been in a large enterprise infrastructure that did not have some type of support agreement with Red Hat for Rail. And so if you look at, at least from my perspective, if you look at the average Red Hat customer who's, you know, vested in, you know, what I want, a supportable, rock-solid version of Linux to run my, whether it's LAMP stack or whatever cloud-native application they're looking at building, there's, I think, a culture that forms around that.

And one of the aspects of that culture, from my perspective, has been, you know, this thing that we want productized solutions, whether they come from proprietary solutions or from open source. And when I look at Kubernetes, especially when Red Hat got into Kubernetes, I can't say that, you know, five years ago that Kubernetes was a very enterprise-friendly platform. Like, what, with all the options on the market or in open source in general, what did Red Hat see in Kubernetes that made them choose Kubernetes?

You know, a project coming out of Google is not something that I normally say, oh, let's make this broadly available for enterprise customers. Yeah. No, it's a great question. I think when we looked at it, you know, there was a couple aspects to it. I think first and foremost, the fact that it was based on Google's Borg, you know, so it was somewhat of a new project, but it was based on Google's Borg, which basically said, it's going to have web-scale DNA built into it, right?

It's been around for a while. The concepts have been around for a while. So that part was really interesting to us in that we said, okay, while Google doesn't necessarily have experience in the enterprise, the engine is designed to scale and it's proven to scale. So that was a checkbox. The second one was they were very interested in it being community-owned and governed. And so we looked at that and we said, okay, they want to structure it so that we're not going to be, you know, potentially fighting with them or somebody else be fighting with them over the direction of where it should go.

And, you know, for us, that was a really healthy indicator of, you know, this is going to allow a community to grow and flourish, not just be a Google project. And then I think the third thing, and this is really important and people don't always understand this, is Kubernetes, the patterns that are built into Kubernetes. So, you know, the early patterns were pretty simple. It was, you know, run an application, you know, short term and run an application that will run, you know, long life and so forth.

But what we saw in it was it was going to be a technology that allowed a lot of different types of patterns to work, which meant a lot of different types of applications would eventually be able to natively take advantage of Kubernetes. And what that meant was, yes, you know, stateless, scalable cloud native applications would work, but it wasn't hard for us to see that, yep, we're going to be able to extend this to work with stateful applications. We're going to be able to make big data applications and AI and ML work on this.

You know, and so when we saw that, that to us said, okay, that's going to be a really good fit in the enterprise because you know this, the enterprise is filled with lots of different kinds of applications. Some are new. A lot of them are legacy in some form or, you know, some way, shape or form. And I think we looked at that and we said, boy, we have a really big opportunity to bring our enterprise expertise into this community and really add to the project and help it flourish.

Kubernetes has a reputation, I think, deservingly so, for being pretty hard to manage. You know, probably the most famous Kubernetes advocate out there is Kelsey Hightower, and he has probably the most popular book, which is Kubernetes the Hard Way. And when you look at a book like that and you look at, you know, taking Kubernetes, and I don't think anyone realistically takes an open source project and goes, you know, kind of unsupported and bare metal with it themselves. However, if you look at the fundamentals of Kubernetes, it is, I think, in my impression, harder to manage than Linux was in some of its earlier days.

Where are you seeing the most value for enterprises looking at Kubernetes, especially when it has a reputation for being a difficult to manage system? Yeah, so I think you highlight a couple of really interesting things there. I think, you know, we make this analogy sometimes, and maybe this is too Linux-y because, you know, Red Hat's known as a Linux-y company, but we tend to say that, you know, the same way that nobody these days, you know, goes out and takes the Linux kernel and compiles their own distribution, right?

They go get it from Red Hat or, you know, SUSE or Debian or whatever. We kind of think that that's the analogy that works best with, would you ever take Kubernetes by itself from the upstream and try and build things around that? Because, and there's a little bit of parallelism. We had this with OpenStack where people thought, oh, okay, OpenStack is VMware, right? They confused a project with a product, and then they started realizing, oh, okay, wait, OpenStack is, there's a piece of it that's for compute, and there's a piece for storage and a piece for networking and a piece for this and a piece for that.

And there's a little bit of that with Kubernetes. Kubernetes by itself does a few things, but people forget that there's so many things that aren't part of Kubernetes by default that if you tried to put it all together, you know, you're piecing together a lot of things. It doesn't do networking. It doesn't do storage. It doesn't do CICD. It doesn't do logging. It doesn't do, I mean, like, those are all things that somebody has to figure out how to wire together in order to make Kubernetes at all useful.

And so I think the reason that people are attracted to OpenShift is that we've essentially made it a complete platform, right? It's Kubernetes as an engine, but we include by default, you know, SDN networking. We include storage of lots of different protocols and flavors. We include a monitoring stack. We include a logging stack. We include, you know, a really rich user interface and experience. We integrate with AD. So, you know, all those checkbox things that enterprises would expect of a product, a platform, those come by default.

And then I think the other thing that's been really successful with OpenShift was we also realized that we learned, and we learned this from the past days. We sort of, you know, maybe even learned it from the Cloud Foundry days. You can only be so opinionated with the enterprise. If you force the enterprise and you say, you must do things only this way with only these technologies, it's really easy for them to say, you know what? I don't need that project right now.

That's too much grief. And so we tried to be, you know, prescriptive and complete in what we deliver by default, but we're also modular. If somebody says, hey, I want to use Splunk for logging or I want to use, you know, NetApp for storage or something, we allow pluggability for that as well. And so I think, you know, number one, bringing it all together so people can start using it on day one and then allowing them to, you know, properly integrate it into an enterprise has been a lot of the reason why OpenShift has been probably more successful than a lot of the other, you know, kind of do-it-yourself Kubernetes or just real bare bones Kubernetes offerings that are out there.

Yeah, I think this is some of the frustration with the OpenStack kind of attempt to penetrate the enterprise. Getting a working OpenStack product inside of your organization was really hard. I think Kubernetes has learned a lot. And as I understand Kubernetes and OpenShift, OpenShift is a fully compliant Kubernetes distribution. So if I don't want to use the SDN that comes with OpenShift, I can plug in another one. It's still upgrade in theory to the next version of OpenShift as it comes out.

That's my understanding of how it works. Is that correct? Yep, absolutely. Yeah, I mean, there's, I think we have about seven or eight different ones. So if you want to plug in VMware's NSX or Tigera or, you know, a lot of other ones, you can plug those in as well. But yeah, that was the other big piece of it is Kubernetes, the project has a new version that comes out every quarter. And if you think about that in the context of the enterprise, especially for something that's kind of an infrastructure-y product or technology, asking the infrastructure team to touch it every quarter is kind of crazy.

And so, you know, as a company, we had to work really, really hard to figure out how do we make it so that it's, you know, the value they get out of making the applications effective is more than the pain they have to deal with from, you know, touching the infrastructure on a regular basis. And actually, you know, we dealt with that for a while with OpenShift. And I think every Kubernetes distribution struggle with it. We actually reached a point where we said, we have to completely look at this differently.

We acquired a company called CoreOS about 18 months ago, last January or February. That's now fully integrated into OpenShift version 4. But we had to completely rethink what the automation and the update mechanisms look like for a, you know, a Kubernetes platform to deal with the fact that it, you know, has so many moving parts coming out of the community so quickly. Yeah. So you kind of led right into one of the last questions I wanted to ask, which was the competitive solutions from not necessarily, you know, VMware has its OpenStack distribution.

I mean, I'm sorry, Kubernetes distribution, PKS, which I think customers, I don't really think customers too much struggle on PKS versus OpenStack. I think those is about the relationship more than anything about the actual product details. What's more interesting to me is OpenShift versus like consuming it as a SaaS. Because that quarterly cadence worrying about deploying it, even if OpenShift makes it simple, you know, when I look at VKE or ECS or whatever, the Azure Kubernetes services, etc. What are the deciding factors for customers choosing to consume Kubernetes as basically a control plane managed by someone else versus, you know what?

I want to bear the burden, however, the burden is of running the on-prem version of Kubernetes, be it OpenShift or any other version. Yeah, it's a great question. It's one that's coming up a lot with different companies that we talk to or companies that come to us. I think there's a, there's kind of a checklist that I think runs through a lot of people's mind. You know, the first one is, do I, you know, where do I want to run my Kubernetes?

If I only want to run it in the public cloud, that's sort of one decision criteria. If I think there's going to be opportunities where I need it in the public cloud, but also in their private cloud, or potentially, I'm going to potentially want to run it in this one public cloud, but also another public cloud. You know, that's, that tends to be the first criteria they figure out is like, okay, where do I think I need to run the application? And what are the criteria for making me think that location is a deciding factor?

The second one tends to be like, okay, if I'm thinking about more than one location, if that's either a today problem or a future problem, do I want them to be consistent? And, and this is a really big, I don't want to say misnomer or kind of misunderstanding in the market, but here's the thing. Almost every Kubernetes offering on the planet is compliant. They check the boxes to get the CNCF compliance thing. The thing that people don't always think about is beyond Kubernetes.

And again, go back to what we talked about earlier. It doesn't include that many things, right? So everything else you have to make work. And so if you think about it, let's, let's take a common example. If I were, for example, to run OpenShift on prem and my network of choice was, let's say VMware NSX, right? I'm not going to be able to get NSX as the internal networking in AWS or in Azure. Or in Google, right? So my network team, if I were to say I have to run Kubernetes on prem and in the public cloud, well, I'm going to have two different environments, even though compatibility wise, yes, they're both Kubernetes.

And, you know, can I put something in a container and make it run? Yes, compatible. But the rest of your operations is typically going to be different, right? Different logging, different authentication. So that becomes a factor. Do I need, do I want consistency between environments? And then the third thing ultimately comes down to what do, what do I want the software or the platform to deliver for me? And then what do I want to, what do I want to have to build or maintain above and beyond?

So let's take the basic Kubernetes services that are out there, you know, EKS, AKS, GKE, and so on and so forth. Those basically give you the bare bones Kubernetes thing. They expect that you're just going to bring a raw container, a Docker container and run it. They don't provide you necessarily a developer experience. They don't provide you integrated CI and CD. They don't provide you logging, you know, automatic logging of your containers running to some centralized logging thing. So what ends up becoming a lot of times the deciding criteria is people will say, do I want to have to basically do a build myself on top of one of the public cloud offerings?

Or do I want to acquire technology like OpenShift and run that, you know, in the public cloud as opposed to, you know, putting it together themselves? So those types of things are the high level questions that people have. I'll give you a little bit of kind of context of that from an OpenShift perspective. We probably have somewhere between 30 and 40 percent of our customers today who run OpenShift on the public cloud, right? It's not just an on-prem product. They'll run that software on the public cloud because they want to be in the public cloud.

They want to take advantage of on-demand or, you know, location or wherever. So, you know, we find there are a lot of usages in the public cloud of people who like OpenShift as a more robust Kubernetes platform. The other thing for us, and this came up at Red Hat Summit here in May, you know, we've found people who say we want OpenShift. We just don't want to run it ourselves. Can you manage it for us? And while we've had an OpenShift offering that Red Hat offers, so think of Red Hat as being, you know, like Amazon offering a Kubernetes type of thing.

That's called OpenShift Dedicated. We announced a public service with Azure. So Microsoft is actually going to run OpenShift as a service out of their cloud as a native service. So it's called Azure Red Hat OpenShift. And demand for that has been through the roof. It's been really interesting to see how many people are like, I like OpenShift. I didn't want to run it myself. I want to have the backing of a, you know, massively scalable cloud provider behind it.

And it's just kicking off. But we feel like we've got to offer people the ability to say, run it wherever you want. Do you want to manage it? Do you want someone else to manage it? And then you're going to see us more and more offering different price points to say, hey, do you want to buy it as software on an annual basis? Or do you want to start consuming it on demand? And all those options will be there as well.

So it's, there's a matrix of decisions. But we feel like providing that robustness of functionality a lot of times wins out over the bare bones Kubernetes functionality. So Brian, we're going to have to have you on for a part two to add in some detail. Because that's a really interesting announcement and a really good blending. I have a ton of follow on questions about integration, et cetera. But until then, if people just can't wait until that next episode, where can people find out more about OpenShift?

com. com, at OpenShift on Twitter. And actually, I'll give you a really great site for your listeners that are technical. If you want to play around with it, and you're like, I don't want to set it up, I don't want to deal with that. com, there are a ton of free browser only structured training that are out there that people can kind of walk through everything from the basics of Kubernetes to, you know, how do I set up, you know, really complicated scenarios and stuff.

So that's a great site to go free, good chance to kind of go experience the technology if you want hands on. Yeah, I might check that out myself. Where can people find you on the web and the Cloudcast? Best way to do it is at bgracely on Twitter. A couple things as far as the podcast goes, I do host the Cloudcast, which is a weekly show, you can find it on iTunes and all the other ones. And if you're really into Kubernetes, I host a probably bi-weekly one called podctl, P-O-D-C-T-L, which is just about it's about 50% Kubernetes talk, kind of what's going on in the community, and about 50% OpenShift talk.

So if you're really into into this specific topic, podctl is another one that we do that we have a lot of fun with. Yeah, I tried to listen to it once or twice. It was a little bit too geeky and too inside baseball for me, but it is a great podcast if you want to dive deep into Kubernetes in the community. Brian, I really appreciate you joining the podcast. com and on Twitter at CTO Advisor. Talk to you next, CTO Advisor podcast.