 From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon North America 2020 virtual, brought to you by Red Hat, the CloudNative Computing Foundation, and Ecosystem Partners. Hey, welcome back everybody. Jeff Frick here with theCUBE, coming to you from our Palo Alto studios today with our ongoing coverage of KubeCon, CloudNativeCon 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 late fall show. So we're excited to welcome in our very next two guests. First joining us from Madrid, Spain is Miguel Perez Colina. He is the principal product manager from Red Hat. Miguel, great to see you. Great to see you, happy to be in theCUBE. Yes, great, well welcome. And joining us from North Carolina is Rich Sharples. He is the senior director, product management of Red Hat. Rich, great to see you. Yeah, likewise, thanks for inviting me again. Absolutely. So we're talking about Java today, and before we kind of jump into it, and preparing for this, Rich, I saw an interview that you did, I think earlier, about halfway through the year, celebrating the 25th anniversary of Java, and talking about the 25th anniversary of Java. Before we kind of get into the future, I think it's worthwhile to take a look back at kind of where Java came from, and how it's lasted for 25 years is such an important enterprise kind of application framework, because we always hear jokes about people looking for cobalt programmers, or all these old language programmers, because they have some old system 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, I should add that in terms of languages, 25 is actually still pretty young. Java's kind of middle-aged, I guess. Things like CC++, or 45, 50 years old. Python, I think, is about the same as Java in terms of years. So languages do tend to stick around a fair 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. It was open in a sense from the very start, and it's remained open as an open source and an open community as well. So that's really, really helped keep the language innovating and moving along and attracting new developers. And it's still a fairly modern language in terms of some of the new features. It's re-advancing with the industry, taking on new kinds of workloads and new kinds of pro-program paradigms as well. So it's evolved very well and has a huge base. It has somewhere between 11 and 13 million developers still using it as their primary development language in professional settings. What struck me about what you said, though, in that interview was kind of the evolution in 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 kind of really lightweight, kind of almost IoT applications, then to be coming this really great application to deliver enterprise applications via a web browser, 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. The very early days were around embedded devices, intelligent toasters and whatever. And then where it really, really took off was for 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 for the last 15 years has been where it's really shown, building backend systems. Now, as we kind of move forward, the idea of a server-side application versus a front-end is kind of changed. 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 has radically changed. And as such, the language has to change as well, which is why I'm pretty excited to talk about Quarkus today. Yeah, so let's jump into it and talk about Quarkus because the other big trend along with obviously browsers being great enterprise applications, delivery vehicles, is this thing called containers, right? And specifically more recently, Kubernetes is the one that's grabbing all the attention and grabbing all the momentum. So I wonder, Miguel, if you could talk about it kind of as the popularity of containerized applications and containerized to everything, right? Containerized storage, I've even talked about containerized networking control, how that's impacted what you guys are doing and the impact of Java and making it work with kind of a containerized Kubernetes world. Well, what we found is that the paradigm of development has changed. So we have this sort of factor up paradigm that the people are following to be able to do the best with containers to the best with Kubernetes. And this has worked quite fine in Greenfield and for many cases it's been a way to develop applications faster to be able to obtain better results. And the thing is that for many users, for many companies that we work with, they also want to bring some of their stuff that the applications that are currently running into this world. And we work especially a lot in helping these customers be able to adapt those applications. But we try to do it, as we say it, the no pixie dust, we really dig into the code, we review the code, we modernize the application, we help the customer modernize the application, we provide the tools that are open for anyone to be able to review it and to be able to check it. So we are moving away from Greenfield into Brownfield and not away, we are evolving together to say we more precise, all these Greenfield applications keep coming but also the current applications want to be modernized. Right, right. So it's pretty interesting because that's always the big conversation. It's all fine and good if you're just building something new 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 Quarkus, I wonder if you just give, let's just jump into it. What is it at the highest level? What's it all about? What should people know? Yeah, so Quarkus is really an attempt by Red Hat to ensure Java is a first class citizen in containerized environments for building reactive applications, cloud native applications functions. Java is an incredible piece of engineering. It does some incredible things. It can self-optimize as it's running. It can inline 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're likely to be running microservices. And your services are likely to have a kind of limited lifecycle as you're able to deploy more frequently for in a function environment where you invoke once and then you're done. Doing all those long kind of optimizations over time don't really make a lot of sense. So what we can do is remove a lot of the weight 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 a function or something running in native as you scale up and scale down. So we move a lot of the optimize, we move a lot of the efforts within the application to compile time. We pre-compile all of your config and initialization. So that doesn't have to happen in your runtime or your production environment. And then we can optimize the code. We can remove dead code. We can remove whole trees of class libraries and really slim down the memory footprint and radically slim the memory footprint, increase the startup time as well. So you have less dead time in your applications. And we've recently done a study with IDC that shows some pretty stunning results compared to some existing frameworks. We get up to like overall cost savings of 60 to 64%. We can get eight times better density, running more in a cluster and reduction in memory up to 90% as well. So these are significant changes. Now, that's all good. Saving 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 they actually stay for is the speed of development. So I think Cork is real silver bullet is the developer productivity. For organizations, the cost of development is still one of the major costs. I mean, the operational costs, the hosting costs are 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 Cork is, especially when coupled in an open shift or Kubernetes environment really, really does shine. Yeah, it's pretty interesting. So people can go to corkist.io and see a lot of the statistics that you just referenced in terms of memory usage and speed and a whole bunch of stuff. But what struck me when I went to the site was this big two words that jumped out, developer joy. And it's funny that you talked on that just now about really 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 down into the weeds of this stuff. Again, the presentations on your LinkedIn, everyone needs to go look when you talk a lot about app migration and you 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 app migration? That's our interesting question. The thing is that the tooling is important and the current code is important. And the thing is that normally when we start a migration project, we try to find archetypes in the applications to be able to find patterns. You find patterns is much easier because once you solve one pattern, the same pattern can be solved in a very similar way. So this is one of the parts that we focus a lot but before getting to that point, it's very important on how you start. So the assessment phase is very important to be able to review 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, the maintenance that they're taking, 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 make more sense to start with and see how to group them together by similarities. And then you can start with the project that's saying, okay, let's go for this 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 the methodology is important. And we normally, for example, when we help partners do application migration, one of the things that we stress is, this is the methodology that we follow. And in the website for migration to application, you can find also a methodology part that could help people understand, okay, these are the stages that we normally follow to be successful with migrating applications. Yeah, and Miguel, 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 the fact that I'm calling out your PowerPoint, I actually mean something because I think it's the worst application ever built, but you got some tremendous information in there and people do need to go in and look. And again, it's all from your LinkedIn. But I want to shift gears a little bit, right? We're at KubeCon CloudNativeCon. Obviously, it's virtual, it's 2020, that's the way of the world today. But I'm just curious to get your guys take on what does this event mean for you? Obviously, really active open source community. Red Hat has a long open source history. What does KubeCon CloudNativeCon mean for you guys? What do you hope to get out of it? What should people hope to learn from Red Hat? Yeah, we're by DNA, we're very, very collaborative. We love to learn from our customers, users of the technologies in the community we support. Speaking as a, we're both product guys, there's nothing better than getting with people actually use the products in anger in real life, whether they're products or upstream technologies, learning what they're doing, understanding where some of the gaps are. There's, we just couldn't do our jobs without engaging with developers, users in these kind of conferences. Yeah, a lot of the interests we've seen with caucus is in the community. I've been part of many, many successful open source projects over at Red Hat. And it's great when your customers, like 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 to, whether it be virtual, virtually or physically sitting down with the users of your technology. How about you, Miguel? What are you hoping to get out of the show this year? We are working a lot on Kubernetes in Red Hat and as part of the community, of course. And I mean, there are so many new stuff that is coming around Kubernetes that it's mostly about it, about all the capabilities that we're adding, especially for example, serverless. Serverless is an important topic with caucus because for example, as you make the application start so much faster and react so much faster, you could have none of them running and just waiting for an event to happen which saves a lot of resources and makes you super efficient. So this is one of the topics for example that we wanted to cover in this edition, how we are implementing serverless with Kubernetes and OpenShift and many other things like pipelines, like I don't know. We just recorded recently a video live on what is coming on OpenShift 4.6 and I recommend people to take a look at it to get everything that's new because there's a lot for that to be for me. You guys are technical people. You've been doing this for a long time. Why is Kubernetes so special? Why, 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 its path. Why, what should people know about Kubernetes that aren't necessarily developers? Why do they need to pay attention? There's really nothing interesting about a single container or a single microservice, right? That's not the kind of environment that real organizations live in. They live in organizations where they're going to have hundreds of services, hundreds of containers. And you need a technology to orchestrate and manage that complex environment. And Kubernetes has just quickly become the de facto standard. Folks at Red Hat jumped on very, very early. I mean, one of the advantages Red Hat has is 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 emerging technologies that are coming out of open source. And that's exactly what happened with Kubernetes. It was clear it was going to be sophisticated for our most sophisticated customers running at scale, but also great for development environments as well. So really a good fit for where we were headed. And just very, very quickly became de facto standard. And you just got to go with the de facto standard, right? Right, right. Well, another thing that you mentioned, Rich, and 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 Quarkus 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? You know, kind of what are the things that kind of drive that process, that decision? And, you know, I would imagine that part of it has to do with popularity and scales. That's something, you know, potentially down the road. How do you think of 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 approach? Yeah, I mean, foundations on it was necessary. You know, when you have a, you know, if you have an open, a very open project with clear rules for collaboration and you know, kind of that encouragement for others to collaborate and be able to, you know, move the project, then, you know, a foundation isn't always necessary. What we've seen, I've been part of the Node.js world where, you know, the community refelt that to keep Node.js moving forward, we had to go from a, what we call a benevolent dictator for life, somebody who's well-intentioned, but, you know, we want to own the technology to a foundation, which is much more inclusive and, you know, greater collaboration and you can move even quicker. So, you know, I think what's required is open governance for open source projects and where that doesn't happen, you know, maybe a foundation is the right way forward. Right now, with Quarkus, you know, the non-Red Hat developers seem pretty happy with the way they can get engaged and contribute. But if we get to a point where the community is demanding a foundation, and yet we'll absolutely consider it, that's the best the project will do. That's great. So, 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 KubeCon, CloudNativeCon, you know, what should people be looking for, find you, 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, as we come to the end of 2020, thankfully, as you look ahead to 2021, you know, what are some of your priorities as we get ready to turn the calendar? Miguel, let's start with you. So, I mean, we have been working very hard this year on the Migration Toolkit for Applications to help every user that is using Java to bring it to containers, you know, whether it is JEE or it is Quarkus. But we're putting like a lot of effort in Quarkus. And we are bringing new rules. And by December, we expect to have the new version of the Migration Toolkit for Applications that is going to include all the rules to help developers bring their code to, the Java code to Quarkus. And this is the main goal for us right now. We are moving forward to the next year to include more capabilities in that project, everything so far as you can go to the conveyor project and check it and add capabilities for the assessment phase. So whenever any partner, any of our RELHA consultants are working on migration or anyone that would like to go and try it themselves and adopt it, would like to do these migrations to the cloud native world, would feel comfortable with this tool. So that is our main goal in my team. All right. And how about you, Rich? Yeah, I think we're going to see this kind of solidification of kind of web, of Microsoft services, 2.0, if you like. I hate that, I'm sorry. But this kind of next generation Microsoft services is going to be, as Miguel mentioned, is going to be based around native, eventing, serverless functions. I think that's really the ideal architecture for building Microsoft services on Kubernetes and corpus plays really, really well there. I think there's a kind of backlog of projects within organizations that hopefully next year everything really does start to crank up. And I think a lot of the migration that Miguel's 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 doing some kind of decomposition into Microsoft services using corpus and native. I think we'll see a lot of that. So I think we'll see a real drive around both the kind of green field applications, this next generation of Microsoft services, as well as pulling those existing applications forward into these new environments like Kubernetes. So it's going to be pretty exciting. Awesome. Well, thank you both for taking a few minutes with us and sharing the story of corpus and have a great show. Great to see you and really enjoyed the conversation. Thanks a lot. All right, he's Miguel, he's Rich. I'm Jeff, you're watching theCUBE's ongoing coverage of KubeCon CloudNativeCon 2020 North America virtual. Thanks for watching. See you next time.