How IBM and Red Hat Support Platform Engineering Efforts?

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 watching a familiar face, if you're catching this on video. If you're catching this on audio, Stu Miniman. Stu, what's your title at Red Hat? Hey, Keith, my title at Red Hat is I'm the Director of Market Insights on part of what we call the Hybrid Platforms Business Unit, which is all the activity we do in the cloud, includes like the OpenShift products, as well as a few other products, like people remember OpenStack and some of the other services that we offer.

So I have to make sure I get my language right about OpenStack versus OpenShift. I've gotten in trouble inside of Red Hat with completing the two. So I promise you, I will not do that in this IBM sponsored video. Stu, we're going to talk about a market insight that I wanna get from you, which is this concept of the Platform Engineering Team. It seems like I can't create enough content talking about platform engineering. Can you, in a few sentences, explain to me what platform engineering is and what are you seeing in the field?

Yeah, well, first of all, Keith, yeah, it's a super buzzy, hot topic. And anytime you talk about something where we're talking about the future of people's jobs and, oh my gosh, do I have to reset an organizational structure? Is DevOps dead? You know, is, you know, the headline that you see on these. So, you know, what's the challenge that everybody has, Keith? We know, first of all, everything is changing constantly. What do I worry about? I worry about making sure my developers get the most utilization.

You want them delivering code, writing applications, modernizing applications. In the software world, a lot of us measure how am I getting, you know, more efficiency and more out of my developers. And when I talk to my team that are looking at some of the technologies that usually go under the platform engineering heading, a term that came up was they said, you know, we wanna lower the cognitive load for our developers. And that really, it really jumped when I heard it because, Keith, the question I used to ask when I did theCUBE many years ago was, hey, how do you keep up on all of this?

And the answer is none of us can keep up on all of it. Forget it. I get Corey's newsletter about AWS every week. I try to read lots of things. I keep on on all of the activities, but, you know, I need to do my job, but I also need to worry about that new thing and how do I take care of it? Something that we at Red Hat pride ourselves is we help, you know, curate out of the millions of projects that are out there on open source.

There are certain ones that we will contribute to and help make them ready for our customers to be able to consume them, run production workloads on them and the like. So platform engineering at its core is that whole discussion of what do devs do? What do ops do? How do they work together? How does security fit into it? Platforms are not a new discussion. Something, Keith, you and I have been discussing this for over a decade as to, you know, is the cloud the new platform?

What happened to the platform as a service discussion? But as a developer, I just want to be able to consume what I need. I shouldn't have to think about things like scaling and some of the base security. Let me shift that to the platform to be able to handle it. And I actually saw our head of our SRE team at Red Hat had a really good discussion on a different platform saying, you know, well, hey, here's what dev ops do. Here's what SREs do.

Here's what platform engineering do. Is there overlap between all of these teams? Absolutely. But, you know, the core thing that we need is, you know, we need self-service for these kinds of technologies and we need to be able to deliver to the developers what they need when they need it. Which, gosh, Keith, some of these things, you know, remind me of the discussions we had back in the early days of virtualization. It can't take me two months to deploy a server.

I want to, you know, reduce that down to hours of weeks. And today, of course, you know, heck, if it takes me longer than getting my cup of coffee to deploy something, I'm going to be pretty frustrated. So, and over the years, we've talked about this concept of, I mean, I think it's a bad word because it no longer applies. Private cloud. This idea that we can replicate what the cloud providers do on-premises. And we stopped, I think it's safe to say we've stopped thinking about that.

What we started thinking about is how can we give a consistent platform? Without a doubt, and you've mentioned this, what developers love about AWS, Azure, Google Cloud, IBM Cloud, all the clouds, what they love about this is that they can just go provision their resources and have a platform on which they can develop on. One of the early arguments that I had against Kubernetes was that it wasn't exactly that. Like, there was stuff that was missing. There's, you know, things that we find in OpenShift that are packaged and ready to go.

It is a platform. And OpenShift is, you know, when I think about providing these capabilities on-prem, I think about OpenShift. However, when I think about a consistent environment, because what I see what large enterprises want, they want consistency across their cloud environments. They don't care if the cloud is an AWS, on-premises, an IBM Cloud. They want developers and operators to have a consistent experience. Have you seen that? Yes, Keith, absolutely. I do see that. And as you noted, you know, Kubernetes is wonderful.

And, you know, containers, Kubernetes, changed the discussion of architecture quite a bit. But Kubernetes by itself, I need a lot more to really be able to deploy my applications and run really what we tend to call a cloud native architecture today. And the challenge that we have is, you know, even if, you know, I love a cloud and I'm doing most of my things in the cloud, you know, most companies today, I've got my data center. I probably have some hosted environments and I have a primary cloud, but either, you know, by accident, whether it was from acquisition or, you know, some line of business that started using a second cloud, or sometimes there's just a service that somebody makes a really good case for that says, hey, there's some functionality that I can get, an innovation or, you know, heck somebody disrupted something from a price standpoint that I'm going to use a secondary cloud.

Do I need to have that platform team where I start having multiple platform teams? Because the last thing we want is number one, I need to spin up teams to manage all of these different environments and learn and understand them. And secondly, our developers, if all of a sudden you say, I've got a developer working in one environment and now say, oh, hey, I need to shift you and you need to work over here. And they say, forget about it. You had me working on AWS and now I've got to do Google and I've got five years of working on AWS.

It's easier for me to go take another job than it is for me to all of a sudden ramp out and help out, you know, in Google. So again, Kubernetes alone doesn't necessarily solve this issue, but that's what we've tried to do with OpenShift is OpenShift is OpenShift everywhere, no matter you're in one of those environments. And we'll talk a little bit more about how we're integrating deeper with the public cloud providers, but at its core, the OpenShift code, the way of working with OpenShift and writing applications on top of OpenShift is consistent across all of my environments in the data center, in the public cloud and at the edge.

OpenShift equals Kubernetes. I like to say OpenShift equals Kubernetes plus. So if I develop an app in OpenShift, I know I can take those containers. I can take those runtimes and take it to AWS because there's a service in AWS I want to consume. So I think one of the engineering and platform team challenges is, do I take the mobility part of OpenShift and then consume something like a EKS, AKS in AWS? Or do I deploy and have to manage OpenShift inside of AWS on VMs?

And it starts to sound like an anti-pattern to cloud. Yeah, Keith, great point. And in many ways, it echoes what I remember back. You and I, Keith, both have networking background and there are standards and there are wonderful standards, but we know that there is a difference between every vendor and how they deploy things. So while there are dozens of companies that have compliant Kubernetes distributions, unfortunately, I can't necessarily transfer any application from any Kubernetes and just throw it on another because there are underlying dependencies, whether that are things like, we have great interfaces for storage and networking, but the APIs that I write to and how I do things, there are differences between these different environments.

And there are some tools out there to make it a little easier, but to your point, number one is OpenShift and I want to go in the cloud. I can just run OpenShift on AWS. Like customer, I've managed it, I've configured it exactly the way that I want. And I've played with all those wonderful geek knobs that everybody of course loves tuning things to the nth degree. OpenShift allows you to do that and you could then run that in almost any environment, like all the clouds and you can deploy that.

But we've worked jointly with the public cloud providers and we have first party native services. So with AWS is Red Hat OpenShift service on AWS, first party offering, same group that does EKS with Amazon is the engineering team that works with us. And the difference is, it's not just EKS, which is primarily just Kubernetes, which is great compliant Kubernetes and everything. But if you want all of that, you said OpenShift plus, I'm gonna tell you it's Kubernetes like plus, plus, plus, there's a lot of things that go into OpenShift.

But I get all of that inside AWS as a first party offering. And I know you probably have some followups to discuss that because right, you could, if the anti-pattern that I see is yes, you could have OpenShift at the data center and do one of the EKS and Amazon and AKS and Azure, but you've then again, have to have platform team with specific training and specific requirements and developer dependencies for each of those teams, as opposed to just having OpenShift everywhere where you would have consistency.

So I'm gonna try not to get overly geeky on this because there's use cases and why I want to use or I would want to use an EKS and the importance of a first party offering. So with EKS, I don't have to worry about integration into IAM, AWS Identity Management. I can give a runtime, some persistent storage that's managed by EKS, et cetera. I can give it IAM rights and I don't have to stitch that together. When, what AWS has done consistently with first party solutions is that they've integrated in this and what I like to call first class citizen products in which the offering is not any different than any other AWS service.

One, I can get to it from my AWS console. I don't have to go to the marketplace. I can use credits to buy it and I can integrate it into all of my AWS services as if it was another AWS service. So that's the argument I typically see towards using something like EKS. Are you hinting to that ROSA, which is the Red Hat OpenShift, what does the A stand for? Red Hat OpenShift Service on AWS. Oh, okay. And actually, Keith, who named the product?

AWS did, so that was theirs. And to your point, yes, Keith, this is not, we actually have OpenShift, OpenShift container platform, OCP that we've been selling for years, what you can buy for the data center, you can buy that same software in the AWS marketplace. And do we have things to make sure you can still buy that from AWS and do integrations? Absolutely, but ROSA is different, jointly engineered, jointly supported between our two companies. And not to get too geeky, Keith, but I know you'll understand these things.

First of all, where does ROSA integrate with AWS? With ECR, so the container registry, you want predefined IAM roles assigned with ROSA, you've got it. The AWS controller for Kubernetes, which is an ACK operator, that is also supported. So many of the things that you would look at and say, oh, here's what AWS has done with EKS to make it easy to work with all the other Amazon services. We've done the same thing because ROSA is just another one of the hundreds of services that are available in console, first party offered from Amazon.

The only way you know it's from us is it does mention Red Hat there, but you're buying it from Amazon, it's part of your whole support contract that you have, it's jointly supported between the two of us. So, and Keith, it just runs on EC2. So just question we get on the time is like, hey, if you look at pricing, whether you're buying EKS or you're buying ROSA, there's infrastructure that you need to buy on that. I will tell you, is ROSA more expensive than EKS?

Yeah, it is, because there's a whole lot more in OpenShift than just Kubernetes. And even, I'll tell you, the infrastructure is a tiny bit more expensive for kind of the base configuration, just because if you think about there's dozens of other services that we have, there's more infrastructure to support that. And actually, we've been doing some things to make sure we can have more modularity and flexibility in how we handle that piece of it so that we actually believe we'll be shrinking the difference between that piece.

But as you grow and you scale, it's a minimal piece in the difference between what we have. And in many of our accounts, we're going in jointly, working very closely with AWS on these, because again, this is joint. If you're an AWS seller, this is just part of the bag that you have and you get credit for it just like anything else that you would have sell of the Amazons. So this is the important thing that I wanted to address. And this is why we asked IBM to sponsor talking to you.

We had Roger Primo on a couple of weeks ago. He's a GM and strategist over at IBM. And one of the questions that I asked him was about consistency of experience across hybrid cloud. IBM can be arguably called the first hybrid cloud company. The enterprise architect to me wants a consistent experience across the public cloud, the private cloud, my IBM Z16, my IBM Z system, as well as I want to be able to consume the recently announced generative AI system from AWS from within my containerized application platforms.

I want all of that. And I don't wanna manage the platform. Talk to me about the control plane. Me and you have talked about the control plane for years. We've predicted the control plane, the data center control plane is going to be in the cloud and managed by the cloud providers and our trusted vendors. Talk to me about that maturity and journey of where Red Hat is and giving me a turnkey managed OpenShift experience, regardless of where the containers or workloads are running.

Yeah, Keith, it's a great thing. And I'd say we're making progress on the journey. When I dial back earlier into my career and you think about outsourcing was kind of my mess for less. And the problem that most customers had is they had a disconnect between, boy, I need changes, I need to respond to our customers, we need to make changes. And if we push that off to someone else to manage, we couldn't move at the pace that business actually needed to.

Cloud, the promise of cloud was, heck, I should be able to start new things and move faster. But we've reached a point where, Keith, I don't know, you've got an actual physical data center and you've bought stuff in the clouds. I believe if you were to configure a server, you've got more options actually go into a cloud provider than I had if I went to my favorite vendor of choice in the data center. So that paradox of choice is really tough to manage.

So, right, how do we manage these things? How do I make sure that I have architecture control, but I don't necessarily want my people running around doing things. So one of the biggest differences between kind of OpenShift in the data center and OpenShift in the cloud when we do something like ROSA is that management component. So what we offer with ROSA is our team, site reliability engineers, they actually manage that for you. So the full cluster. So I'm not responsible for what I would typically call, you know, the plumbing and electrical, the scaling and, you know, patching of operating systems in some of the, you know, much more than the traditional cloud shared responsibility model, where in the cloud shared responsibility model, the cloud's responsible for, you know, compute and some of those things.

But, you know, you're really responsible for all of the worker nodes, configuring them, identity management, tagging and security. Using ROSA, we take care of that full Kubernetes cluster for you so that you really only need to worry more about the application itself. Now, you specifically asked Keith about a managed, you know, across all environments. So from a Red Hat standpoint, we have a managed offering in the public cloud in the data center. That's where we turn to our partners. So the likes of IBM and many of our other GSI partners, they can actually, you know, deliver as a service managed offering for those.

But from a Red Hat standpoint, doing whether, you know, traditional X86 or Z or P, that is a customer, you manage it. And by the way, that's one of the differences we find out if customers start with OpenShift. And often, as I said, they'll configure things the way they want exactly. When they go to the public cloud, if they want that exact configuration, they can deploy that. Or if they're willing to work with us, understand where the boundaries are, and be able to let go of those geek knobs a little bit, Keith, we can actually take that off of their plate so that they should have less people having to manage the infrastructure, and they can push them on, you know, the app and security issues that the business needs and the updates that they need, rather than maintaining that platform.

Allow us to do that. And again, we work with lots of our partners to be able to offer managed OpenShift in other environments. You know, Stu, one of these days, we're going to get IBM to sponsor the CTO Advisor showing this nuance and where you should go with a GSI like IBM, go with a ROSA versus rolling your own. But I really do appreciate you stopping by the state of the cloud, whether we're talking about just what IBM offers as a big umbrella or what Red Hat offers as a focused offering has been an amazing journey for the past few years.

We're accelerating it, we're getting closer to this vision of turnkey, having our cloud management or data center stack control plane managed by a cloud and delivered wherever we want. We've, I think, given a great conversation standard of where the standard is today. For those attending KubeCon, I think Red Hat is going to be there if we publish this in time, right? Yeah, Keith, you know, whether we publish in time, we are there. We are one of the top level sponsors, which we typically are for KubeCon.

I will be there. I'm sitting on a panel talking about platform engineering for the press and media. We've got a big booth. We've got like 41 speaking sessions. I can send you the link for, there's a whole event page that Red Hat has. So yeah, definitely a very big presence and mostly from our European staff because Red Hat, we have a very large European presence. So super excited to be there. Even have one of the members of my team that's local that I will get to see in person.

So super excited for that. Sorry, you're not joining us this time, Keith. I know you've been a couple of times and KubeCon is one of my favorite community shows. Yeah, this is actually the first in-person KubeCon that I've missed in probably four or five years. I've kind of snuck into the cloud native community through the enterprise door. I've been traditionally one of those suits that showed up to the show. For those of you that want to find out more about the CTO advisor, you can follow us on the web, the CTO advisor.

Both me and Stu are pretty active on Twitter. He's at Stu, S-T-U on Twitter. He's the old- What's that say, Keith? Twitter, Twitter. I seem to remember using Twitter back in previous years. Yeah, there's a lot of years ago. Every now and again. Every now and again. If you add him, chances are he'll respond. My DMs are open because unfortunately I still have to be on Twitter. Please go back, rate the podcast, give us feedback.

We are doing more of these sponsored podcasts. Are you getting value from them? I want to know. Until then, talk to you next CTO advisor podcast.