 Welcome back to theCUBE's coverage of Red Hat Summit 2021 virtual, which we were in person this year, but we're still remote, we're still got the COVID coming around the corner soon to be in post COVID. Got a great guest here, Clayton Coleman, architect at Red Hat, CUBE alum, I've been on many times, expanded role again this year, more cloud, more cloud action. Clayton, great to see you. Thanks for coming on. It's a pleasure to be here. So great to see you. We were just riffing before we came on camera about distributed computing and the future of the internet, how it's all evolving, how much fun it is, how it's all changing, still the game is still the same, all that good stuff. But here at Red Hat Summit, and we're going to get into that, but I want to just get into the hard news and the real big opportunities here. You're announcing with Red Hat new managed cloud services portfolio. Take us through that. Sure, we're continuing to evolve our OpenShift managed offerings, which has grown now to include the Red Hat OpenShift service on Amazon to complement our Azure Red Hat OpenShift service. That means that we have, along with our partnership on IBM cloud and OpenShift dedicated on both AWS and GCP. We now have managed OpenShift on all of the major clouds. And along with that, we are bringing in and introducing the first, I think really the first step of what we see as growing and involving the hybrid cloud ecosystem on top of OpenShift. And there's many different ways to slice that, but it's about bringing capabilities on top of OpenShift in multiple environments and multiple clouds in ways that make developers and operation teams more productive. Because at the heart of it, that's our goal for OpenShift and the broader open source ecosystem is do what makes all of us safer, more productive and able to deliver business value. Yeah, and that's a great stake you guys put in the ground. And that's great messaging, great marketing, great value proposition. I want to dig into a little bit with you. I mean, you guys have, I think, the only native offering on all the clouds out there that I know of. Is that true? I mean, you guys have, it's not just, you support AWS, Azure and IBM and GCP, but native offerings? We do not have a native offering on GCP. Not yet. We offer the same service. And this is actually interesting as we've evolved our approach. Everyone, when we talk about hybrid, hybrid is dealing with the realities of the computing world we live in, working with each of the major clouds to try and deliver the best integration possible in a way that drives that consistency across those environments. And so actually our OpenShift dedicated on AWS service gave us the inspiration in a lot of the basic foundations for what became the integrated native service. And we've worked with Amazon very closely to make sure that that does the right thing for customers who've chosen Amazon. And likewise, we're trying to continue to deliver the best experience, the best operational reliability that we can so that the choice of where you run your cloud or where you run your applications matches the decisions you've already made and where your future investments are gonna be. So we want to be where customers are, but we also want to give you that consistency that has been a hallmark of OpenShift since the beginning. Yeah, and thanks for clarifying that, I appreciate that, it's because the managers on GCP rest are native. Let me ask you about the application services because Jeff Barr from AWS posted a few weeks ago, Amazon celebrated their 15th birthday, they're still teenagers, relatively speaking. But one comment he made that was interesting to me in the supplies, kind of this cloud native mega trend happening is, he says the APIs are basically the same. And this brings up the hybrid environment. You guys are always been into the API side of the management with the cloud services and supporting all that. As you guys look at this ecosystem in open source, how is the role of APIs and these integrations because without solid integration, all these services could break down and certainly with open source, more and more people are coding. So take me through how you guys look at these application services because many people are predicting more services going to be onboarding faster than ever before. It's interesting, so for us, working across multiple cloud environments, there are many similarities in those APIs, but for every similarity, there's a difference. And those differences are actually what drive cost and drive complexity when you're integrating. And I think a lot of the role of this is, it'd be irresponsible to talk about the role of an individual company in the computing ecosystem moving to cloud native because as many of these capabilities are unlocked by large cloud providers and transformations in the kinds of software that we run at scale, everybody is a participant in that. But then you look at the broad swath of the developer and the operator ecosystem and it's the communities of people who paper over those differences, who write runbooks and build the policies and who build the experience and the automation, not just in individual products or in individual clouds, but across the open source ecosystem, whether it's technologies like Ansible or Terraform, whether it's best practices websites around running Kubernetes. Every part of the community is really involved in driving consistency, driving predictability and driving reliability. And what we try to do is actually work within those constraints to take the ecosystem and to push it a little bit further. So the APIs may be similar, but over time those differences can trip you up. And a lot of what I think we talk about like where are the industries going, where we want to be is everyone ultimately is going to own some responsibility for keeping their services running and making sure that their applications and their businesses are successful. The best outcome would be that the APRs are the same and that they're open and that both the cloud providers and the open source ecosystem and vendors and partners who drive many of these open source communities are actually all working together to have the most consistent environment to make portability a true strength. But when someone does differentiate and has a true best of breed service, we don't want to build artificial walls between those. I mean, that's hybrid cloud is you're going to make choices that make sense for you. If we tell people that their choices don't work or they can't integrate or an open source project doesn't support this vendor or that vendor, we're actually leaving a lot of the complexity buried in those organizations. So I think this is a great time to, as we turn over for cloud native, looking at how we as much as possible try to drive those APIs closer together and the consistency underneath them is both a community and a vendor and for Red Hat it's part of what we do is our core mission is trying to make sure that that consistency is actually real and that you don't have to worry about those details when you're ignoring them. Yeah, that's a great point. Before I get into some architectural impacts I want to get your thoughts on this trends going on. Everyone jumps on the bandwagon. You see, oh yeah, I got it. I want a data cloud, you know, everything's like the new, you know, there's no snowflake, I got to have some, I got to have some of that data. You got streaming data services, you got data services and native into these platforms but a lot of these companies think it's just you, I'm just going to get a data cloud, just so easy. They might try something and then they get stuck with it or they have to refactor. How do you look at that as an architect when you have these new hot trends, like say a data cloud? How should customers be thinking about kicking the tires on services like that and how should they think holistically around architecting that? There's a really interesting mindset is, you know, we deal with this a lot. Everyone I talk to, you know, I've been with Red Hat for 10 years now, been on OpenShift all 10 years of that. We've gone through a bunch of transformations and every time I talk to, you know, I've talked to the same companies and organizations over the last 10 years, each point in their evolution, they're making decisions that are the right decision at the time. They're choosing a new capability. So platform as a service is a great example of a capability that allowed a lot of really large organizations to standardize. That ties into digital transformation. CICD is another big trend where it's an obvious win, but depending on where you jumped on the bandwagon, depending on when you adopted, you're gonna make a bunch of different trade-offs. And that process is, how do we improve the ability to keep all of the old stuff moving forward as well? And so open APIs, open standards are a big part of that. But equally, it's understanding the trade-offs that you're gonna make and clearly communicating those. So with data lakes, there was kind of the first and second iterations of data lakes, there was the, in the early days, these capabilities were new. They were based around open source software. A lot of the Hadoop and big data ecosystem started based on some of these key papers from Amazon and Google and others taking infrastructure ideas, bringing them to scale. We went through a whole evolution of that and the inputs and the output of that basically led us into the next phase, which I think is the second phase of data lake, which is we have this data, our tools are so much better because of that first phase that the investments we made the first time around, we're gonna have to pay another investment to make that transformation. And so I've actually, I never want to caution someone not to jump early, but it has to be the right jump and it has to be something that really gives you a competitive advantage. A lot of infrastructure technology is, you should make the choices that, you make one or two big bets and sometimes people say this, call it using their innovation tokens. You need to make the bets on big technologies that let you operate more effectively at scale. It is somewhat hard to predict that. I certainly say that I've missed quite a few of the exciting transformations in the field, just because it wasn't always obvious that it was going to pay off to the degree that customers would need. So I got to ask you on the real-time application side of it, that's been a big trend, certainly in the cloud, but as you look at hybrid, hybrid cloud environments, for instance, streaming data has been a big issue. Any updates there from you on your managed service? That's right. So one of, we have two managed services that are both closely aligned, three managed services that are closely aligned with data in three different ways. And so one of them is Red Hat OpenShift Streams for Apache Kafka, which is a managed cloud service that focuses on bringing that streaming data and letting you run it across multiple environments. And I think that we get to the heart of, what's the purpose of managed services? It's to reduce operational overhead and to take responsibilities that allow users to focus on the things that actually matter for them. So for us, managed or OpenShift Streams is really about the flow of data between applications in different environments, whether that's from the edge to an on-premise data center, whether it's an on-premise data center to the cloud and increasingly these services, which we're running in the public cloud, increasingly these services have elements that run in the public cloud, but also key elements that run close to where your applications are. And I think that bridge is actually really important for us, that's a key component of hybrid is connecting the different locations and different footprints. So for us, the focus is really, how do we get data moving to the right place? That complements our API management service, which is an add-on for OpenShift dedicated, which means once you've brought the data in, you need to expose it back out to other applications in the environment. You can build those applications on OpenShift, you can leverage the capabilities of OpenShift API management to expose them more easily, both to end customers or to other applications. And then our third service is Red Hat OpenShift Data Science. And that is an integration that makes it easy for data scientists in a Kubernetes environment on OpenShift to easily bring together the data to analyze it and to help route it as appropriate. So those three facets for us are pretty important. They can be used in many different ways, but that focus on the flow of data across these different environments is really a key part of our long-term strategy. You know, all the customer checkboxes are there, you mentioned earlier. I mean, I'll just summarize that that you said, you know, obviously value, faster application velocity, time to value. Those are like the checkboxes, you know, Gartner, all the analysts, check those. Lower complexity, oh, we do the heavy lifting, all cloud benefits. So that's all cool. Everyone kind of gets that. Everyone's been around cloud, knows DevOps, though those things come into play. Right now, the innovation focus is on operations and day two operations becoming much more specific when people say, hey, I've done some lift and shift. I've done some green field, born in the cloud. Now it's like, whoa, this stuff is kind of, I haven't seen this before as you start scaling. So this brings up that concept and then you add in multi-cloud and hybrid cloud, you've got to have a unified experience. So these are the hot areas right this year, I would say, you know that, I mean, day two operations have been around for a while, but this idea of unification around environments to be fully distributed for developers is huge. How do you architect for that? This is the number one question I get and I tease out when people are kind of talking about their environments, their challenges, their opportunities. They're really trying to architect, you know, the foundation, that building to be future proof. They don't want to get screwed over when they realize they made a decision. They weren't thinking about day two operations or they didn't think about the unified experience across clouds, across environments and services. This is huge. What's your take on this? So this is probably one of the hardest questions I think I could get asked, which is looking into the crystal ball, what are the aspects of today's environments that are accidental complexity? That's really just a result of the slow accretion of technologies and we all need to make bets when the time is right within the business and which parts of it are essential? What are the fundamental hard problems? And so on the accidental complexity side, for Red Hat, it's really about that consistent environment through OpenShift, bringing capabilities, our connection to open source and making sure that there's an open ecosystem where, you know, community members, users, vendors can all work together to find solutions that work for them because there's no way to solve for all of computing. It's just impossible. I think of that as kind of our, that's our development process and that's what helps make that accidental complexity evolve itself away over time. But in the essential complexity, data is tied to location, data has gravity, you know, data lakes are a great example of because data has gravity, the more data that you bring together, the bigger the scale of tools you can bring, you can invest in more specialized tools. I've almost viewed that as a specialization, centralization. There's a ton of centralization going on right now. At the same time that these new technologies are available to make it easier and easier, whether that's large scale automation with, you know, config management technologies, whether that's Kubernetes and deploying it in multiple sites in multiple locations and OpenShift bringing consistency so that you can run the apps the same way. But even further than that is, you know, concentrating more of what would have typically been a specialized problem, something that you build a one-off around in your organization to work through the problem. We're really getting to a point where pretty soon now there is a technology or a service for everyone. How do you get the data into that service? Out, how do you secure it? How do you glue it together? I think of, you know, some people might call this, you know, the ultimate integration problem, which is we're going to have all of this stuff in all of these places. What are the core concepts? Location, security, placement, topology, latency, where data resides, who's accessing that data? We think of these as kind of the building blocks of where we're going next. So for us, trying to make investments in, how do we make Kubernetes work better across lots of environments? I have a KubeCon talk coming up this KubeCon and it's really exciting for me to talk about where we're going with, you know, the evolution of Kubernetes, bringing the different pieces more closely together across multiple environments. But likewise, when we talk about our managed services, we've approached the strategy for managed services it's not just the service in isolation, it's how it connects to the other pieces. What can we learn in the community, in our services, working with users that benefits that connectivity? So I mentioned the OpenShift Streams connecting up environments. We'd really like to improve how applications connect across disparate environments. That's a fundamental property of, if you're going to have data in one geographic region and you need to move services closer to that, well, those services need to know and encode and have that behavior to get closer to where the data is. Whether it's one data lake or 10, we got to have that flexibility in place. And so those abstractions are really key. And to your point about the building blocks where you got to factor in those building blocks because you're going to need to understand the latency impact, that's going to impact how you're going to handle the compute piece that's going to handle all these things are coming into play. So again, if you're mindful of the building blocks, this is a cloud concept, then you're okay. We hear this a lot actually. There's real challenges in the ecosystem of, we see a lot of the problems of, I want to help someone automate and improve, but the more Balkanized, the more spread out, the more individual solutions are in play, it's harder for someone to bring their technology to bear to help solve the problem. So looking for ways that we can grease the skids to build the glue, I think open source works best when it's defining de facto solutions that everybody agrees on, that openness and the easy access is a key property that makes de facto standards emerge from open source. What can we do to grow de facto standards around multi-cloud and application movement and application interconnect? I think it's already happening. What can we do to accelerate it? That's a key area for us. Well, I think, Clayton, you bring up a really good point. This is probably a follow-up, maybe a clubhouse talk, or maybe you guys will do a separate session on this, but I've been riffing on this idea of, today's silos, tomorrow's component, right? Or module, and most people don't realize that these silos can be problematic if not thought through. So you don't have to kill the silos to bring in kind of an open place. So if you're open, not closed, you can leverage a monolith. Today's monolithic app or full stack could be tomorrow's building block unless you don't open up. So this is where an interesting design question comes in, which is, it's okay to have pre-existing stuff if you're open about it, but if you stay siloed, you're going to get really stuck. And there's going to be more and more pre-existing stuff. I think, even the data lake, for every data lake, there's a huge problem of how to get data into the data lake or taking existing applications that came from the previous data lake. And so there's a natural evolutionary process where let's focus on the mechanisms that actually move that data, get that data flowing. I think, we're still in the early phases of thinking about huge amounts of applications, microservices are 10 years old, in the sense of it being a fairly common industry talking point before that we had service-oriented architecture. But the difference now is that we're encouraging and building one developer, one team might run several services. They might use three or four different SaaS vendors. They might depend on five or 10 or 15 cloud services. Those integration points make them easier, but it's a new opportunity for us to say, well, what are the differences? To go back to the API point is you can keep your silos. We just want to have great integration in and out of those silos. Exactly, they don't have to, you don't have to break down the silos. So again, it's the tried and true formula, integration, interoperability, and abstracting away the complexity with some sort of new software abstraction layer. You bring that to play as long as you compatible with that, you apply the new building blocks, you're cloudified. Sounds so simple, doesn't it? It does, and of course it'll take us 10 years to get there. And after cloud native will be a galactic native or something like that. There's always going to be a new concept that we need to work in. I think the key concepts we're really going after are, everyone is trying to run resilient and reliable services and the clouds give us and the clouds take it away. They give us those opportunities to have some of those building blocks like location of geographic hardware resources. But there'll always be data that's spread. And again, you still have to apply those principles to the cloud to get the service guarantees that you need. I think there's a completely untapped area for helping software developers and software teams understand the actual availability and guarantees of the underlying environment. It's a property of the services you run with. If you're using a disk in a particular availability zone, that's a property of your application. I think there's a rich area that hasn't been mined yet of helping you understand what your effective service level goals, which of those can be met, which can't, it doesn't make a lot of sense in a single cluster or single machine or single location world, the moment you start to talk about, well, I have my data lake. Well, what are all the ways my data lake can fail? How do we look at your complex web or vendor dependencies and say, well, clearly if you lose this cloud provider, you're going to lose not just the things that you have running there, but these other dependencies. So there's a lot of, there's a lot of next steps that we're just learning what happens when a major cloud goes down for a day or a region of a cloud goes down for a day. You still have to design and work around those cases. It should be the computing. And again, I love the space reference. Galactic cloud, I mean, you got SpaceX. Where's cloud X? I mean, you know, space is the next frontier. You know, you got all kinds of action happening in space, great space reference there Clayton. Great insight. Thanks for coming on. Clayton Coleman, architect at Red Hat. Clayton, thanks for coming on. Thank you. It's been a pleasure. Always great chat. I'm talking under the hood, what's going on. And Red Hat's new managed cloud service portfolio. Again, the world's getting complex, abstract away the complexities with software, interoperate, integrate. That's the key formula with the cloud building blocks. I'm John Furrier with theCUBE. Thanks for watching.