 From around the globe, it's theCUBE with digital coverage of Red Hat Summit 2020 brought to you by Red Hat. Hi, and welcome back. I'm Stu Miniman. This is theCUBE's coverage of a Red Hat Summit 2020 bringing you guests from Red Hat, their partner ecosystem, practitioners, where they are around the globe, bringing to them this digital event. And while we wish we could all be together in person, we'll just be together apart for 2020. Happy to welcome to the program a long time Red Hatter first time on theCUBE, Rich Sharples who's the senior director of product management inside Red Hat. Rich, thank you so much for joining us. Yeah, thanks for the invitation, great to be here. All right, so the topic we're going to talk about today is something you've got a long background in the middleware space, but it's a Quarkis. So I personally was not familiar with Quarkis. Obviously, I believe some Red Hatter told me once there's like two million open source projects out there. So I believe I can be forgiven for not having every one of them memorized there. But of course anybody in our community is going to know Java and what a huge impact that has had on the industry. I think, you know, clinics and Java too are the major movers of how we build you know, deal with application today. So give us a little bit of a framework as to what Quarkis is, you know, why it was created. Yeah, so it's no secret that as organizations and developers move to this kind of new style cloud native development, developing applications running in containers or in a kind of serverless environment that Java is not necessarily the best fit. Java does many incredible things. It's an amazing field of engineering, but many of the cool things it does assumes it's going to be a long running application that can do all this cool dynamic class loading and dynamic optimization as the application runs. Those things are pretty impressive, but they're also fairly heavyweight. And in a kind of ephemeral environment, whether containers or functions of service, you don't have long running applications and you can't make use of those things. So in a Java environment, you pay for those really cool features that you don't necessarily get any benefit from them. So, you know, what we're really trying to do with Quarkis is ensure developers can continue to use Quarkis. It's still the dominant language for enterprise development. You still get the benefits of these new architectures. So ensuring that Java continues to be performant and efficient in these new constrained environments. Okay, excellent. So we're not calling it cloud native Java though. Right, Rich? But we are bringing, if I heard to write Java for things like containers, Kubernetes, I even heard functions of the service that we're talking to serverless. Of course, you know, open shift serverless, something that's being talked about this week. So help us understand, you know, if Java was long in the tooth, you know, what stays the same? What's different? How have people been managing and, you know, building applications in this environment? Because obviously, you know, we've been dealing with containers for a number of years now. So what have they been doing so far? And, you know, why is Quarkis different from some of the alternatives that are out there? Yeah, and really the goal is to ensure it does stay the same. It's not a different language. It's not a fork. It is Java. You write your Java applications, essentially the same way you used to write them. You may be using microservices or functions, so slight difference in terms of design. But it's, you know, we want to ensure that you can bring your favorite frameworks and libraries with you as well. When you're accessing databases or message brokers, we want to ensure you can still use those technologies. So we're trying to bring a whole ecosystem with us with Quarkis so those things can run well in a container or for a service environment as well. And that's super important because the real benefit here is that many organizations face the choice of, I want to develop cloud native. I want to develop functions. But I got this huge investment in Java in terms of skills and tools and tool chains. And I don't want to go learn a new language just because I need to take advantage of these new environments. So we're essentially giving developers their cake and allowing them to eat it. So we're trying to provide the best of both worlds. Stick with the language you already know and you have lots of experience with. You'll still be able to get the benefits of running in a containerized environment. Okay, what are some of the challenges here? So, you know, from an infrastructure standpoint, my background is, you know, virtualization broke a lot of pieces and containerization did the same thing. As you mentioned, things, you know, spin up really fast and they don't stay on nearly as long. You know, you mentioned functions in the service often we're measuring things in milliseconds. So everything changes to how I understand what's up, how do I manage it, how do I monitor it, all of those pieces. So, you know, I understand you're saying we take the skill set and what we know, but, you know, there's got to be some on-ramp here and some consideration for... Yeah, so, yeah, absolutely. So Red Hat's taken on the on-ramp. We're ensuring that this ecosystem moves with us. We do a lot of the hard work within Quarkus, so developers don't have to. We do some very, very clever stuff that very few organizations would be able to do because they don't have the depth of knowledge of the Java virtual machine that we do. We're able to take a lot of things that you would normally do at startup once only, like loading classes and, you know, building kind of your memory data array, all of your reading configurations, all of the things applications do once and only once. Why do it at runtime? Why not build that into the compile time? You're going to do it once, but take it out of your runtime environment completely. So, yeah, in many ways, we're having to kind of rethink the way, you know, applications run. We have to kind of do a reset on... Well, Java was built for this environment of long running applications where if the application took 10 minutes to load up all this data and classes and config, it didn't really matter because it was going to run for 36 months. Going to do a reset on those design decisions and think very, very differently. And given with our deep experience with containers and working on things like native, serverless, and our deep, deep roots in Java, we're able to do that and really think differently. So, Corkus takes a lot of that kind of work away from developers, I think too much about it. And by and large, what it can do is focus on their applications and their microservices and we do all of that wiring and optimization for them and hopefully deliver some real significant improvements both in developer productivity, but also the kind of runtime resource utilization as well to really lower costs. Okay, and Rich, it's great. That's been really the nirvana when you talk about developers is they don't want to have to think about some of that underlying, you know, gobbledygook. That was why the term serverless is so polarizing is because from a developer standpoint, I don't want to think about this, but everybody screams, but there are servers and there is networking and there's, you know, things underneath that I need to think about. So, what is the underlying assumption here? We talked about containers, Kubernetes, functions as a service. What integration is done there? Does this live across? Is it kind of like, you know, does it sit just on rel and therefore everywhere that rel lives, it's there or help me understand kind of what that underlying, you know, substrate is? Yeah, right now our focus is rel x86 because that's the kind of dominant platform in the cloud. It is just Java. So we have that natural kind of portability and, you know, as other architectures become important, we can certainly look at those as well. But the reason why the underlying machine architecture is important is because one of the options you have with caucus is actually to be able to compile everything down to a binary executable, right? That may give you some additional footprint reduction and performance enhancements. And obviously if we compile down to native, we do need to think about the underlying operating system and architecture. But by and large, as a developer, you really don't have to care just like you don't have to care with Java today. You also have the option with caucus to run on conventional JVM, open JDK is our preference. And if you can run on open JDK, then you can pretty much run anywhere. And there are different reasons for compiling down to native versus running on a traditional JDK, different optimizations, different trade-offs you would likely make. All right. So Rich, an open source project here, can you tell us a little bit about who's contributed to this? What general adoption is this? And where are we with the solution today? Is it today ready for production environments? Yeah, it's getting close to production ready. We'll be making this generally available during summits. And many of the components we use are tried and tested. Again, we're not reinventing everything from the ground up. We leverage things like RALVM, we leverage open JDK, we leverage all the frameworks and libraries that developers are familiar with. We just have to optimize them for focus. So yeah, much of this is not brand new technology. The existing technology that has that kind of maturity and tooling support. So yeah, we're confident it's production ready. One of the early stages of the development of Corpus was to use some of Red Hat's own products as guinea pigs. Actually optimize those products for containerized environments by rebuilding them on top of Corpus. And that gave us obviously a lot of insight into the general readiness, yeah, the whole kind of eating your own dog food principle. In terms of the organizations investing in Corpus, we have this kind of old adage we often use at Red Hat, which is if you wanna move quickly, go alone. If you wanna go far, then go with others. We're at the stage where we've been developing Corpus very, very rapidly. And that's mostly been a Red Hat effort. We've certainly got some help from the mothership IDM. And I expect that to increase over time. And we're now at the point where we have a generally available product coming up and we're ready to really kind of expand the ecosystem. So we're looking for whether you're a framework provider, you've written a framework for Java and you wanna have that qualified and ensure that runs really well and part of the kind of growing ecosystem around Corpus, we're looking for that. We're looking for cloud providers to take this technology and see how it runs in their environments and give us feedback. So yeah, definitely looking to expand that ecosystem of contributors so we can really turn this into a kind of digital environment. You're really turn this into a kind of de facto technology for the cloud. Yeah, so Rich, step back for us for a second. You've got a long history with Java. Why in 2020 is Java still, I believe it's like number two on the language list there. Why is it so important today and why is moving forward to all of these cloud solutions so important for that ecosystem? Yeah, I think it comes down to, organizations are faced with a tough choice that they stick with the language they know and love which is Java, the language they've developed applications for the last decade and not be able to take the best advantage of a cloud native or a serverless environment or do they go learn a new language, Golang or Node.js and kind of hunt around and try and see if it has the same kind of ecosystem and support. So we wanna give organizations a better choice which is you can stick with a language you already know and love and you have the skills and the resources. Yeah, you can still take advantage of these new environments. And that's, I mean, fundamentally the problem we're trying to solve for our customers. That's why open source projects or they live or die depending on if they really do scratch and itch your full fill of need with real developers. And we think we've certainly from the adoption in the interest we've seen with cook as we really do think you found a very real problem to solve. Yeah, Rich, before we wrap up, just wanna give you the opportunity. You know, how's your teams doing? I think Red Hat's making a real concerted effort to take a appropriate tone for the event this week. Trying to make sure it's not, you know, some of the usual glam that we normally expect to see pulling the community all together. But, you know, the community is so important and, you know, the network of people that, you know, build not only, you know, technologies but careers and, you know, relationships. So it gives a little insight as to how your team's doing and responding in these challenging times. I think this is a good, another good example of where open source really does show its resilience. Open source projects are typically very, very distributed. No open source projects rely on an office being open. So, you know, we're a distributed team. We're all used to work using distributed tools across the world, different time zones. It's kind of natural for us. So we're kind of plugging on, you know, just as we have done in the past. You know, a few more dogs in the background and crying babies and, you know, we're all humans. We all tolerate that. We have great support from our leadership, both at Red Hat and IBM. You know, they're very clear that they put people and families before, you know, before revenue and that's good to know. Everybody's, you know, continuing as they can to ensure that we have, you know, great technology out there. Because like I say, there's a real demand here that needs to be filled and we're going to continue doing that. So, you know, everybody's kind of holding up pretty well. So let's just see how long this thing goes on. But again, I do think it's a, it is a valuable kind of lesson on the resilience of distributed teams and open source in particular. So, yeah. All right. Well, thank you for that, Rich. Just to bring it on home, as you said, the general availability of Quarkus, you know, is in front of us here, really expecting that the ecosystem and customers move. Give us a little bit of what we should be looking at going forward. What are some of the kind of maturity steps and what should we expect to see through the remainder of 2020? Yeah, it's going to be a pretty exciting year. I mean, given that the changes we've, we're all going through, we are going to try and come meet developers where they are, which is, you know, on their laptops and in front of their computer. So we're going to do a, we're playing to a bunch of, you know, kind of very quick webinars, you know, quick five minute takes on your interesting features. We're going to do some, some virtual hackathons as well. So you can actually get keyboard time and talk to some experts. We have a platform for doing that. So pretty excited. We, you know, again with the, with the internet, we can reach a lot of developers very easily. Actually, far more than we could at a live event like Summit. So we're going to, we're going to make the best of it and try and get out to as many developers as we can with focus. And, you know, hopefully they'll repay us by investing a little bit of time into it and giving us some feedback and, you know, trying some applications and, you know, see how it goes. All right. And, you know, final, final question for you, Rich, you know, Quarkus, I have to imagine that the Quark, the subatomic particle, you know, came into the naming there. Is there, there's some connection with that? You know, what, I guess, why the name for the project? Yeah. I mean, that's pretty much it. Yeah. The Quark is the, you know, kind of subatomic. Arguably, the smallest fundamental particle. And can we find something smaller? Well, the potentially something smaller, but that's kind of in the realm of quantum mechanics and physics, which I'm not an expert on. So, but yeah, it's, it's meant to mean small. And the, the US bit, the US bit, I'd like to think there was a really good deep meaning around that. The meaning is that we understand that trying to get any kind of brand leadership or trademark protection on a well-known term like Quark is impossible. So we had to add something to Quark. And Quark is kind of soundful. All right. Well, Rich Sharples, pleasure to catch up with you. Congrats on the progress for Quark is definitely look forward to watching its progression in the future. Thanks, great talking to you. All right. I'm Stu Miniman. Lots more coverage here at Red Hat Summit 2020. Thank you as always for watching The Cube.