Why Quarkus?

Since the advent of Spring Boot, it has been the De-Facto Backend Framework for Java Web Developers, thanks to its Developer friendly ecosystem, Autoconfiguration Magic and ready to code setup (Spring starters).

But, This is the age of cloud. Several other frameworks have mushroomed up, such as Micronaut and Quarkus.

We will talk about Quarkus, how is it different from Spring Boot, how cloud has made companies to rethink their strategy of choosing the framework, and what is Spring's answer to Quarkus.

For me, Quarkus was difficult. Despite Quarkus having similar ready to code setup, similar style of writing code, there was far less developer support and exhaustive documentation when compared to that of Spring boot's detailed documentation and other online forums.

Spring uses reflection heavily for autoconfiguration. It provides amazing developer experience.

Stereotypes, Component Scan, Configuration Classes declaring beans for classes outside the container using @Bean, Spring Data JPA interfaces, You name it, All of these are autoconfigured using reflection. Spring creates proxies at runtime to setup the Spring Container. This results in high usage of RAM and slower application startup.

To relate to this, lets go through a small example.
You might have seen BeanCreationException during Spring application start up , refer here for official documentation. This exception can occur due to variety of reasons. The main crux of the issue remains that Spring tries to resolve all the dependencies and create Beans in their respective scopes at application startup.

This can help you understand that Spring Beans are created at runtime, when the Application Context initialization is attempted.

But, the objects are created at runtime, why is that a problem?

Imagine a jar file that is included in your project's classpath and is not part of Spring container. You use @Bean to create a Spring bean. Behind the scenes, a proxy class is created at runtime, whose object is created and used by the Spring Container.

Let's take another example, you create an interface extending JPARepository<T>, and it magically provides implementations of multiple methods without a single line of code. How does that work in reality?

Well, again a Proxy class is created at runtime which actually implements those methods.

What does it tell you about Spring?

It tells us that Spring has a high memory footprint and that it is slow as Spring's runtime is computation heavy. Lets understand, why is it a problem.

Organizations have been moving to Microservices architecture because of its Reliability and Scalability. Systems are moving to cloud environments, reducing costs compared to On Premises Infrastructure and plenty of out of the box options for various use cases that these systems may need.

A monolith is divided into multiple microservices based on domain driven design principles. Each microservice has multiple replica instances and each replica gets its own computing and memory resources.

Imagine a system where hundreds, if not thousands of microservices run on cloud, each pod consumes memory and computing resources, the cloud bill increases multifold.

Now imagine an Alternative that is approximately 10x faster on average and uses 1/10th of memory resources, saves a ton of money, the trade off is Developer experience. This is what Quarkus brings to the table.

Here we discussed briefly how Spring works internally, what challenges does it face when integrating with cloud.

In the next part, we will discuss as to how Quarkus solves the cloud challenge and what Spring's team is doing to mitigate the same.