1 minute read

Using Java in a Microservice based Architecture is challenging. The JVM is slow to start and consume significant memory at bootstrap. In container based deployments these challenges impose significant limitations on how an application can scale. Quarkus is a solution to address these problems.

Quarkus tailors your application for GraalVM and HotSpot. Amazingly fast boot time, incredibly low RSS memory (not just heap size!) offering near instant scale up and high density memory utilization in container orchestration platforms like Kubernetes.

To evaluate whether Quarkus would be a suitable solution for using Java in a MSA I’ve created a sample maven monorepo project using Quarkus. The project provides the following functionality.

Structure

The following principles will be adopted:

  • A separate parent and aggregator POM will exist at the top-level (or any other grouping for e.g. the services folder) to support independent module versioning.
  • Build Tools will have their own configuration module, per the Apache recommendations
  • Profiles will be used to allow building of nested modules e.g. -Pservices, -Pcve
  • Quarkus Services will be modules below the service directory
  • common modules will be created for both service and non-service (generic) code

Quarkus specifics

  • To ensure that beans in a dependency get scanned when building a Quarkus service, jandex is used
  • service application.properties includes a property quarkus.native.additional-build-args=-H:ResourceConfigurationFiles=resources-config.json to get the native build to load extra resources defined in resources-config.json

Generic functionality

  • includes pmd / checkstyle / cve checks plugins
  • provides a generic endpoint /version (in services/common) for all services - info populated from git stats, as proof of CDI bean loading from a dependency
  • provide a multi-stage Dockerfile for building native images