>> live from Boston, Massachusetts. It's the queue covering your red. Have some twenty nineteen brought to you by bread. >> Welcome back to the Cube and our continuing coverage here. The Red had summit. This is six time around for us. Fifth time for stew minimum. So he still gets almost the perfect attendance. Goldmark. First time for me. So still have a lot of catching up to do. Stewed minimum. John Walls and Steve Spiker now joins us. He is the senior principal product manager. Developer tools, Red Hat and Steve. Good afternoon to you. Thanks for joining us. Thanks for having me. Let's just talk about first off development in general. I mean, there's a lot of give and take there, right? You're tryingto listen. What air? The needs. Where the deficiencies, Where can the improvements be made? But how much do you drive that on your side and how much do listen and respond to do what? You're here for. The community. >> Yeah, we do a little bit of both. And so a lot of it is responding to the community, and that's one of the areas that Red has really excelled. Is taking what's popular, what's working upstream and helping moving along make it a stable pot product or stable solution that developers can use. But we also have a certain agenda or certain platforms that we want to present. So we start from, like, various run times to actually contain our platforms. And so we want to have to kind of drive some of that initiatives on our own to help Dr Phil that because we hear it from customers a lot, it's like things you're doing are great. But like there's all these projects that need to come together sort of a product or unified experience. And so we spent a lot of our time China bring those things together as a way to help developers do those different task and also focus across like not just a job run times which we have a lot of job. >> So you might have it. You might have an in product in mind, right? And you realize that there might be a gap in terms of development, so you encourage or you try to bridged that gap a little bit. To get to that in product is that you're saying Yeah, >> so we do a lot of things to help build the pieces so that people can sometimes build their own experiences. They want. In the end, developers control kind of their own destiny, their own set of tools and a lot of customers have their own unique requirements, even like some tools they develop in house for loans, kind of regulatory reasons and other things. And so we have two, one build the pieces but also stitched the pieces together to help them have that kind of out of the box experience. Because some some customers really don't want to do that. They just want to say one kind of a turnkey solution. But then we may need to make some adjustments here and there. >> Yeah, but by Steve, you know, it's it's funny. It rhymes for me with what I saw, you know, fifteen, twenty years ago with Lennox. A lot of changes, a lot of pieces. I want to take advantage of it. But you know, a boy can somebody help me with this and you know that that's of course. Red hat rode that way pretty well right Today, cupidity is even more sprawling. There's so many different projects. There's so many pieces boy. It is complicated on DH. Therefore, how do we take advantage of that? What do I need to know? What can my platform a vendor do for me so that I don't have to manage that? Yeah, I love you. Spanned on that gives us a little bit of comparing trash. You know what's the same? What's different? Yeah, and so >> there's different aspects. I think the developer experience one thing that we talked about. It's like it just works sometimes. So, like it's if it's Cooper days. We've spent a lot time making sure it's hardened and works well. So you're not like debugging it, spending time on things that waist development time. Instead, That way, folks let on that. We also look at how we can build abstraction layers on top of that. So we built a Seelye tool called Rodeo, which is a developed, streamlined developer experience for open shift, and it's really focused on open ship. That way, that developer really just can focus on their application. They could deploy it, taken quickly, work on the changes before they commit to get, and then they can then also have a similar experience in the browser with things like Eclipse Jr Code or Dick workspaces are I got commercial offering behind that and that takes actually using the platform itself to do development, which is really, really super cool so that you can have an idea and the browser. You can also have the workspace like you're all your dependencies, like everything you would normally have on your laptop now don't need to worry about. It's now containerized and quickly spun up as a way to do development. And it's really a thing that enterprises really enjoy because they get like, quick satisfaction, like they get the stuff off the proprietary code off the death up there using their container platform, and it's building the same way they would build when they >> deployed my backgrounds on the infrastructure side. And the whole reason we have infrastructure to be able to run our abs and the Holy Grail we've wanted is you know, not not my developers. I shouldn't need to think about the stuff underneath, right? We looked at virtual ization. We look a container ization. You know, the nirvana of server lists, as they call it, is that I shouldn't have to think about that you know how we doing? Because at the end of the day, and I talked to users like Oh, jeez, well, I need to worry. What if something breaks? I need to understand the security for my environment. You know what you're seeing and talking to customers about it from there. Stop development. Yes, so they're able >> tto. It's like here's different stories, like Tool, Factor act. So it's like if you stay in certain parameters, you can have a lot of success, and that's still kind of true today. Survivalist kind of takes that to the next level, where you can really just have a predefined either a function spectacle o two and then things are really easy, and you don't have to worry about various aspects. But even though you look at the various vendors when you're working with different functions, it's even complex like, Oh, I need to provide the security on you. Make sure he sees a wire together. How do I log these things? How do I debugged when things across this mesh go wrong? And so it's like it's getting getting better. But there's still a lot of work to do to continue to improve that, and you will see a lot of innovation happening in that area, especially the work that we're working on. >> What kind of given take do you have in terms of what? Not only what is that community learning from you and the tools that you're providing them? But what are you getting back from that other than, you know, advancing a project or whatever, in terms of expertise, in terms of understanding, maybe a new wayto to build a different mouse trap. You know that someone comes up with an interesting idea. You're like, >> Wow, I >> didn't take that. Yeah, I think that's >> where, like the partnerships we've had with various companies before you go off starting out with Cooper Netease Anything in the Cave Native project last year. And that really took a different way of looking at serve elicit, moving it forward to say, Yeah, this is this is a different way. We thought about how we would do this on Cooper nowadays, even kind of like you abstract that ap I away. And it's like it's just to keep native of survivalists and then Karina use this kind of implementation detail behind that even and So that's really interesting to see things like that. And then also the recent work announcements with Microsoft and the azure functions where people like they maybe, you know, into the event sources there they would make sure that were close. That they're doing the functions are building, are running on Cooper Netease and our communities is is open shift. So it's really kind of completing the life cycle. >> So what if we could just step act, you know, if you talk about communities and open ships specifically, you've got you know, you've got partnership with Google and they've got the geeky and Antos stuff. You've got partnership for the Amazon, you know, they've got a ks, these things, they're not fully seamless and interoperable. It's, you know, I usually hear some confusion in the marketplace as to, you know, communities can run lots of places, but all the various you know, if you choose an implementation well, that your implementation and you should run that everywhere. Not I can't take all the various implementations and they're not inter swappable. So maybe you could help expand on that A little bit is toe, you know what's the goal? Where are we with this maturity here and you know, where do we need it to get? Because, you know, boy, it definitely is a little bit complicated. Least, you know, from the seat that I sit in Yeah. So it's >> somewhat complex, I think, goes back to your early days talking about letting she's like you would say you have an application that could run anywhere. They have Lenox this kind of truth. You know, there's always like certain security settings or packages you have enabled. That just holds true for elected Kuban aged world as well. You can lock it down a certain way. You could open it up a certain way. And so you see a lot of content that's delivered, assuming certain like privileges I have on the system and other systems that don't allow it. And so I think, more and more we see through the standardization something we could study in conformance testing. It really helps people like No, we want our getting in their hands. On an instance. It's really, you know, a full fledged communities or the part that they care about the most is working out well. And so I see that gave me the evil by also see tools that kind of abstract, even more so like a native, is a mentioned sort of survivalist workloads or functions themselves and then even house tool in kind of works. On top of that, like Natively understands the platform, that platform and those requirements to move those applications across the different systems because we have a lot of customers who run open ship communities as well as like many other good bearnaise kind of instances that so they have. We have this requirement to make sure we stay conforming, allow them to make sure the were closer portable, and it's an important part to move forward. So I still think there's a lot of work to be done toe to make these things a smoother processes. It's a lot of interesting things going on, though, >> So any interesting tens with workloads that's one of things we always look at is, you know, um, I just taking the old workloads. Am I doing them in a new place Or, you know, are there new new workloads and anything jumping out at you from customers that you talk to? >> Yes. So the way talk I know I mentioned several See multiple times a whole idea around this auto scaling. And Lou only losing your uplink your resources when you need to is a big deal. So we see a lot more and more of those kind of small function, single purpose things that are occurring up until, like, machine learning. Big data. It just continues. A GPU resource is we talked about running a V EMS and cos when I first heard this, like four years ago, I laughed out loud, and I really don't know. Their seriousness is something that happens. And, yeah, it's becoming mainstream now. So now kind of everything kind of fits within the current. You know, orchestrator of those workloads. >> You're not laughing anymore, right? No. No, because there's someone areas in which your concerns are certainly understandable securities. One of those a lot of attention being paid automation these days, right? And a lot of opportunity there. Is there one, or are there a couple areas where you say this is kind of where we have maybe greener pastures in terms of providing developers with really unusual tools are really more sophisticated, more complex or effective tools than than in any other area where you could use that kind of a boost. >> Yeah, I think there's a lot of things, but one thing that I see in this area is still a lot of fragmentation, like I'm not sure if I see you like this kind of a single way that things work, seeing a lot of great work, like with the Microsoft GS code tooling pieces. And I'm just saying that from an abstraction way to bring certain things together. Nice work going with Microsoft, the committee's plugging for there, and we were collaborating with them on that to extend it for some of the open shift use cases. But that just kind of moves, I think Mohr to beat the developers where they're at and will continue to invest across the different set of tools like I do, the more you keep up with these list of all these tools in the ecosystem. Everytime I present it, someone says, I don't know about those, but here's Maura that I didn't know about it, so this is just continues to grow and people continue to innovate, and I think it just think it's exciting because we continue Teo to evolve it. So I know think there's much in the way of kind of narrowing down on a smaller set of things. I think it's going to continue to expand in the sense. >> Speaking of expansion at Microsoft build yesterday, there was announcement of beloved Taquito K d a. A ce your functions with open shift. Help us parts a little bit. What, what that is. >> Yeah. So what that's about is really taking Thea's your functions and allowing those workloads to Warren on open ship because they're targeted towards Cuba. Netease and, of course, open ship those grenades distribution. So it allows that to happen. There's also that it's a unique auto scaler that kind of allows workload to be more surveillance run. So then also it's it ties into some of the azure event sorts of soul like thee. The message Cuba and bus Kafka that's there. And so now you can wire in yours your pieces, you can run it across here. Either hosted is your or on open shift with those of your function. >> Okay, just to clarify this is today separate from the K Native Initiative that you were talking about earlier. >> Yes, that's right. So this is touching on some of those points and the idea behind this project. This liken early preview announcer was like showing some progress, but they're looking in wiring in some of the chips. Start the kidney of serving pieces to allow running in those applications on open ship, but also the need of events sources. So you can take combination events and triggers your functions and do some of these exciting things. >> Can I ask you, you're doing sessions here at this show? You know how many of the people here you know, talking about survivalists and looking at that bleeding edge or there? There are other technologies that you find them spending a little bit more time in the tooling. It's >> a wide range. I'm really shocked by what some of the customers are like. Bleeding edge Kate made. It was like, Oh, you know, we saw whatever zero dot three release out there with this, and we'd really like this auto scaling capability because we're spending a lot of money running these applications that are not doing anything, So we like the better auto scaler that's out there. The others are really just like trying to understand more about container technology. I was just talking to Jen one early after a session. He's like, This is what we're trying to do. We need to contain your eyes applications. How do I build a CIA pipeline around it? So it's a It's a wide range of things you see here. Well, >> you certainly at the center of this inspiration, the innovation of the industry. I know you're an exciting place, and it's kind of something new every day for you. Probably right. >> Oh, it is. Yeah. Especially when these big conference and announcements come >> out. Gear up, right? Yeah, Exactly. Good job, Steve. Thank you for joining us here. We appreciate the time and wish you well down the road. >> Take me much. Enjoyed being on >> you, Steve Spiker from Red Hat. Joining this here for the first time on the Q. Good to have you, Steve. Good Have you with us as we continue our coverage from Boston. But the Red Hat Summit