Another year, another advent and I am honoured to again open the reign of 24 fantastic blog posts around Java, language, ecosystem and friends guiding all of us into the most silent holiday times of the year. With this being the fifth year (I only missed 2016) I feel really old right now 🙂 But on the opposite side of things a lot has happened in these years and Java is still striving and making all of us productive year over year. Being in the industry this long also allows me to reassure all readers that one topic is a constant: Lifelong learning. When I started developing the first enterprise applications many moons back, there was a complex platform (J2EE) supported by a first couple of thoughts how to make it usable (Spring) and we all meandered our ways through almost two decades of productivity and simplifications for developers and operations. This lead us to the lightweight Microprofile, containers, and Kubernetes as the underlaying infrastructure orchestration. The times and sufferings of bloated specifications and runtimes were over it seemed. But with change comes challenges. Realising that nothing beats proven and established APIs we’ve seen many solutions pushing concepts that are almost a good fit. But not completely. Jonas BonĂ©r coined the termin “microlyth” and with it beautifully described the way that distributed microservices took in most projects. They grew and basically became smaller monoliths interfacing with their peers. Bootiful or not, while beating the complexity of thousands of teensy services the concept reintroduced startup times challenges and scaling problems. While some keep saying that truly distributed applications just need other programming models, we as an industry kept fighting the good fight to keep API knowledge alive and create runtimes that help us bridge the gap between what is necessary and possible. The most innovative approach is called Quarkus. (And yes, I am still angry that they misspelled my name ;)) I’ve been looking into this new and shiny thing almost constantly over the last two months since I rejoined Red Hat. And here is what I learned about it. All in one blog post with a lot of pointers and links in it so you can get to know Quarkus equally good.
Best of all worlds coming together in one place.
The website describes Quarkus as:
A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.
Which actually already is a pretty good description of what it does. Ok, there are a couple of buzz words in here but let’s start at the top.
From the outset Quarkus has been designed around a container first philosophy. What this means in real terms is that Quarkus is optimised for low memory usage and fast startup times. Graal/SubstrateVM support has been an important part of the design for Quarkus from the beginning. When an application is compiled down to a native image it starts much faster and can run with a much smaller heap than a standard JVM. As much processing as possible is done at build time, so your application will only contain the classes that are actually needed at runtime. In a traditional model all the classes required to perform the initial application deployment hang around for the life of the application, even though they are only used once. With Quarkus they are not even loaded into the production JVM. This results in less memory usage, and also faster startup time as all metadata processing has already been done. All of this plus even more makes Quarkus the perfect choice for containerized Java applications. You can take a quick look at how to build, run, package your application with Maven in this Quarkus guide.
For years, the client-server architecture has been the de-facto standard to build applications. But a major shift happened. The one model rules them all age is over. A new range of applications and architecture styles has emerged and impacts how code is written and how applications are deployed and executed. HTTP microservices, reactive applications, message-driven microservices and serverless are now central players in modern systems.
Quarkus has been designed with this new world in mind, and provides first-class support for these different paradigms. Quarkus development model morphs to adapt itself to the type of application you are developing. If you are exposing a simple RESTful endpoint, you can rely on well-known standards such as JAX-RS, JPA and MicroProfile Rest Client. If you need milliseconds of response time, 100% uptime, lower latency, push data instead of pull, higher throughput and elasticity, Quarkus gives you a head-start with Reactive programming, too. You can find more examples reading about the programming paradigm behind it.
Last but not least, standards. Nobody wants you to spend hours learning new technologies. Instead, the Quarkus programming model builds on top of proven standards. Be it official standards such as Eclipse MicroProfile or leading frameworks in a specific domain such as Eclipse Vert.x.
The dependency injection solution is based on CDI. You can use JAX-RS annotations to define the REST endpoints. You can use JPA annotations to map your persistent entities and JTA annotations to declare the transaction boundaries. You can use Eclipse MicroProfile to configure and monitor your application. You can use Vert.x, Apache Camel and it support much more. You can even write your own extensions.
For the joy of development
Quarkus is not just about being great for writing Web Applications or microservices. It focusses on more than the feature set. By focussing on simplicity and preconfigured defaults it lets you do your day-to-day job in the most intuitive way. Making it trivial to develop simple things, and easy to develop the more complex ones. And all if this is supported by the Quarkus Tools for Visual Studio Code which delivers Gradle support, input validation, properties support and a lot more. But the joy continues. As a Spring Boot developer you can also use well-known Spring annotations for Spring Data, Web, and Dependency Injection when building Quarkus applications. Spring developers can quickly become productive with Quarkus using existing knowledge and familiarity of these APIs. You can see if live and in action with this little 15 minute tutorial. To be clear, the Spring API compatibility in Quarkus is not intended to be a complete Spring platform to re-host existing Spring applications. The intent is to offer enough Spring API compatibility to make developing new applications with Quarkus a natural getting started experience. When combined with pre-optimized extensions, Quarkus delivers an amazing amount of functionality for microservices development. With all this being said, developers have successfully migrated Spring applications to Quarkus. If you prefer to watch a video I can only recommend the recording from Devoxx Belgium where Georgios Andrianakis talks about Kubernetes Native Spring apps on Quarkus.
And there is even more fun in it. Kubernetes is much more than a runtime platform for Docker containers. Its API can be extended with application-specific custom resource definitions (CRDs), and you can implement your own controllers adapting your applications dynamically to changes in the cluster. Until recently, most operators were written in Go, re-using code from the built-in Kubernetes controllers. With Quarkus and the fabric8 Kubernetes Client we now have a great basis for implementing operators in Java, allowing us to integrate our existing code base with the power of Kubernetes API extensions. Watch Fabian Stäbler talk about it at Devoxx Belgium.
A workshop – I want code
There is a great hands on lab which offers attendees an intro-level, hands-on session with Quarkus, from the first line of code to making services, to consuming them, and finally to assembling everything in a consistent system. It was developed by Emmanuel Bernard, Clement Escoffier, and Antonio Goncalves. It walks you through everything necessary in a simple step by step guided structure. This workshop will give you a practical introduction to Quarkus. You will install all the needed tools to then develop an entire microservice architecture, mixing classical HTTP microservices and event-based microservices. You will finish by extending the capabilities of Quarkus and learn more about the ability to create native executables.
The getting-started guides on quarkus.io are also a very good place to kickstart your Quarkus knowledge.
And last but not least – It’s open source
We probably rarely think about this anymore, but naturally, as a Red Hat sponsored project, Quarkus is Apache 2.0 licensed and has a home on GitHub. Feel free to star, fork, contribute, file issues, and send pull requests our way and help make it even better. You can also follow @QuarkusIo on Twitter, post on the forum or chat with the community.
I hope you liked this December first post and it shortened the waiting time until your holidays. Wishing you and your loved ones some silent and peaceful days to come and am very much looking forward to meeting you as part of the broader Java community on one of the upcoming events in 2020.
Author: Markus Eisele
Markus Eisele leads developer tools marketing at Red Hat. He has been working with Java EE servers from different vendors for more than 14 years, and gives presentations on his favourite topics at leading international Java conferences. He is a Java Champion, former Java EE Expert Group member, and founder of JavaLand. He is excited to educate developers about how microservices architectures can integrate and complement existing platforms.
He is also the author of “Modern Java EE Design Patterns” and “Developing Reactive Microservices” by O’Reilly. You can follow more frequent updates on Twitter @myfear or Mastodon @myfear@mastodon.online
steinhauer.software
1 Pingback