Quarkus

Announcing Thorntail 2.4 general availability

Announcing Thorntail 2.4 general availability

At this year’s Red Hat Summit, Red Hat announced Thorntail 2.4 general availability for Red Hat customers through a subscription to Red Hat Application Runtimes. Red Hat Application Runtimes provides application developers with a variety of application runtimes running on the Red Hat OpenShift Container Platform.

Introduction to Thorntail

Thorntail is the new name for WildFly Swarm, and it bundles everything you need to develop and run Thorntail and MicroProfile applications by packaging server runtime libraries with your application code and running it with java -jar. It speeds up the transition from monoliths to microservices and takes advantage of your existing industry standard Java EE technology experience.

Continue reading “Announcing Thorntail 2.4 general availability”

Share
Subsecond deployment and startup of Apache Camel applications

Subsecond deployment and startup of Apache Camel applications

The integration space is in constant change. Many open source projects and closed source technologies did not withstand the tests of time and have disappeared from the middleware stacks for good. After a decade, however, Apache Camel is still here and becoming even stronger for the next decade of integration. In this article, I’ll provide some history of Camel and then describe two changes coming to Apache Camel now (and later to Red Hat Fuse) and why they are important for developers. I call these changes subsecond deployment and subsecond startup of Camel applications.

Continue reading “Subsecond deployment and startup of Apache Camel applications”

Share
Migrating Java applications to Quarkus, Part 2: Before and after

Migrating Java applications to Quarkus, Part 2: Before and after

This article is a continuation of Migrating Java applications to Quarkus: Lessons learned, and here, I’ll make a comparison of performance metrics for building and running a Java app before and after Quarkus. My goal here is to demonstrate how awesome Quarkus is and maybe help you decide to use Quarkus to build your cool microservices.

Continue reading “Migrating Java applications to Quarkus, Part 2: Before and after”

Share
Guru Night at Red Hat Summit: Hands-on experience with serverless computing

Guru Night at Red Hat Summit: Hands-on experience with serverless computing

Millions of developers worldwide want to learn more about serverless computing. If you’re one of the lucky thousands attending Red Hat Summit in Boston May 7-9, you can gain hands-on experience with the help of Burr Sutter and the Red Hat Developer team.

Guru Night is a BYOL (bring your own laptop) event taking place Wednesday, May 8 from 5:00 p.m. to 8:00 p.m. at the Boston Convention and Event Center in ML2 East-258AB. (Doubtless there will be a map to show you where or what ML2 East etc. is; we have no idea.) Head to the signup page and fill out your details now.

TL;DR: Beer and pizza will be served.

We felt compelled to point that out. But read on.

Continue reading “Guru Night at Red Hat Summit: Hands-on experience with serverless computing”

Share
Migrating Java applications to Quarkus: Lessons learned

Migrating Java applications to Quarkus: Lessons learned

Migrating applications from a well-grounded framework to a completely new framework just a few days after its public release sounds crazy, right? Before doing so, I asked myself several questions, such as: Why should I do that? Is this new framework stable? What would be the gain? To me, the most important of these is: Why?

To help answer that question, I started thinking about my application’s performance—in this case, the bootstrap time—and asked myself whether I was happy with the actual time my application took to start up. The answer was no. And, nowadays, this is one of the most important metrics to be considered when working with microservices, mainly on a serverless architecture.

The goal of this article is to provide a point of reference for a basic migration of an existing Java EE application to Quarkus. For this reason, I’ll save a few lines of the article by not introducing Quarkus and focus mostly on the migration part. If you don’t know what Quarkus is, then I recommend reading this article and visiting the Quarkus homepage.

In this article, I’ll try to illustrate all the changes, or at least the most important changes, that I had to do on my existing application to make it run well with Quarkus.

Continue reading “Migrating Java applications to Quarkus: Lessons learned”

Share
From zero to Quarkus and Knative: The easy way

From zero to Quarkus and Knative: The easy way

You’ve probably already read about Quarkus, but you may not know that the superfast startup speed of Quarkus makes it the best candidate for working with Knative and serverless for your Function-as-a-Service (FaaS) projects.

Quarkus, also known as Supersonic, Subatomic Java, is a Kubernetes native Java stack tailored for GraalVM and OpenJDK HotSpot, crafted from the best-of-breed Java libraries and standards. Knative is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads. You can learn more in this article series.

This article does not provide a full deep dive on Knative or Quarkus. Instead, I aim to give you a quick and easy way to start playing with both technologies so you can further explore on your own.

Continue reading “From zero to Quarkus and Knative: The easy way”

Share
Quarkus: Why compile to native?

Quarkus: Why compile to native?

Quarkus is Kubernetes native, and to accomplish that we’ve spent a lot of time working across a number of different areas, such as the Java Virtual Machine (JVM) and various framework optimizations. And, there’s much more work still to be done. One area that has piqued the interest of the developer community is Quarkus’s comprehensive and seamless approach to generating an operating system specific (aka native) executable from your Java code, as you do with languages like C and C++, which we believe will typically be used at the end of the build-test-deploy cycle.

Although the native compilation is important, as we’ll discuss later, Quarkus works really well with vanilla OpenJDK Hotspot, thanks to the significant performance improvements we’ve made to the entire stack. The native executable aspect Quarkus offers is optional and, if you don’t want it or your applications don’t need it, then you can ignore it. In fact, even when you are using native images, Quarkus still relies heavily on OpenJDK. The well-received dev mode is able to deliver near-instantaneous change-test cycles all due to Hotspot’s rich dynamic code execution capabilities. Additionally, GraalVM internally uses OpenJDK’s class library and HotSpot to produce a native image.

Still, there’s the question: Why have native compilation at all if the other optimizations are so good? That’s the question we’ll look at more closely here.

Continue reading “Quarkus: Why compile to native?”

Share