Switching JHipster Microservices to Monolith: Configuration Changes for Low‑Traffic Deployments

Question

Goal: Migrate a JHipster-generated microservices stack (gateway, registry, and one or more services) to a monolithic deployment to lower infrastructure costs for a low‑traffic workload.
Constraints: The microservices version relies on separate Docker containers for the JHipster Registry and Gateway, each with its own JVM heap settings, and uses a shared database that may need to be re‑evaluated for tight coupling. The monolith generator produces a single application with its own Maven or Gradle build configuration, and the existing CI/CD pipelines are tuned for multi‑artifact builds.
Uncertainty: It is unclear which configuration files (application-*.yml, Dockerfiles, docker-compose.yml, pipeline scripts) must be removed or altered, how the build tool choice (Maven vs Gradle) influences resource usage after the switch, and what JVM memory settings are appropriate for the consolidated monolith without causing excessive GC pauses.
Which JHipster configuration artifacts (e.g., registry and gateway Docker Compose services, their application-*.yml files, and related CI/CD steps) should be deleted or repurposed when converting to a monolith?
How does the build tool selection (Maven or Gradle) affect the resource consumption and build time of the resulting monolith compared to the original microservices build?
What JVM heap (-Xmx) and GC tuning values provide a balance between low idle memory usage and acceptable pause times for the monolith under low‑traffic conditions?

Tasadduq Burney · Answer

Answer: What to remove or repurpose

Delete the jhipster-registry and gateway services from docker-compose.yml (or any Kubernetes manifests).
  Remove their Dockerfiles and the associated application-registry.yml and application-gateway.yml (or application-dev.yml) files.
  Keep only the monolith’s application.yml and profile‑specific files (e.g., application-prod.yml).
  Retain the shared database configuration: copy the spring.datasource URL, username, and password into the monolith’s application-*.yml. If the microservices used separate schemas, merge them or adjust entity packages to avoid naming conflicts.
  In CI/CD pipelines, replace the multi‑artifact build steps (separate Maven/Gradle builds for gateway, registry, each service) with a single build of the monolith artifact. Update image tags and deployment manifests to point to the new Docker image.

Likely explanation of build‑tool impact
Both Maven and Gradle produce comparable runtime resource usage for the resulting monolith because the final artifact is a single Spring Boot jar/war. The difference appears at build time:

Gradle: incremental compilation and configuration avoidance can reduce build time for frequent code changes, especially when only a subset of modules is modified.
  Maven: offers more stable, deterministic dependency resolution and is often faster for clean builds when the dependency graph is large but unchanged.
  Recommendation: continue using the build tool already adopted in the project to avoid relearning and potential plugin incompatibilities.

JVM heap and GC tuning for low‑traffic monolith
Start with a modest heap that can accommodate the application’s baseline memory plus a small buffer for occasional traffic spikes:
-Xms256m -Xmx512m
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100
-XX:InitiatingHeapOccupancyPercent=70

These settings give the JVM a 256 MB initial heap, allowing it to grow to 512 MB if needed, while G1GC aims to keep pause times below 100 ms. Monitor idle heap usage; if the steady‑state usage stays well below 256 MB, you can safely lower -Xms and -Xmx to 128 MB/256 MB respectively.
Missing diagnostic detail
To confirm that the chosen heap size is adequate, please provide the observed idle heap usage (e.g., from jcmd <pid> VM.heap_info or a GC log) after the monolith has been running under typical low‑traffic load for a few minutes. If the idle usage consistently exceeds 70 % of the configured -Xmx, increase the heap; if it stays far below, consider lowering it further.

Switching JHipster Microservices to Monolith: Configuration Changes for Low‑Traffic Deployments

1 answer

Answer: What to remove or repurpose

Likely explanation of build‑tool impact

JVM heap and GC tuning for low‑traffic monolith

Missing diagnostic detail

Your perspective belongs here.

0 question comments