S1E4: Red Hat Expert Insights: What is Quarkus, Anyway? And What Do I Need to know about Serverless Computing?
S1E4: Red Hat Expert Insights: What is Quarkus, Anyway? And What Do I Need to know about Serverless Computing?
Jim GarrettPrincipal Solution Architect - Red Hat
Speaker 1: ASCII Anything, a podcast presented by Moser Consulting. Join us every Wednesday to find out who from Moser's more than 200 resident experts we'll be talking to and what they're focused on at the moment, trends, security, set up. ASCII Anything and we'll give you our best answers.
Speaker 2: Hello, everyone. Welcome to another episode of ASCII Anything, presented by Moser Consulting. Today, we have an episode centered on Red Hat, more specifically on Quarkus, one of Red Hat's most formidable tools. It is worth noting that Moser Consulting is a Red Hat apex partner and in 2020, Moser was named Red Hat system integration partner of the year. With us today, we have Jim Garrett of Red Hat who will talk about what Quarkus is and what it could do for you or your organization. Jim works at Red Hat, the world's leading provider of open source software solutions. He is part of the North American channel solutions architecture group, responsible for helping customers solve the most difficult and challenging problems they face. He believes in using technology to empower others through open communication, sharing of knowledge and liberal use of open source. For the past 20 years, Red Hat's open source software development model has produced high performing, cost effective solutions. Red Hat's model mirrors the highly interconnected world we live in where ideas and information can be shared worldwide in seconds. Today, more than 90% of Fortune 500 companies rely on Red Hat. Red Hat offers the only fully open technology stack from operating system to middleware, storage to cloud and virtualization solutions. Red Hat also provides a variety of service, including award winning support, consulting and training. Jim has lots of past consulting experience in the fields of enterprise architecture, solution architecture and end to end implementation. He also has a solid management experience starting up new IT projects and engagements, program management, client relationship, team building and delivery with global multicultural teams. Jim, thank you very much for being with us today. We really appreciate your time. We really want to hear more about Quarkus. How are you today?
Jim Garrett: I'm doing great. Thanks. A real pleasure to be here with you and to have an opportunity to talk about Quarkus.
Speaker 2: That's phenomenal, Jim, and we really appreciate you taking the time here today to talk to us. Let's dive right in. Can you describe what Quarkus is?
Jim Garrett: For the common user, they need to understand that Quarkus is a full stack Kubernetes native Java framework made for Java virtual machines. It's optimized specifically for containers and enabling it to become an effective platform for serverless cloud and Kubernetes environments. In fact, from the outset, Quarkus was designed around a container first philosophy. And what this means is that Quarkus is optimized for low memory usage and fast startup times. When an application is compiled down to a native image, it starts much faster and it can run with a much smaller heap than the standard Java virtual machine. As much processing as possible is done at build time so your application will only contain the classes that are actually needed at run time. In a traditional model, all the classes that are required to perform the initial application deployment, hang around for the entire life of the application, even though they're only used once but with Quarkus, they're not even loaded into the production Java virtual machine. And what this does, is it results in less memory usage and faster startup time as all the metadata processing has already been done. All of this combined together makes Quarkus an ideal choice for containerized applications.
Speaker 2: Interesting. I was reading yesterday about what the name Quarkus means and I found something interesting that Quark means elementary particle and then us, somebody made a joke about us being the hardest thing in computer science, meaning us humans. I found that very interesting yesterday. Thanks for that answer. Next question, Jim, how did Quarkus come about? What motivation and goal was it developed?
Jim Garrett: Quarkus came about with two main goals. The first goal was to improve the developer experience when developing microservices. And the second was to make Java a language of choice for microservice and serverless architecture. And at its core, Quarkus is just an open source project that's sponsored by Red Hat, but it's also contributed to by several other organizations outside of Red Hat.
Speaker 2: Interesting. Let's dive a little bit deeper then, what are the strengths of Quarkus? I understand it combines a reactive and imperative development in the same application. How does that translate into a strength?
Jim Garrett: It's a good question. So one of the key strengths of Quarkus is that it helps you save money. In the past, every company bought the hardware they needed to run their applications so you spent money on acquiring it. However, today we don't buy hardware anymore, but we pay for its usage. We pay for CPU, we pay for RAM and basically the more CPU and RAM we need, the more we pay. The usage of CPU and RAM actually matters. Quarkus in its native mode helps you cut down that CPU usage by reducing the boot time and the time per requests. And it reduces the memory requirements by up to tenfold in comparison to what other traditional Java frameworks perform. You combine this with the serverless aspect of Quarkus and what it deliver is a solution that not only gets built when it's running, but it then goes to sleep and doesn't consume any resources. There's one other benefit to using Quarkus and that is what we call live reloading. This is something that other languages already have, but it's something fairly new to Java developers. With live reloading, what that means is it allows you to make a change in any file of your application without having to recompile and repackage it. Without live reloading for a change to be reflected in the running instance, you had to compile and package the entire application, stop the previous instance and restart the whole application. But with Quarkus and live reloading, you only need to save the change and the change is almost instantly reflected in the running instance. No compilation, no repackaging, no restart. And then last but not least and this kind of gets directed more to your question. Quarkus is also based on the well known specifications like JAX- RS, JPA, CDI, mean validation and micro profile. What this means is that everything you already know about using those tools can be used in Quarkus and the other way around is true also. Everything you learn about these specifications in Quarkus can then be used in other projects, not based on Quarkus. You really have a good advantage as you don't need to learn or investigate how to do things in each of the frameworks that you're already developing.
Speaker 2: Wow, that's very interesting to see how Quarkus works, not just in an active role, but also in that background, in that it allows Java developers just to start something, leave it right there and then the system kind of doesn't burn up your system itself. Speaking of those strengths, you mentioned a couple of times a microservices. How does Quarkus get applied to microservices, reactive applications, message driven microservices and serverless?
Jim Garrett: For years, the client server architecture had been the de facto standard to building applications. Though with the invention of the cloud, a major shift happens. The one model that rules them all age is over and in its place, a new range of applications and architecture styles has emerged and it impacts how code is written and how applications are deployed and executed. Quarkus has been designed with this new model in mind and it provides the first class support for these different paradigms. For example, the Quarkus development model morphs itself to adapt to the type of application you're developing. If you're exposing a simple restful endpoint, you can rely on the well known standards, such as JAX- RS, and JPA to do that. If you need milliseconds of response time, a 100% uptime, low latency, push data instead of pull, higher throughput and elasticity, Quarkus gives you a head start with its reactive programming model.
Speaker 2: I was reading a little bit yesterday about this, about just how fast it is, about how it sort of build a container first philosophy. I think that's sort of where along the lines, where we're going with this. Putting all this together, Jim, what does this mean for Java developers who are used to other types of frameworks when working?
Jim Garrett: Really what it means in all honesty, Java developers continue to write Java just like they have in the past. Nothing has changed. The only difference is with Quarkus, their Java code is much simpler to containerize and much simpler to move into the cloud. In addition, something that most Java developers are not going to be accustomed to is what I talked about previously, which is the live reloading of their code. And that's a huge selling point. If you've ever developed any type of Java application, if you can simply redeploy that application by saving a file and it automatically deploys it and you can instantly test it, that actually saves a lot of time in development cycles. Really for Java developers, the way they write code is the same, this just makes it a lot simpler and faster to do it.
Speaker 2: Yeah. Something to the effect of develop it, save it and it's up and running. Something that quick, that easy, that just allows the developers to have an easiness of use and just then put something out there that's quicker than what they're used to, right?
Jim Garrett: That's right. And you combine that with the ability that it's instantly available inside of the container. Man, you've just created the best thing since sliced bread.
Speaker 2: That's good. You mentioned earlier serverless computing. For those of us that are not Java developers, that are not really into the IT world, other than just the basic stuff, what does that mean? What is serverless computing?
Jim Garrett: The important thing to understand about serverless is it doesn't mean without a server, but instead it means without a specific server. And the way I like to think about serverless is it implies that the containerized application doesn't actually start to consume resources until an actual request is made. This implies no memory, no CPU, no disc space is used until a call is made to the application. And when the call's made, the cloud server is responsible for quickly spinning up that application, sending the request. The application will then service the request and return a reply. And if no other requests are made, it shuts down. This should imply that the application needs to be able to start within milliseconds and then process the request. And in this example, the application is compared to what we call function as a service for on the spot execution.
Speaker 2: And how quickly that response occurs. Even though, as you said, it doesn't mean that it's necessarily completely serverless. Is Quarkus open source? If yes, what's the benefit of this?
Jim Garrett: Yeah. The short answer is yes. Quarkus is absolutely open source. The benefit is that the development community has access to all of the source code for Quarkus and they have the ability if they want to, they can contribute into the upstream development code base. The difference, when you run Quarkus with Red Hat is that you're using the enterprise version of Quarkus, which is going to give your customers a version of the open source Java stack that is supported by Red Hat.
Speaker 2: Basically if you do run Quarkus through Red Hat, you're getting that benefit of getting the big company behind you, providing you all the tools necessary that you might need in the eventuality you use Quarkus.
Jim Garrett: That's right.
Speaker 2: How does the Quarkus Java framework compare with Spring? How do you think the Spring API compatibility and Quarkus will help developers?
Jim Garrett: First of all, both Quarkus and Spring offer a very powerful stack of technologies and tools to build job applications. In general terms, Quarkus inherits its core features from the JAVA EE stack with tools like CDI and JAX- RS being the most evident an example. On the other hand, Spring follows an alternative modular architecture based on the Spring core. And in terms of microservices, they also differ as Quarkus leverages the micro profile API while Spring boot relies on the Spring boot actuator and the Netflix Hystrix. To size the different stacks, Quarkus has some unique features available out of the box, such as build time, class initialization, Kubernetes resource generation and GraalVM native image support. Although there's no official benchmarks in the typical case of a rest service built with Quarkus, you can observe a memory reduction to half and you can increase the boot speed by five times. In terms of compatibility, it's worth mentioning that while users are encouraged to use your CDI annotations for your applications, Quarkus provides a compatibility layer for Spring dependency injection in the form of Spring DI extension.
Speaker 2: Basically Quarkus does provide an advantage when it comes to speed. As you were mentioning, just that it provides a quicker speed of developing for those that are using it versus a Spring API. However, they are very similar in what they do.
Jim Garrett: That's correct. They're very similar in what they do.
Speaker 2: I mentioned something earlier about Quarkus being container first. Since Quarkus is a relatively new framework that promises lightweight development of container first applications in Java, what is meant by container first? What does that mean?
Jim Garrett: What it means is Quarkus from the beginning was thought to work perfectly inside a container. By its architecture, they wanted it to work perfectly inside a container. By providing a way to compile an enterprise application to native code, it's very important, it's well known by the Java community, that JBM program running inside a container can eventually blow up without any obvious reason. The true reason for this crash, it's related to the fact that Java was created long time ago, before Linux containers entered the scene. And at that time of JBM, didn't have the notion of a container so the process tried to use as much memory and CPU as the hardware machine was able to provide. When you put a Java program in a container, it tries to grab as many resources as possible, sometimes going beyond the boundaries of the container. And when this happened, the Linux kernel stops the container and the process that's running inside of it too. Although this has improved since then, making Java 11 ready to be used in containers, you still need to know how to do it. And Quarkus fixes that problem by providing a way to produce a native executable of your enterprise Java application so you get the same behavior as any other native compiled program when they're run inside a container. The second direction is that we're not creating what's called a big uber- JAR, but rather we create a small uber- JAR, which provides fast build time. This feature is very useful in case you're not building the native executable, but running your Quarkus application in the JBM, using Java. Other frameworks in comparison, have the concept of what they call an uber- JAR, where they bundle everything in the application, along with all the required libraries into that very large JAR file. This isn't a problem if you're not building a container to run that application, but if you use container technology, then things become a little bit more interesting. When you create a Docker container, the container is generated in layers so each step is used to build the container and it's stored in that layer so it can be reused by other builds. Using a heavy, big uber- JAR means that for any change in your code, you're creating a new layer which is tens of megabytes in size because your application layer is the application and all of its dependencies. We produce two artifacts, one JAR containing the runnable code and another one continuing to dependencies. And what this effectively means is if the two layers are created in the container, one for the code, one for the dependencies so any change in your code implies only a small layer with just the runnable code, as the dependencies are going to be reused from the previous execution. And that's one of the things that allows Quarkus to be so quick when it goes to start up.
Speaker 2: Even for people like me that are brand new to code and are brand new to these kinds of topics, making sure that after every action that they receive, they just put out so much, I'll call it energy, but so much information that they can just react quickly and not be bogged down by what was already there, right?
Jim Garrett: That's correct. Yes.
Speaker 2: Red Hat is already using Quarkus in their products and services. How is it helping Red Hat in increasing the efficiency of your cloud native applications?
Jim Garrett: Red Hat is always working on increasing the efficiency of cloud native apps, and they do it in several ways through a combination of practices and technologies and processes that eventually lead to cloud native application success. For example, we constantly evolve our DevOps culture and practices to embrace new technology. We're constantly speeding up existing monolithic applications with simple migration processes that eventually lead to microservices and mini services. We like to choose the right tools for the right application by using a container based application platform that supports a large mix of frameworks and languages and architectures. And we implement continuous delivery and advanced deployment techniques to accelerate the delivery of the cloud native applications.
Speaker 2: That's interesting how they use that to make sure that their cloud native applications just continue to grow and continue to excel at what they do. What is the product messaging for Quarkus on OpenShift?
Jim Garrett: Quarkus was built from the start of course, to be Kubernetes native. Quarkus starts with a small footprint, little memory, fast startup for Java. It's great for containerization. It's great for orchestrated microservices and serverless. And then it touches on developer productivity features like live coding, remote development, reactive and imperative programming models, supports for microprofile. And it also provides for new innovation for Java and the extension of the ecosystem. With Quarkus now being included in OpenShift, the message will get a refresh to provide more detail around why it's the best choice for modern microservice and serverless development. For example, calling out the parts of Quarkus that integrate directly with OpenShift, make it easier to develop compared to what people do today, either on or off of OpenShift. and longer term, the messaging will add support to what we call key native functions, OpenShift pipeline integration and new work on the operators that Java developers are creating.
Speaker 2: In turn, making it easier just to use Quarkus on OpenShift, or really on any other application that it might be applied to, correct?
Speaker 2: Yeah. I completely agree. It sounds like everything is easier with Quarkus to be honest. Everything you've described so far, if you're out there and you're interested in starting to develop code for Java, I would say this would be a good place to start with Quarkus.
Jim Garrett: Absolutely. Absolutely. And you can start to reuse all of those Java developers that you have today. Repurpose them, start developing containers with them.
Speaker 2: Interesting. Well, I've got one last question here, Jim, who could we follow up with to get more information about the upcoming Quarkus capabilities of MTA?
Jim Garrett: I would, first of all, do a Google search look up Quarkus, Red Hat. That will obviously provide very good direction on who to follow up with. There is one individual at Red Hat, his name is Miguel Perez Colino. He is a great resource to get more information about Quarkus. His email address, we can actually provide that to at a later point if you'd like, but in short, those two resources, I think are the people that you would want to look towards.
Speaker 2: All right, well, you heard the expert, Jim Garrett is here with us today from Red Hat. Jim, it has been a pleasure to talk to you today, learning a little bit more about Quarkus myself. I really appreciate your time and your answers. I have learned a lot from you today and I'm sure our listeners have as well. Thank you very much. Once again, Jim Garrett from Red Hat.
Jim Garrett: Yep. Thanks for having me, guys. It's been my pleasure.
Speaker 2: If you have any questions about Red Hat, don't forget to contact Moser Consulting at moserit. com, your technology partner.