¡Hola a todos! Este es el segundo post de nuestra serie sobre Quarkus. Hoy hablaremos de la compilación nativa.
es una pila de Java diseñada para . Y aunque, por supuesto, queda mucho por hacer, hemos trabajado bien en muchos aspectos, incluyendo la optimización de la JVM y de varios frameworks. Una de las características de Quarkus que ha generado un gran interés por parte de los desarrolladores es el enfoque integral y sin costuras para convertir el código Java en archivos ejecutables para un sistema operativo específico (lo que se denomina "compilación nativa") de manera similar a C y C++, donde dicha compilación generalmente ocurre al final de un ciclo que consiste en construir, probar y desplegar.
Y aunque la compilación nativa, como mostraremos a continuación, es importante, cabe destacar que Quarkus también funciona muy bien en una máquina Java normal OpenJDK Hotspot gracias a las mejoras de rendimiento que hemos implementado en toda la pila. Por lo tanto, la compilación nativa debe considerarse como un bono adicional que se puede utilizar a voluntad o necesidad. De hecho, en lo que respecta a las imágenes nativas, Quarkus se basa en gran medida en OpenJDK. Además, el modo de desarrollo, que ha sido bien recibido por los desarrolladores, permite pruebas casi instantáneas de cambios gracias a las avanzadas capacidades de ejecución dinámica de código que se implementan en Hotspot. Además, al crear imágenes nativas, GraalVM utiliza la biblioteca de clases de OpenJDK y las capacidades de HotSpot.
Entonces, ¿por qué es necesaria la compilación nativa si todo ya está tan bien optimizado? A esta pregunta intentaremos responder a continuación.
Comencemos con lo obvio: Red Hat tiene una gran experiencia en la optimización de JVM, pilas y frameworks a lo largo del desarrollo del proyecto , incluyendo:
- El primer servidor de aplicaciones para ejecutar en la nube en la plataforma .
- El primer servidor de aplicaciones para ejecutar en computadoras .
- El primer servidor de aplicaciones para ejecutar en .
- Una serie de proyectos que funcionan en dispositivos .
Durante muchos años, hemos abordado los problemas de ejecución de aplicaciones Java en la nube y en dispositivos con recursos limitados (conocidos como IoT) y hemos aprendido a maximizar el rendimiento y la optimización de la memoria en la JVM. Al igual que muchos otros, hace tiempo que trabajamos con la compilación nativa de aplicaciones Java a través de , , e incluso y somos completamente conscientes de las ventajas y desventajas de este enfoque (por ejemplo, la dilema entre la versatilidad de 'compilar una vez - ejecutar en cualquier lugar' y el hecho de que las aplicaciones compiladas tienen un tamaño menor y se inician más rápido).
¿Por qué es tan importante tener en cuenta estas ventajas y desventajas? Porque en algunas situaciones, su relación se vuelve decisiva:
- Por ejemplo, en entornos serverless/event-driven, donde en modo de tiempo real (duro o blando) para poder reaccionar a los eventos. A diferencia de los servicios persistentes de larga duración, aquí la duración del inicio en frío aumenta críticamente el tiempo de respuesta. Iniciar la JVM todavía toma un tiempo considerable, y aunque en algunos casos se puede reducir de forma puramente hardware, la diferencia entre un segundo y 5 milisegundos puede ser una cuestión de vida o muerte. Sí, se puede experimentar con la creación de un respaldo en caliente de máquinas Java (lo que, por ejemplo, hicimos al ), pero por sí solo no garantiza la cantidad suficiente de JVM para manejar las solicitudes a medida que se escala la carga. Y desde un punto de vista económico, sin duda, no es la opción más acertada.
- Además, hay otro aspecto que a menudo surge, como la multitenencia. A pesar de que la JVM ha llegado a acercarse mucho a las capacidades de los sistemas operativos, todavía no pueden hacer lo que tan acostumbrados estamos en Linux: aislar procesos. Por lo tanto, un fallo en un hilo puede romper toda la máquina Java. Muchos intentan sortear esta deficiencia asignando a cada usuario una JVM separada para las aplicaciones, con el fin de minimizar las consecuencias de un fallo. Es bastante lógico, pero no se combina bien con la escalabilidad.
- Además, para las aplicaciones orientadas a la nube, es importante un indicador como la densidad de servicios en el host. La transición hacia la metodología , los microservicios y Kubernetes aumentan la cantidad de máquinas Java por aplicación. Esto significa que, por un lado, todo esto proporciona elasticidad y confiabilidad, pero al mismo tiempo, el consumo de memoria base por servicio también aumenta, y parte de estos gastos no siempre es estrictamente necesario. Los archivos ejecutables compilados estáticamente se benefician aquí de diversas técnicas de optimización, como la eliminación de código muerto de bajo nivel, donde solo se incluyen en la imagen final aquellas partes de los marcos (incluyendo el propio JDK) que el servicio realmente utiliza. Por ello, la compilación nativa de Quarkus ayuda a ubicar más densamente las instancias de servicios en el host sin comprometer la seguridad.
De hecho, los argumentos mencionados anteriormente ya son suficientes para comprender la justificación de la compilación nativa desde la perspectiva de los participantes del proyecto Quarkus. Sin embargo, hay una razón más, que no es técnica, pero también importante: en los últimos años, muchos programadores y empresas desarrolladoras han abandonado Java a favor de nuevos lenguajes de programación, considerando que Java, junto con sus JVM, pilas y marcos se ha vuelto demasiado voraz en cuanto a memoria, demasiado lenta, etc.
Sin embargo, la costumbre de utilizar la misma herramienta para resolver cualquier tarea – . A veces es mejor dar un paso atrás y buscar algo diferente. Y si Quarkus obliga a las personas a hacer una pausa y reflexionar, eso es bueno para todo el ecosistema de Java. Quarkus encarna una visión innovadora de cómo crear aplicaciones más eficientes, haciendo que Java sea más relevante para nuevas arquitecturas de aplicaciones, como serverless. Además, gracias a su extensibilidad, Quarkus, como esperamos, contará con todo un ecosistema de extensiones de Java, aumentando significativamente la cantidad de marcos que de forma nativa soportarán la compilación en las aplicaciones.
Fuente: habr.com
