Java is still, by far, the most popular language when it comes to software development, especially backend. Over the last few years we've seen a huge interest in everything that is cloud-related, like serverless architecture and containerisation. In this article, we'll shortly discuss the shortcomings of the current Java ecosystem in relation to cloud computing and give a brief introduction to Quarkus, a JVM framework aiming to solve those issues.
Anno 2019, I think we can state that quite a lot of companies are heavily investing in cloud infrastructure. Containerisation is becoming a standard and in combination with platforms such as Kubernetes and Amazon ECS we're looking at highly scalable, self-healing and decoupled micro services. One of the most important properties of such services is that they should be lightweight and have a low startup time.
Containerised java applications aren't particularly known to be the fastest when it comes to start up times.
As you'll have noticed in my other blog posts, I'm a big fan of Spring Boot. I use it for most if not all of my side projects, as well as in all services we create at Arkane Network. It's industry proven technology, has a low learning curve and has never let us down when it comes to dependability.
However, the more I'm building complex applications, consisting of dozens of - albeit smaller - micro services, the more size, memory footprint and startup time becomes increasingly important. Whether we're scaling our application, or performing rolling updates, our applications need to be as lightweight as possible.
0x02: Cloud Functions and Java
There's a reason nearly nobody is using java as their go to language when it comes to cloud functions. Some time ago, I was discussing lambda functions with an Amazon Engineer. During the workshop he was giving, he was explaining how Java is almost never used in AWS Lambda, due to much slower cold starts - the phenomenon which occurs when a cloud function is first started - compared to node or python.
The same principal applies to Kubernetes or Amazon ECS. When you're reacting to sudden spikes in your application traffic or load, you can't afford to wait for more than 30 seconds to add another instance. You want your instances up and running in the blink of an eye.
In march 2019, Josh Long - better known as @starbuxman - released a new "installment" of Spring Tips in which he dives deeper in the new features of Spring Boot 2.2, resulting in applications starting up in a lazy fashion, which makes boot times a lot quicker. However, in this blog post, we'll cover an alternative for Spring Boot, which aims to solve the aforementioned issues in a different way.
Quarkus tries to tackle the aforementioned issues by making you create applications with a very low memory footprint and an unbelievably fast boot time.
Quarkus allows you to write your applications imperatively and reactively, so you can have the non-blocking features of for example Spring Webflux.
Although Quarkus is quite young technology, it has a surprising amount of extensions, which allow you to integrate with libraries and platforms you're already familiar with.
The reason Quarkus applications are a lot quicker is because Quarkus prepares your application for Graal/SubstrateVM. An application can be compiled down to a native image, resulting in much faster execution time and smaller Heap size than the standard JVM.
In the past, the result of our CI/CD pipeline would have been a Jar or a War file. However, due to the rise of containerisation, developers tend to deliver images and containers. Because of this, the environment of your application is fully known and part of your configuration. As a result, it's perfectly reasonable to fully compile your java applications to native code ahead of time, as it will definitely run on the target operating system, because it's part of your containerisation configuration. The results of these compiled down applications are astonishing.
Over the course of the coming weeks and months, I'll be writing short 5-10 minute guides on how to leverage the power of Quarkus and other frameworks. They'll be in the same style of the Netflix series I wrote a few years back.
Instead of creating a new github repository for every new blog post, like I did before, I'll be collecting them in one big repository. This will force me to keep the code accompanying the tutorials and guides up to date.