>>From around the globe. It's the cube with coverage of coop con and cloud native con North America, 2020 virtual brought to you by red hat, the cloud native computing foundation and ecosystem partners. >>Hey, welcome back, everybody Jeffrey here with the cube coming to you from our Palo Alto studios today with our ongoing coverage of coupon cloud native con North America, 2020. It's not really North America, it's virtual like everything else, but you know that the European show earlier in the summer, and this is the, this is the late fall show. So we're excited to welcome in our very next two guests. Uh, first joining us from Madrid. Spain is Miguel Perez, Kaleena. He is a principal product manager from red hat, Miguel. Great to see you. >>Good to see you happy to be in the cube. >>Yes. Great. Well welcome. And joining us from North Carolina is rich Sharples. He is a senior director, product management of red hat. Rich. Great to see you. >>Yeah, likewise, thanks for inviting me again. >>So we're talking about Java today and before we kind of jump into it, you know, in preparing for this rich, I saw an interview that you did, I think earlier about halfway through the year, uh, celebrating the 25th anniversary of Java and talking about the 25th anniversary Java. And before we kind of get into the future, I think it's worthwhile to take a look back at, you know, kind of where Java came from and how it's lasted for 25 years of such an important enterprise, you know, kind of application framework, because we always hear jokes about people looking for COBOL programmers or, you know, all these old language programmers, because they have some old system that's that needs a little assist. What's special about Java. Why are we 25 years into it? And you guys are still excited about Java yesterday, today and in the future. >>Yeah. And I should add that, um, in terms of languages, uh, twenty-five is actually still pretty young. Java's, uh, kind of middle aged, I guess. Um, you know, things like CC plus bus rrr you're 45, 50 years old Python, I think is about the same as Java in terms of years. So, you know, the languages do tend to move at a, um, at a, they do tend to stick around, uh, uh, a bit, well what's made Java really, really important for enterprises building business critical applications is it started off with a very large ecosystem of big vendors supporting it. Um, it was open in a sense from the very start and it's remained open as in open source and an open community as well. So that's really, really helped, um, you know, keep the language innovating and moving along and attracting new developers. And, um, it's, it's still a fairly modern language in terms of some of the new features it's advancing with the industry taking on new kinds of workloads and new kinds of per program paradigms as well. So, you know, it's, it's evolved very well and has a huge base out somewhere between 11 and 13 million developers still use it as a primary development language in professional settings. Yeah. >>What struck me about what you said though in that interview was kind of the evolution and how Java has been able to continue to adapt based on kind of what the new frameworks are. So whether it was early days in a machine, like you talked about being in a set top box, or, you know, kind of really lightweight kind of almost IOT applications then to be calming, you know, this really a great application to deliver enterprise applications via a web browser and that, you know, and it continues to morph and change and adapt over time. I thought that was pretty interesting given the vast change in the way applications are delivered today versus what they were 25 years ago. >>Yeah, absolutely. It's, you know, the very early days were around embedded devices, uh, intelligent toasters and, you know, whatever. Um, and, and then where it really, really took off was, but the building supporting big backend systems, big transactional workloads, whether you're a bank or an airline you're running both the scale, but also running really, really complex transactional systems that were business critical. And that's that's for the last, you know, 15 years has been, um, where it's, it's really shown building backend, um, systems. Now, as we kind of move forward, you know, the idea of, uh, um, like server side, uh, server side application versus a front end is kind of changed. You know, now we're talking microservices, we're talking about running in containers. So really the focus of where we run Java and the kinds of applications we're building with Java as this has radically changed. And as such the language has to change as well, which is, you know, one, I'm pretty excited to talk about caucus today. >>So let's, let's jump into it and talk about corcus cause the other big trend, you know, along with, with, with obviously, uh, uh, browsers being great enterprise applications, delivery vehicles is this thing called containers, right? And, and specifically more recently Kubernetes is the one that's grabbing all the attention and grabbing all the, all the momentum. Um, so I wonder Miguel, if you could talk about, you know, kind of as, as the popularity of containerized applications and containerized to everything right, containerized storage, or you even talked about containerizing networking, troll, how that's impacted, uh, what you guys are doing and the impact of Java, uh, and making it work with kind of a containerized Kubernetes world. >>Well, what we found is that the paradigm of development has teeth. So we have this top up, uh, uh, paradigm that the people are following to be able to do the best with containers, to the best with Kubernetes on the, this has worked quite fine in Greenfield on for, for many cases has been a way to develop applications faster, to be able to obtain variably salts. And the thing is that for many, uh, users, for many companies that we work with, uh, they also want to bring some of their stuff that the applications that are currently are running into this world. And, uh, I mean, we, we walk especially a lot in helping these customers be able to adopt those obligations, but we try to do it, uh, as we say, the N pixie dust, you know, we really dig into the code, we'll review the code with modernize. The application will help their customer with that application. We provide the tools are open for anyone to be able to review it and to be able to take it. So we are moving away from Greenfield into brownfield and not a way we are evolving together to say we more precise, you know, all these Greenfield applications keep coming, but also the current applications want to be more organized. >>Right. Right. So it's pretty interesting. Cause that's always the big conversation. There's, it's, it's all fine. And good if you're just building something new, uh, to use the latest tools. But as you mentioned, there's a whole lot of conversation about application modernization and this is really an opportunity to apply some of these techniques to do that. So quirky. So I wonder if you just give, let's just jump into it. What is it at the highest level? Uh, what's it all about? What should people know? >>Yeah. So, so Corker says I'm reading an attempt by red hat to ensure Java is a first-class citizen in containerized environments, but building reactive applications, uh, cloud native applications, uh, functions, Java is an incredible piece of engineering. It does some incredible things. It sudden can self optimize. As it's running in line code, it can do some really amazing things the longer it runs, but in a containerized environment, you're likely not going to be running huge amounts of code. You'd likely be running microservices and your, your services are likely to have a kind of limited life cycle as we you're able to deploy more frequently or in a function environment where, you know, you've been bought once and then you're done, um, you know, during all those long, um, kind of, um, those optimizations over time, don't really, um, make a lot of sense. So what we can do is remove a lot of the, um, the weights of Java, a lot of the complexity of Java, and we can optimize for an environment where your code is maybe just running for a few microseconds as in the case of the function or something running in native, cause you scale up and scale down. >>So we move a lot of the op side. We move a lot of the, um, the, the efforts within the application, uh, to compile time, we pre compile all of your, of your config and initialization, so that doesn't have to happen in your, um, your, your, your runtime or your production environment. Um, and then we can optimize the code week. We can, we can remove that code. We can remove, you know, whole, uh, trees and class libraries and really slimmed down the memory footprint and radically, um, slim, the Maddie memory footprint, um, increase the startup time as well. So, you know, you have less downtime in your applications. Um, and we've recently done a S a study with ADC that shows some pretty stunning results compared to, you know, some existing frameworks. And, you know, we get, um, you know, sort of like, you know, overall cost savings of, you know, 60, 64%. >>Um, we can get eight times better density. You're running more in a, in a, in a cluster and, um, you know, reduction in memory up to 90% as well. So it's, these are significant changes now. That's all good, you know, saving, saving 60, 60% on your operational costs is significant. But what we find is that most organizations, they come for the performance and the optimizations, but what actually stay for is the speed of development. So I think, I think caucus real silver bullets is, um, the developer productivity, you know, for organizations, the cost of development is still one of the major costs. I mean, the operational costs, the hosting costs a significant, but development costs, time to market will always be top of mind for organizations that are trying to move faster than the competition. And I think that's really where, um, um, caucus special and coupled in, uh, in, uh, OpenShift or Coobernetti's environment really, really does shine. Yeah, >>It's pretty interesting. So people can go to corcus.io and see a lot of the statistics that you just referenced in terms of memory usage and speed and, and whole bunch of stuff. But what struck me when I went to the site was that was this big, uh, uh, two words that jumped out developer joy. And it's funny that you talked on that just now about really, um, the benefits that come to the developer directly to make them happier. I mean, really calling out their joy. So they're more productive and ultimately that's what you said. That's where the great value is in terms of speed of deployment, happy developers, and productive developers. You know, Miguel, you get your, you get down into the weeds of this stuff. Again, the presentations on your LinkedIn, everyone needs to go look and you talk a lot about at migration and you lot talk a lot about app modernization. So without going through all 120 some odd slides that I think you have, which is good, phenomenal information, what are some of the top things that people need to think about and consider both for app modernization as well as at migration? >>Um, that's, that's, that's an interesting question. Uh, the thing is that, um, the tolling is important on the current code is, and the thing is that normally when, when we started migration project, we tried to find architects in the applications to be able to find patterns. You know, you find parents is much easier because, uh, once you solve one part on the same part on can be solved in a very similar way. So this is one of the parts of that. We focus a lot, but before getting to that point, it's very important how you stop, you know, so the assessment phase is, is very important to be able to review well, what is the status of the applications, the context of the applications. And with that, I mean, things like, for example, the requirements that they have, there's the maintenance that they take in their resiliency and so on. >>So you have to prepare very well, the project by starting with a good assessment, you have to check which applications makes more, make more sense to start with and see which, how to group them together by similarities. And then you can start with the project that saying, okay, let's go for these set of applications that make more sense that are more likely to be containerized because of the way we are developing them because of the dependencies that they have because of the resiliency that is already embedded into them and so on. So that, that the methodology is important. And we normally, for example, when we, when we help partners do a application migration, one of the things that we stress is that this is the methodology that we follow and in the website for my vision, totally for application, you can find also, um, methodology, uh, part that, uh, could help, uh, people understand, okay, these, these are the stages that we normally follow to be successful with migrating applications. >>Yeah. Let go. You don't, we're not friends. We don't hang out a lot, but if we did, you would know I never ever recommend PowerPoint for anything. So, so the fact that I'm calling out your PowerPoint actually means something. Cause I think it's the worst application ever built, but you got some tremendous, tremendous information in there and people do need to go in and look, and again, it's all from your LinkedIn work, but I wanted to shift gears a little bit, right? We're at CubeCon cloud native con. Um, obviously it's virtual is 2020. That's the way the world today. But I just curious to get your guys' take on, on what does this, uh, event mean for you obviously really active, open source community, you know, red hat has a long open-source history. Um, what does CubeCon cloud native con mean for you guys? What do you hope to get out of it? What should people hope to, uh, to learn from red hat? >>Yeah, we, um, yeah, we're, we're buying your DNA. We're very, very collaborative. Uh, we, we love to learn from our customers, users of the technologies, um, in the communities that we support. Um, speaking as a, you know, we're both product guys, there's nothing better than getting with, um, people that actually use the products, um, in anger, in real life, whether they're products are upstream technologies, learning, learning, what they're doing, understanding where, um, some of the gaps are there's. Um, yeah, we just couldn't do our jobs without engaging with developers, users in these kind of conferences. Yeah. A lot of the, um, love interest we've seen with coworkers is, is in the community, you know, um, like I'd been part of many, many successful open source projects, um, um, over red hat. And it's great when your customers, you know, like, uh, Vodafone, Greece or Carrefour in Spain are openly publicly talking about how good your technology is, what they're using it for. And that's really good. So it's just nothing, there's no alternative that, you know, whether it be virtual virtually or physically sitting down with, uh, with users of your technology, >>How about you, Miguel? What are you hoping to get out of, uh, out of the show this year? >>Um, we are working a lot with, on Kubernetes in red hat, on, uh, as part of the community, of course. And, um, I mean, there are so many new stuff that is coming around, Kubernetes that, uh, it's mostly about it, about all the capabilities that were arming, especially for example, several lists, you know, several lessons, there is an important topic with crackers, because for example, as you make the application stopped so much faster and react so much faster, you could have known of them running and just waiting for an event to happen, which saves a lot of resources and makes us super efficient. So this is one of the topics, for example, that we wanted to cover in this edition, you know, how we are implementing serverless with Kubernetes and OpenShift and many other things like pipelines. Like, I don't know, we just had quite a visit in the, uh, uh, video, uh, life of what is coming up. I see for the six. And I recommend people to take a look at it, to get everything that's new because there's a lot. Yeah, >>Yeah. You guys are technical people. You've been doing this for a long time. Why is Kubernetes so special? W Y Y you know, there's been containers in the past, right. And we've seen other kind of branded open source projects that got a lot of momentum, but Kubernetes just seems to be blowing everybody out of the out of its path. Why, what should people know about Kubernetes that aren't necessarily developers? >>Yeah, there's really nothing interesting about a single container or a single microservice, right? That's not, that's not the kind of environment that, um, real organizations live in. They live in organizations where they're going to have hundreds of services, um, who just containers and you need a technology to orchestrate and manage that in that complex environment. And Kubernete's has just quickly become the, the district per standard. Um, yeah, folks are red hat jumped on my very, very early, um, I mean, one of the advantages around her have is where we're embedded with developers and open source communities. We often have a pretty good, it gives us a pretty good crystal ball. So we're often quick to jump on the emerging technologies that are coming out of open source. And that's exactly what happened with Cubanetis. It was clear. It was, um, you're going to be sophisticated for our, you know, most, um, most sophisticated customers running at scale. Um, but, but also, you know, great for development environments as well. So it really a good fit for, uh, where we were headed and, you know, just very, very quickly became the fact that standard. And you, you just gotta go with the de facto standard. Right, right. >>Right. Well, the another thing that you mentioned rich in that other interview that I was watching is it came up the conversation in terms of managing open source projects. And at some point, you know, they kind of start, and then, you know, I think this one, if I go to corcus and look at the bottom of the page sponsored by red hat, but you talked about, you know, at some point, do you move it over to a foundation, um, you know, and kind of what are the things that kind of drive that process, that decision, um, and, you know, I would imagine that part of it has to do with popularity and scale, is that something, you know, potentially down the road, how do you think that you said you've been in lots of open source projects, when does it move from, you know, kind of single point of origin to more of a foundational support? >>Yeah. I mean, in fact the foundation's owner was necessary. Um, you know, when you have a, yeah. If you, if you have a, an open, very open project with, um, um, clear, clear rules for collaboration and kind of the encouragement or others to collaborate and be able to, you know, um, move the project and, you know, the foundation as low as necessarily what we've seen, I've been part of the no GS world where, you know, the, the community reached Belden to keep no GS moving forward. Um, we had to go from a, what we call a benevolent dictator for life, somebody who's well-intentioned, but, um, yeah, we're on stone, the technology, so a foundation, which is much more inclusive and, um, you know, greater collaboration and you can move even quicker. So, you know, um, I think what's required is, is open governance for open source projects and where that doesn't happen. You know, maybe a foundation is, is the right way forward. Right, right now with, with caucus, um, you know, the, the non red hat developers seem pretty happy with the way they can get, uh, get engaged and contribute. Um, but if we get to a point where the community is demanding a foundation and we'll absolutely consider it, that's the best project we'll do. >>So, so we're, we're coming to the end of our time. I want to give you each the last word, really with two questions, one again, you know, just kind of a summary of, of, uh, of CubeCon cloud, native con, you know, what should people be looking for, uh, find you, and, and, and I don't know if you guys are sponsoring any sessions, I'm sure there's a lot of great content. If you want to highlight one or two things. And then most importantly, as we turn the calendars, we come to the end of 2020, uh, thankfully, um, as you look ahead to 2021, you know, what are some of your priorities, uh, as, as we get ready to turn the turn, the calendar, and Miguel let's start with you. >>So, um, I mean, we have been working very hard this year on the migration, took it for applications to help her every user that is using Java to bring the two containers. You know, whether it is data IE or these crackers, but we're putting like a lot of effort in crackers. And now we are bringing in new rules. And, uh, by the, by December, we expect to have the new version of the migration looking for applications that is going to include the, all the bulls to help developers bring their, their code to the Java code, to, to carcass. And, uh, on this, this is the main goal for us right now. We are moving forward to the next year to include more, more capabilities in that project. Everything's up on site. You can go to the conveyor, uh, project and ticket on, uh, on the up capabilities for the assessment phase. So whenever any partner, any, any of our consultants are working on, on migration or anyone that would like to go and try it themselves on adopted, would like to do these migrations to the cloud native world, uh, will feel comfortable with, with this tool. So that is our main goal in, in my, in my team. >>All right. And how about you rich? >>Yeah, I think we're going to see this, um, um, kind of syllabus solidification kind of web of, um, microservices. Um, you know, if you like hate that, I'm sorry, but I'm just going to next generation microservice. There's going to be, as Miguel mentioned, is gonna be based around, um, uh, native, um, advancing, um, serverless functions. I think that's really the, the, the ideal architecture, the building March services, um, on, on Coobernetti's and caucus plays really, really well there. Um, I think there's, there's a, there's a kind of backlog of projects, um, within organizations that, um, you know, hopefully next year, everything really does start to crank up. And I think, um, yeah, I think a lot of the migration that Miguel has talked about is going to be, is going to rise in terms of importance. So app modernization, taking those existing applications, maybe taking aspects of those and, you know, doing some kind of decomposition in some microservices using caucus and a native, I think we'll see a lot of that. So I think we'll see a real drive around both the kind of Greenfield, um, applications, uh, you know, this next generation of microservices, as well as pulling those existing applications forward into these new environments, don't give an answers. So it's going to be excellent. >>Awesome. Well, thank you both for taking a few minutes with us and sharing the story of corcus, uh, and have a great show. Great to see you and a really good the conversation. All right. He's Miguel, he's rich. I'm Jeff. You're watching the cubes ongoing coverage of CubeCon cloud native con 2020 North America. Virtual. Thanks for watching. We'll see you next time.

>> From around the globe, it's The Cube, with digital coverage of Red Hat Summit 2020, brought to you by Red Hat. >> Hi, and welcome back, I'm Stu Miniman, this is The Cube's coverage of the Red Hat 2020, bringing you guests from Red Hat and 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 longtime Red Hatter, but first time, on The Cube, 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 of the middleware space. But in, Quarkus so, I personally was not familiar with Quarkus. Obviously we know, god, I believe someone told me once that there's like, 2 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. What a huge impact that has had on the industry. Linux and Java are two of the, you know, major movers of how we, you know, build an, you know, deal with application today, so give us a little bit of a framework as to what Quarkus is, you know, why it was created. >> Yeah, so it's no secret that as organizations and developers move to this kind of new styled 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 coolest things it does, assumes that it's going to be a long running application, it can do this cool dynamic class loading and dynamic optimization as the application runs. Those things are pretty impressive, but they're also fairly, very heavyweight. And in our kind of ephemeral environments, 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 radical features that you don't necessarily get any benefit from them. So, you know, where we're really trying to lay focus is ensure developers to continue to use Quarkus, it's still the, you know, the dominant language for enterprise development. You still get the benefits of these new architectures, so ensuring that Java continues to be you know, performant and efficient in these new you know, constrained environments. >> Okay, excellent, so we're not calling it cloud native Java though, right Rich? But we are bringing, if I heard right, Java for things like containers Kubernetes, I even heard functions as a service so, we're talking to server lists of you know, open shift server lists 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 Quarkus different from some of the alternatives that are out there. >> Really, the goal is to introduce those that stayed the same. It's not a different language, it's not a fork. It is Java, you're writing Java applications, essentially in the same way you used to write them. And you may be using Microsoft still 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 wipers 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 the whole ecosystem with us, with Quarkus, so those things can run well, in a you know, container or service environment as well. And that's super important because the real benefit here is any organizations face the choice of I want to develop cloud native, I want to develop functions, but I've got this huge investment in Java in terms of skills and you know, tools and tool trains and I don't want to go learn a new language, just because I need to you know, take advantage of things new environments so we're essentially giving developers their cake and allowing them to eat it. We are trying to provide the best of both worlds. Stick with the language you already know and you know, have lots of experience with, and still be able to get the benefits of running in our 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 does the same thing. As you mentioned, things you know, spin up really fast and they don't stay on nearly as long. You know, god, you mentioned functions as a service, often we're measuring things in milliseconds, so everything genomes, 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 considerations >> Yes, so, yeah, absolutely so, Red has taken on the ramp and ensuring that this ecosystem moves with us. We do a lot of 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'd normally start off once only, like loading classes and you know, building kind of memory data around, all the kind of reading configurations all of the things applications do once and only once. Why do it another time? Why not build that into the component time, you're going to do it once but take it out of your runtime environment completely, so there are many ways where we're having to kind of rethink the way you know, applications run. We have to do a reset on what job was built for this environment of long running applications where, if the application took 10 minutes to load up all the stage area and classes and config, it didn't really matter, because it's not going to run for 36 months. You got to do a resale on those design decisions and think very very differently and given with our deep experience with containers and you know, working on things like native, serverless and on deep, deep roots in Java, we were able to do that and really think differently. So, Quarkus takes a lot of that kind of work away from developers they don't have to think too much about it. And by and large, what they can do is focus on their applications and their micro services and read all of that wiring and optimization for them. And hopefully deliver some you know, real significant improvements both in development productivity, but also the kind of runtime resource utilization as well to really lower costs. >> Okay, and Rich, what's is 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 you know, the term serverless is so polarizing is because from a developer standpoint I don't 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 you know, 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 just on RHEL and therefore everywhere the RHEL lives it's there? Or, help me understand kind of what that underlying you know, substrate is. >> Yeah, right now our focus is RHEL x86, 'cause that's kind of the dominant platform in a cloud. It is just Java, some have that natural kind of portability and you know, as other architectures become important, we can certainly look at those as well. The reason why the underlying machine architecture is important, is because one of the options you have with Quarkus is actually the ability to compile everything down to a binary executable, right? That may give you some additional footprint reduction and performance enhancements. And also if we compile down to native, we do need to think about the underlying operating system and the architecture. But by and large, as a developer you really don't have to care. Just like to you don't have to care with Java today. You also have the option with Quarkus, 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. Under you know, different reasons for compiling down a native, this is running on a traditional JDK, different optimizations, different trade-offs that you'd like to make. >> All right, so Rich, an open source project here, can you tell us a little bit about you know, who's contributed to this, you know, what general adoption is this, and, you know, where are we with the solution today. Is it today ready for production environments? >> Yeah, it's getting close to production ready, yeah, we'll be making this Germany available and during Summit 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 REHL VM, we leverage open JDK, we leverage all our frameworks and library, the developer that are familiar with, we just have to optimize them for Quarkus, so, yeah, much of this is not brand new technology. The existing technology that has that kind of maturity and tolling support. So yeah, we're confident it's production ready. One of the early stages of the development of Quarkus, was to use some of Red Hats own products as goody picks. Actually, you know, optimize those products for containerized environments by rebuilding them on top of Quarkus and that gave us obviously a lot of insight into the general readiness, yeah, the whole kind of eating around and dog food principle. In terms of the organizations in investing Quarkus, you know, we have this kind of have old addedge, we often use at Red Hat, which is you know, if you want to, if you want to move quickly, go alone. If you want to go far, then go with others. We're at a stage, where we've been developing Quarkus very, very rapidly and that's mostly been a Red Hat effort. We've certainly got some help from the mothership IBM and I expect that to be an increase overtime and we're now in a point where we have a Germany available product coming up and we're ready to really kind of expand the ecosystem. So, we're looking for you, whether you're a framework provider, you've written a framework for Java and you want to have that Quarkus provider, ensure that runs really well and partly the kind of growing ecosystem around Quarkus, we're looking for that, we're for, you know, cloud providers to you know, take this technology and see how it runs in other environments and give us feedback. So, yeah, definitely looking to expand that ecosystem of contributors, so we can really turn this into kind of the facto technology for the cloud. >> So, Richard, stop back for us for a second, you've got a long history with Java. You know, why in 2020 is you know, 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 you know, organizations are faced with a tough choice. That they stick with the language that they know and love, which is Java, the language, the relevant applications for the last decade and not be able to take the best advantage of cloud and native or serverless environment. Whereas if they go and learn a new language, Datalog or No.js and you know, kind of hunt around and trying to see if that has the same kind of ecosystem and support. So, we want give organizations a better choice, which is you can stick with a language you already know and love and you have skills and the resources, yeah, you can still take advantage of these new environments and that's you know, I'm mean, fundaments the problem we're trying to solve for your customers. That twice open source projects are, they live or die, depending on, they really do scratch an itch, you know, fulfill a need with real developments. I'm going to think we've certainly from the adoption and interest we've seen with Quarkus, we really do think we've found a very real problem to solve. >> Yeah, Rich, before we wrap up, I just want to give you the opportunity, you know, how is your teams doing, I think you know, Red Hat's making a real concerted effort to make you know, an 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, full on the community all together, but, you know, the community is so important and you know, the network of people that, you know, built not only you know, technologies but also careers and you know, relationships, so, give us a insight as to how your teams doing, everybody in these challenging times. >> I think this is another good example of where open source really does show it's resilience. Open source projects are simply very, very distributed. No open source projects rely on an office being open, so your word distributed team 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 them in the task, you have 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 leaderships, that's Red Hat and IMB. They're very clear that they've got people and families before revenue and that's good to know. Everybody's you know continuing as they can to you know, ensure that we have you know, great technology out there 'cause like I said there's real demand here that needs to filled and we're going to continue doing that. So, yeah, everybody's kind of holding up pretty well, so, let's just see how long this thing goes but again, I do think 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 the ecosystem in costumers 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 the changes we were 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 computers, so, we're going to do, we're playing through a bunch of you know, kind of very quick webinars, you know, quick bye what it takes, you know, interesting features, we're going to do some virtual hackathons as well, so you can actually get people with time and talk with some experts. We have platform for doing that. So, we're pretty excited, we, you know, again with the incident, we can reach a lot of developers very easily. Actually far more than we could at a live even like Summit, so, we're going to make the best of it and try to get at to as many developers as we can with Quarkus 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 your Rich, you know, Quarkus, I have to imagine that the Quark, the subatomic particle, you know, came into the naming there. Is there some connection with that? I guess why the name to the project? >> Yeah, I mean that's pretty much it, you know, the Quarkus you know, kind of. (mumbles) Arguably the smallest fundamental particle. >> And can we find something smaller? >> Well, there potentially is 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 meant to mean small and the us bit, the US bit. I'd like to think there was a really good big meaning around that. The meaning is that we understand, that trying to do any kind of brand leadership or trademark protection on a well know server like Quark, is it possible? So, we had to add something to Quark and Quarkus kind of sounded cool. >> All right, Rich Sharples, pleasure to catch up with you, congrats on the progress for Quarkus, definitely looking forward to watching it's progression in the future. >> Thanks, great talking to you. >> All right, I'm Stu Minneman. Lot's more coverage here at Red Hat Summit 2020. Thank you as always for watching The Cube. (gentle music)