This material dives into the features of optimized, modern Java applications deployed in Cloud Run in the Google Cloud. It is intended to be a living repo where new optimizations will constantly be added.

App Optimization for Cloud Run should always be framed in the larger context of production readiness of a service for a Cloud Run PROD environment.

There are multiple aspects to writing effective services for serverless environments and they all revolve around the combination of service design, implementation, testing, configuration with environment configuration and optimization best practices.

Optimization is shifted-left and part of the service dev lifecycle from the beginning.

You generally think that a production-ready cloud service must be:

• Stable and Reliable
• Scalable and Performant
• Fault Tolerant without any single point of failure
• Properly Monitored
• Documented and Understood
• Properly secured

Optimizing any app for Cloud Run requires a balance of different aspects to be considered, therefore it is important to always have a clear picture of what it is that you are optimizing for:

• start-up time
• execution latency
• resource consumption (memory & CPU)
• concurrency
• image size
• easy maintainability
• lower costs

This material contains lessons learned from participation in various projects or publicly available knowledge and documentation.

You can:

• revisit the production-readiness checklist as you build the service and review it before deploying services to a Production serverless environment
• use the material as a starting point for optimization workshops or discussions around production readiness

Materials:

• production-readiness checklist
• app w/complete set of services (code, config, environment setup) following best practices
• alternate versions of the services showing what is happening if you don't do this

A set of services is provided to illustrate the different aspects, following this simple architecture:

Source code recommendations can be grouped into the following distinct categories:

• Java - Use latest LTS version
  • Java 17 currently
  • Better performance, security and resource consumption are achieved by simply building and running the app with the latest Java LTS release
• Maven - Use the latest version
  • 3.8.5 currently
• Gradle - Use the latest version
  • 7.4.2 currently
• Dependency management - Use a bill-of-materials(BOM) for managing dependencies and versions consistently for libraries that work together without linkage errors
  • Spring Boot dependencies
  • Spring Cloud dependencies
  • Spring Native dependencies
  • Google Cloud BOM

• Use the latest version of Spring - 2.7.0 currently
  • Spring releases constantly fix issues and CVEs in the frameworks and their dependencies
• Use Spring profiles for environment specific configuration segregation
• Do NOT include Developer tools in Production build
  • Leverage Maven profiles for builds and remove Spring Developer Tools
• Use lazy initialization - potentially not useful if using min-instances, as init could have occurred
• Avoid class scanning by limiting or avoiding class scanning
  • Improvements are app dependent
• Avoid nested library archives JARs - valid for OpenJDK (Hotspot)
  • Building native images with GraalVM eliminates the problem as only classes retained during ahead-of-time compilation will be included in the app image

• Externalize application configuration - do NOT hard-code configs or package config files into images!

• Always set the garbage collector
  • Very important for longer running, smaller footprint Cloud Run services
  • OpenJDK (Hotspot VM)
    • G1 GC set as default for Java 17 for a server class machine - defined as >=1,792 MB RAM and >= 2CPUs
    • Serial GC is automatically set for <1,1791 MB
    • The algorithm used for setting the garbage collector
  • GraalVM
    • Serial GC is set by default for low memory footpring and small Java heapsizes
    • GC implementations
• Use container-aware versions when deploying a Java app in Cloud Run or a Kubernetes-based environment
  • container awareness is important as it allows deployments to cloud orchestration systems to limit container resources via CPU and memory quotas
  • Java 17 and Java 11 are container aware since general availability (GA)
  • Java 8 is container aware since version 8u202
• Understand JVM memory usage
  • Native memory tracking can't be set via JAVA_TOOL_OPTIONS
  • Set start-up arguments in the container image entrypoint or the Buildpack parameters if in use
  • Useful - Java memory calculator
• Catch and handle properly Internal errors - 5XX under the container runtime contract
  • see also source code
• Improve start-up time using application class-data sharing
  • Hotspot JVM - Analysis, slides and source code
    • Spring Boot - use shaded JARs
  • Native Images with GraalVM - use Ahead-of-Time (AOT) compilation
    • Major frameworks have AOT support:
      • Spring AOT
• Find the optimal thread stack size through profiling, to reduce heap consumption
• Use Native Java images for containers

• Test the app with containers - use Testcontainers
  • Use Google emulators for Google managed services
  • Use open-source test containers for Postgres, MySQL and SQLServer for relational databases running in CloudSQL

• Use cloud-native buildpacks to build the container images
• Minimize container images by using optimized container images