>>mhm Yes, Welcome back to the cubes coverage of red hat summit 2021 virtual, which we were in person this year but we're still remote. We still got the Covid coming around the corner. Soon to be in post. Covid got a great guest here, Clayton Coleman architect that red hat cuba love and I've been on many times expanded role again this year. More cloud, more cloud action. Great, great to see you. Thanks for coming on. >>It's a pleasure >>to be here. So great to see you were just riffing before we came on camera about distributed computing uh 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 had some and we're gonna get into that, but I want to just get into the hard news and the real big, 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 open shift managed offerings which has grown now to include um the redhead open shift service on amazon to complement our as your redhead open shift service. Um that means that we have um along with our partnership on IBM cloud and open ship dedicated on both a W S and G C P. We now have um managed open shift on all of the major clouds. And along with that we are bringing in and introducing the first, I think really the first step what we see as uh huh growing and involving the hybrid cloud ecosystem on top of open shift and there's many different ways to slice that, but it's about bringing capabilities on top of open shift 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 open shift. And the broader, open source ecosystem is do what makes all of us safer, more, uh, more productive and able to deliver business value? >>Yeah. And that's a great steak you guys put in the ground. Um, 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 know, you support AWS as your and I B M and G C P, but native offerings. >>We do not have a native offering on GCPD offered the same service. And this is actually interesting as we've evolved our approach. You know, everyone, when we talk about hybrid, Hybrid is, um, you know, dealing with the realities of the computing world, We live in, um, working with each of the major clouds, trying to deliver the best immigration possible in a way that drives that consistency across those environments. And so actually are open shift dedicated on AWS service gave us the inspiration 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 have 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, um, where you run your applications, um, 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 um of open shift since the beginning. >>Yeah. And thanks for clarifying, I appreciate that because the manage serves on GCB rest or native. Um let me ask about the application services because Jeff Barr from AWS posted a few weeks ago amazon celebrated their 15th birthday. They're still teenagers uh relatively speaking. But one comment he made that he that was interesting to me. And this applies kind of this cloud native megatrend happening is he says the A. P. I. S 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 A PS and these integrations? Because without solid integration all these services could break down and certainly the open source, more and more people are coding. So take me through how you guys look at these applications services because many people are predicting more service is going to be on boarding faster than ever before. >>It's interesting. So um for us working across multiple cloud environments, there are many similarities in those mps, but for every similarity there is a difference and those differences are actually what dr costs and drive complexity when you're integrating. Um and I think a lot of the role of this is, you know, the 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. You know, everybody is a participant in that. But then you look at the broad swath of developer and operator ecosystem and it's the communities of people who paper over those differences, who write run books and build um you know, the policies and who build the experience and the automation. Um not just in individual products or an individual clouds, but across the open source ecosystem. Whether it's technologies like answerable or Terror form, whether it's best practices websites around running kubernetes, um every every part of the community is really involved in driving up uh driving consistency, um driving predictability and driving reliability and what we try to do is actually work within those constraints um to take the ecosystem and to push it a little bit further. So the A. P. I. S. May be similar, but over time those differences can trip you up. And a lot of what I think we talked about where the industry is going, where 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 A. P. R. S are the same and 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 to bring service, we don't want to build artificial walls between those. I mean, 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, you know, an open source project doesn't support this vendor, 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 ap is closer together and the consistency underneath them is both a community and a vendor. And uh for red hat, it's part of what we do is a core mission is trying to make sure that that consistency is actually real. You don't have to worry about those details when you're ignoring them. >>That's a great point. Before I get into some architectural impact, I want to get your thoughts on um, the, this trends going on, Everyone jumps on the bandwagon. You know, you say, oh yeah, I gotta, I want a data cloud, you know, everything is like the new, you know, they saw Snowflake Apollo, I gotta have some, I got some of that data, You've got streaming data services, you've got data services and native into the, these platforms. But a lot of these companies think it's just, you're just gonna get a data cloud, just, it's so easy. Um, they might try something and then they get stuck with it or they have to re factor, >>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 architect in that? >>There's a really interesting mindset is, uh, you know, we deal with this a lot. Everyone I talked to, you know, I've been with red hat for 10 years now in an open shift. All 10 years of that. We've gone through a bunch of transformations. Um, and every time I talked 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. Um, 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. Um, that ties into digital transformation. Ci CD is another big trend where it's an obvious wind. But depending on where you jumped on the bandwagon, depending on when you adopted, you're going to make a bunch of different trade offs. And that, that process is how do we improve the ability to keep all of the old stuff moving forward as well? And so open api is open standards are a big part of that, but equally it's understanding the trade offs that you're going to make and clearly communicating those so with data lakes. Um, there was kind of the 1st and 2nd iterations of data lakes, there was the uh, in the early days these capabilities were knew they were based around open source software. Um, a lot of the Hadoop and big data ecosystem, you know, 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 input and the output of that basically let us into the next phase, which I think is the second phase of data leak, which is we have this data are tools are so much better because of that first phase that the investments we made the first time around, we're going to 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, you call it using their innovation tokens. You need to make the bets on big technologies that 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, um, it wasn't always obvious that it was going to pay off to the degree that um, customers would need. >>So I gotta ask you on the real time applications side of it, that's been a big trend, certainly in cloud. But as you look at hybrid hybrid cloud environments, for instance, streaming data has been a big issue. Uh any updates there from you on your managed service? >>That's right. So one of we have to manage services um that are both closely aligned three managed services that are closely aligned with data in three different ways. And so um one of them is redhead open shift streams for Apache Kafka, which is managed cloud service that focuses on bringing that streaming data and letting you run it across multiple environments. And I think that, you know, we get to the heart of what's the purpose of uh managed services is to reduce operational overhead and to take responsibilities that allow users to focus on the things that actually matter for them. So for us, um managed open shift 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 were 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 open ship dedicated, which means once you've brought the data and you need to expose it back out to other applications in the environment, you can build those applications on open shift, you can leverage the capabilities of open shift api management to expose them more easily, both to end customers or to other applications. And then our third services redhead open shift data science. Um and that is a, an integration that makes it easy for data scientists in a kubernetes environment. On open shift, they easily bring together the data to make, to analyze it and to help route it is 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 longer term strategy. >>You know, all the customer checkboxes 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, Gardner told 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 all those things come into play right now. The innovation focuses on operations and day to operations, becoming much more specific. When people say, hey, I've done some lift and shift, I've done some Greenfield born in the cloud now, it's like, whoa, this stuff, 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 gotta have a unified experience. So these are the hot areas right this year, I would say, you know, that day to operate has 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 that challenges their opportunities, they're really trying to architect, you know, the foundation that building to be um future proof, they don't want to get screwed over when they have, they realize they made a decision, they weren't thinking about day to operation 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 um, this is probably one of the hardest questions I think I could get asked, which is uh 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, when the time is right within the business, um 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 um that consistent environment through open shift bringing capabilities, our connection to open source and making sure that there's an open ecosystem where um community members, users vendors can all work together to um find solutions that work for them because there's not, there's no way to solve for all of computing. It's just impossible. I think that is kind of our that's our development process and that's what helps make that accidental complexity of all that self away over time. But in the essential complexity data is tied the location, data has gravity data. Lakes are a great example of because data has gravity. The more data that you bring together, the bigger the scale the tools you can bring, you can invest in more specialized tools. I've almost do 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 um with conflict management technologies, whether that's kubernetes and deploying it in multiple sites in multiple locations and open shift, bringing consistency so that you can run the apps the same way. But even further than that is concentrating, mhm. More of what would have typically been a specialist 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? Um I think of, you know, some people might call this um you know, the ultimate integration problem, which is we're going to have all of this stuff and 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 coupon talk coming up this coupon, 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 as 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 open shift 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 uh in one geographic region and you didn't move services closer to that well, those services I 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 gotta have that flexibility in place. And so those obstructions are really, and to >>your point about the building blocks where you've got to factor in those building blocks, because you're gonna need to understand the latency impact, that's going to impact how you're gonna handle the compute piece, that's gonna handle all these things are coming into play. So, again, if you're mindful of the building blocks, just as a cloud concept, um, then you're okay. >>We hear this a lot. Actually, there's real challenges in the, the ecosystem of uh, we see a lot of the problems of I want to help someone automate and improved, but the more balkanize, 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 um, you know, 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 emerged from open source. What can we do to grow defacto standards around multi cloud and application movement and application interconnect I think is a very, it's already happening and what can we do to accelerate it? That's it. >>Well, I think you bring up a really good point. This is probably a follow up, maybe a clubhouse talk or you guys will do a separate session on this. But I've been riffing on this idea of uh, today's silos, tomorrow's component, right, or module. If most people don't realize that these silos can be problematic if not thought through. So you have to kill the silos to bring in kind of an open police. 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 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 gonna get really stuck >>and there's going to be more and more pre existing stuff I think, you know, uh even the data lake for every day to lake, there is a huge problem of how to get data into the data lake or taking existing applications that came from the previous data link. And so there's a, there's a natural evolutionary process where let's focus on the mechanisms that actually move that day to get that data flowing. Um, I think we're still in the early phases of thinking about huge amounts of applications. Microservices or you know, 10 years old in the sense of it being a fairly common industry talking point before that we have 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 sas 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 point is you can keep your silos, we just want to have great integration in and out of >>those. Exactly, they don't have to you have to break down the silos. So again, it's a 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 can paddle with that, you apply the new building blocks, you're classified. >>It sounds so that's so simple, doesn't it? It does. And you know, of course it'll take us 10 years to get there. And uh, you know, after cloud native will be will be galactic native or something like that. You know, there's always going to be a new uh concept that we need to work in. I think the key concepts we're really going after our everyone is trying to run resilient and reliable services and the clouds give us in the clouds take it away. They give us those opportunities to have some of those building blocks like location of geographic hardware resources, but they will always be data that 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 cannot, it doesn't make a lot of sense in a single cluster or single machine or a single location world the moment you start to talk about, Well I have my data lake. Well what are the ways my data leg can fail? How do we look at your complex web of interdependencies 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, 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's distributed computing. And again, I love the space where galactic cloud, you got SpaceX? Where's Cloud X? I mean, you know, space is the next frontier. You know, you've got all kinds of action happening in space. Great space reference there. Clayton, Great insight. Thanks for coming on. Uh, Clayton Coleman architect at red Hat. Clayton, Thanks for coming on. >>Pretty pleasure. >>Always. Great chat. I'm talking under the hood. What's going on in red hats? New managed cloud service portfolio? Again, the world's getting complex, abstract away. The complexities with software Inter operate integrate. That's the key formula with the cloud building blocks. I'm john ferry with the cube. Thanks for watching. Yeah.