Introducción a Quarkus

2
1973

En este tutorial vamos a conocer Quarkus, un framework Java ligero nativo para Kubernetes diseñado para GraalVM y HotSpot.

Índice de contenidos

1. Introducción

En este tutorial hablaremos de Quarkus, un framework Java nativo para Kubernetes diseñado para GraalVM y HotSpot creado a partir de las mejores librerías y estándares Java. Ofrece un modelo unificado para programación reactiva e imperativa. Es un framework ligero orientado a reducir el tiempo, el consumo de memoria y disco orientado a microservicios desarrollado por Red Hat.

Veamos un poco la idea que subyace.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 15 pulgadas (2.3 GHz Intel i9, 32GB 2400 Mhz DDR4, 1 TB Flash Storage).
  • Sistema Operativo: MacOs Catalina 10.15.2
  • Entorno de desarrollo: IntelliJ IDEA 2019.3.1
  • Apache Maven 3.6.3
  • JDK 8
  • Quarkus 1.1.1.Final
  • Spring Boot 2.2.0.RELEASE

3. Java subatómico y supersónico !!

Este es el lema que podemos leer en la web de Quarkus. Hasta ahora a los servicios hechos en Java se les tilda de ser lentos y pesados en el arranque. Con la llegada de los microservicios como nueva arquitectura de aplicaciones ha habido un cambio en el uso de los diferentes frameworks. En el contexto cloud, Mobile, IoT, contenedores, programación reactiva, Funcion-as-a-Service (Faas), aplicaciones nativas en la nube, se demandan tiempos, consumos y componentes con el menor tamaño/huella posible.

La idea de Quarkus consiste en reducir la parte dinámica de Java (reflexión, IoC …etc.) en tiempo de ejecución porque no es realmente necesaria en un mundo de contenedores. A la hora de desarrollar, disponer de un modelo dinámico donde declarar el comportamiento sin preocuparse de la implementación (se enlaza dinámicamente) es muy potente. Ahora bien,  pero una vez que se crea una imagen para un contenedor, generalmente la funcionalidad no cambia. Toda la flexibilidad que proporciona la parte dinámica de las aplicaciones empresariales ya no es necesaria una vez que se despliega en un contenedor. En el caso de Quarkus, Red Hat ha optado por utilizar librerías y estándares como puede ser Eclipse MicroProfile, JPA/Hibernate, JAX-RS/RESTEasy, Eclipse Vert.x, Netty, etc. para componer este framework ligero.

La literatura está muy bien pero por fin vamos al lío. 🙂

4. Creación de un servicio REST

Vamos a crear un API REST con un CRUD básico utilizando Quarkus y la misma versión utilizando Spring Boot para ver si realmente hay diferencias al utilizar estas implementaciones. Para ser originales, vamos a montar un API para registrar películas de cine, ya…muy original.

4.1. Utilizando Quarkus

Quarkus dispone de un plugin para Maven /gradle que genera una estructura de proyecto estándar con las dependencias necesarias. Se le indica el tipo de proyecto a generar y se nos incluirá las extensiones necesarias como se haría con spring initializr.

Comando maven

Una vez se ejecuta el plugin de Maven, obtendremos una estructura similar a cualquier proyecto en Maven. A continuación podemos cargar el proyecto en nuestro IDE preferido.

Como podéis observar en el código que vamos a utilizar para esta demo, la estructura es la típica de cualquier proyecto de este tipo y con las notaciones estándar de JAX-RS. No tiene nada en especial o si….posteriormente lo comentaremos.

4.2. Utilizando Spring Boot

En este caso replicaremos este mismo servicio utilizando spring boot. Para poder realizar una comparación más realista utilizaremos las librerías más parecidas a las que utiliza Quarkus.

El código a nivel de negocio es idéntico, si bien, debido al uso de resteasy nos hará falta especificar los endpoints del servicio rest para que spring boot exponga los endpoints. En este caso, Quarkus nos simplifica la configuración de la aplicación.

5. Comparativa

Vamos a realizar una comparativa muy sencilla pero que ilustra muy rápidamente la idea que subyace.

5.1. Tiempo de arranque


Arranque con Quarkus


Arranque con Spring Boot

Se puede observar los tiempos de arranque de ambas versiones y se observa que Quarkus tarda aproximadamente 3 veces menos en arrancar que con Spring Boot.

5.2. Tiempo de arranque

En este caso lanzaremos una única petición inicial GET a ambos servicios.


Petición con Quarkus


Petición con Spring Boot

En esta ocasión observamos que ambos servicios tienen tiempos casi idénticos. No se ha hecho un análisis de las peticiones posteriores por no ser relevantes puesto que la implementación es muy simple, en aplicaciones más complejas seguramente la diferencia será mayor.

5.3. Peso del componente

Hemos comparado el tamaño del fichero de ambos servicios (el artefacto que se ejecuta con sus dependencias). Aquí se nota el peso de las librerías en el caso de spring boot.


Tamaño en Kb con Quarkus


Tamaño en Kb con Spring Boot

En este caso Quarkus pesa aproximadamente 3 veces menos que la versión de Spring.

5.4. Consumo de memoria

Para nuestras pruebas me he centrado en calcular la memoria RSS (Resident Set Size) tras lanzar la primera petición. Al tener una lógica sumamente sencilla, nos puede valer para hacernos una idea de la diferencia entre ambos.


Consumo de memoria en Quarkus


Consumo de memoria con Spring Boot

Quarkus consume aproximadamente 3,6 veces menos que la versión de Spring. Tened en cuenta que los consumos de memoria son algo sumamente variable y en aplicaciones reales este ratio puede ser muy diferente.

6. Conclusiones

Hemos realizado un análisis muy somero de las versiones pero nos puede dar una idea de las posibilidades que plantean este tipo de frameworks. Hasta hace poco no han publicado la primera versión estable de Quarkus y seguramente seguirá evolucionando e incorporando nuevas librerías y extensiones. Habrá que estar atento a su evolución.

Como hemos podido observar la reducción de tiempos, consumo y tamaño, es notable. Estas mejoras en tiempos y consumos no son gratis en el sentido que nos imponen una serie de restricciones que deberemos tener en cuenta a la hora de diseñar nuestros servicios. En el caso que optéis por alguna framework de este tipo, es importante, revisar a fondo la documentación de los mismos para conocer los efectos que puede tener sobre nuestras soluciones.

En próximos tutoriales exploraremos las posibilidades que plantean si queremos desplegarlo sobre contenedores de forma nativa utilizando GraalVM pues el diseño de Quarkus está pensado para ser utilizado en contenedores. Os dejo el código fuente de ambas versiones para que podáis trastear un poco 🙂

7. Referencias

2 Comentarios

  1. Hola

    En su momento tuve que estudiar este tipo de frameworks, que ofrecen mayor eficiencia que SpringBoot y que combinan bien con GraalVM, y además de Quarkus, que da un buen resultados; encontré otros dos que tienen una filosofía similar y cuyo rendimiento es también bastante optimo.

    Es micronaut: https://micronaut.io/
    Y Helidon SE/MP https://helidon.io/#/

    Lo pongo solo para complementar este artículo, por otro lado excelente.

  2. Para este tipo de comparativas tambien se tendria que evaluar todo lo que pierdes y ganas en un ecosistema u otro… por poner ejemplo efectivamente si pasas de Spring ganas en velocidad y en menos consumo de memoria… pero pierdes todos los demás elementos del ecosistema spring como puede ser el spring cloud, el spring security, el spring session, el spring oauth, etc etc… que al pasar a un ecosistema no-spring tendrás que inventarte por tu cuenta toda la demás funcionalidad.

    En lo particular les agradezco el articulo, y suena interesante estas nuevas propuestas, igual un articulo de graalvm se agradecería 😛
    Saludos.

Dejar respuesta

Please enter your comment!
Please enter your name here