Spring boot Vs Quarkus

5 min readMay 10, 2020

If you are someone who have been building micro services with java based framework, I wouldn’t be surprised if you have built them using spring boot.

The mass adoption of this framework is not surprising given that JAVA is one of the most commonly available skills. Availability of lots of starter dependencies have only made developer’s life simple. Auto configurations help avoid a lot of boiler plate code. All you will have to do is ensure you feed the right values in properties/yaml configuration file.

However, It is hard to not notice that even a simple service (read it as a service with simple CRUD endpoints connecting to a relational DB) takes quite a few seconds to boot up. This is often a threat to the scalability promise of micro services architecture. The architecture demands that the services be able to scale out or scale in as the traffic spikes/shrinks. When there is a need to scale out your service (bring up a new container/instance of the service), how long can new requests wait for the container/instance to be ready to serve new traffic? Even if the argument is to use predictive scaling techniques (now supported in AWS) vs reactive rules for auto scaling, you never know how soon the number of new requests would beat the infrastructure available to honor the requests. What if this scale out happens frequently and what would be the impact on performance? What would be the impact on user experience?

I landed on this post last December (Dec’2019) — Vodafone Greece replaces Spring Boot with Quarkus. I was particularly impressed with couple of pointers in that article —

“what Quarkus offers by default (without trying to optimize it) is 50%-60% more lightweight (in JVM mode) than what Spring offers after optimizations (taking care of dependencies, playing with JVM options, etc)”

and

Second, the use of the Quarkus live coding capability (a.k.a. dev mode) resulted in an increase of developer productivity, which Christos described as “a very good thing to have”.

I wanted to try this out myself since then, but something or the other made sure I stayed away. I’d almost forgotten about this when I got an email from RedHat on 04/28/2020 with a link to — Migrating a Spring Boot microservices application to Quarkus. So here is my attempt at migrating a spring boot application to quarkus.

I didn’t have a handy spring boot POC. So I started with API design for a household grocery inventory. The API spec can be found here. The spring boot implementation can be found here. The spring boot application is dockerized and deployed in EKS (k8s cluster in AWS). This helped me to deploy the app in EKS. The RedHat article that’s mentioned above helped in creating a quarkus app for the same API spec. The code for quarkus app can be found here. Let me highlight couple of observations about quarkus app that impressed me before comparing the boot times of spring boot vs quarkus apps.

Observation# 1: Simple Swagger Integration

While spring boot app needs a springfox dependency, quarkus needs quarkus-smallrye-openapi as a dependency. Unlike spring boot app that needs api spec to be annotated, quarkus app can serve the swagger ui if the api specification file can be placed in src/main/resources/META-INF. This impressed me as it is aligned with API first design principle. The quarkus code repo link shared earlier should help figure out how it is done. For more details, read

Observation# 2: Response for HTTP Methods

Let us look at POST method for example

Responding is so simple. Response.created() returns 201. Response.ok() returns 200. Response.noContent() returns 204. While this is good, look at the argument passed to created method. created method takes an URI that’s returned as a location in response header. This is impressive. It gives you the power to stick to standards without having to write a lot of boiler plate code.

Notice that you can invoke the location (GET endpoint) in response header (response of POST request) to access the created resource.

Boot time comparison

None of the times in the below screen shots is a result of first time deployment. I’ve tried capturing the boot times from two types of deployment in local.
1st approach is maven package generating a jar and then executing java -jar command to bring the application up (mvn package and java -jar works for both spring boot app and quarkus app).
2nd approach is building a docker image of the app and running the app in a docker container.
Boot time of Spring boot App: