¿Cuándo compilarías un servicio Java a una imagen nativa, y a qué renuncias?

La imagen nativa encaja en cargas donde mandan el tiempo de arranque y la memoria: funciones serverless, herramientas de línea de comandos y servicios que escalan a cero, ya que arranca en milisegundos sin calentamiento y con una huella mucho menor. El coste es el supuesto de mundo cerrado, así que la reflexión, los proxies dinámicos y la carga de recursos deben conocerse en tiempo de build, los builds son lentos, y el rendimiento pico puede quedar por debajo de lo que logra el JIT en un proceso de larga vida.

Tiro de ello cuando el tiempo de arranque está en la ruta crítica. Una función que corre doscientos milisegundos no puede permitirse una JVM que tarda tres segundos en arrancar y otro minuto en calentarse, y el mismo argumento vale para una herramienta de línea de comandos o un servicio que escala a cero entre ráfagas de tráfico. La memoria es la otra ganancia, ya que una imagen nativa puede correr con una fracción del heap. A lo que renuncias es al dinamismo. La compilación anticipada asume un mundo cerrado, así que todo lo que se descubre en ejecución, reflexión, proxies dinámicos, carga de servicios, bundles de recursos, tiene que declararse en tiempo de build. Los frameworks modernos generan casi toda esa configuración por ti durante su paso de build, pero una librería que hace algo listo en ejecución fallará de un modo que solo aparece en el binario nativo, así que la suite de tests también tiene que correr contra la imagen. Los builds además tardan minutos en vez de segundos, y el tooling de observabilidad está menos maduro. Para un servicio de larga vida con tráfico estable me quedo en la JVM, porque el JIT acaba ganando al código compilado de forma anticipada en rendimiento pico.