 Hola a todos. Hola, Jonathan. Hola, ¿cómo estáis? Bienvenidos a Friendship en Vivo. Hoy vamos a hablar de un tema que parece ser que está en el candelabro o en el candelero. Una de las preguntas que es migrar de Skriput a Cuercus. Hay mucha gente que parece que está interesada y por suerte tengo a mi compañero Jonathan aquí que nos va a contar un poco. ¿Quieres compartir tus diapositivas si empezamos? Dale, déjame un momento que comparta la pantalla. Toda tuya. Adelante. Tres, dos, uno. Deberíais verla. Perfecto. Vamos a ver, la presentación es un poco, digamos así, el tema es bastante sencillo. Migrar de Skriput a Cuercus. Pero bueno, básicamente toda la presentación o toda... Cuando alguien muestra la tecnología, lo primero que debes hacer es responder a una pregunta y es ¿por qué? Podríamos estar aprendiendo macramé jugando al go o a las damas chinas, cualquier cosa. Pero ¿por qué se me ocurrió migrar Skriput? Bueno, pues porque está en boca de todos. Como dice Miguel, Cuercus y Skriput, pues es algo del uso. Muchos developers hemos usado Skriput. Y bueno, pues había que probar en nuestras carnes. Si esta migración es fácil, no es fácil. Bueno, pues ¿y qué aporta? Bien, porque vender, se puede vender fácil, pero lo interesante es probarlo y luego uno puede mostrar los beneficios de la migración. Así que fue un reto. Y pues oye, lo aceptamos con mucha ilusión. Así que challenge accepted. Poco la idea de la presentación, pues veis los pasos que hay por si en algún momento queréis ir a tomaros algo y volveis y engancháis justo en el capítulo que os habéis perdido de la serie. Y pues un poco primero daros una idea de qué es lo que podéis esperar en esta presentación. Para aquellos que todavía no conozcáis Cuercus, pues bueno, un poco de idea de qué es Cuercus. Como ya os he dicho antes, ¿por qué debéis plantearos migrar? Debeis plantearos migrar. Luego lo veremos. Luego los pasos de la migración, una comparativa de performance entre las diferentes opciones y luego mi compañero Miguel os mostrará una herramienta fantástica que nos ayudará a poder hacer esta migración y otras. Pues un poco sobre mí, pues nada. Recientemente fui nominado como Java Champion. También soy... Felicidades. Gracias, Miguel. Oye, que te nominen Java Champion no es fácil, es todo un logro. Muchas felicidades. Pues la verdad es que sí, gracias. Han sido muchos años apoyando la comunidad, moviendo eventos, estar con el open source y bueno puedo decir que soy el octavo pasajero de este vuelo español repleto de Java Champion. Así que, bueno, pues gracias. Gracias por las felicidades. Ahora os va a quedar la imagen del octavo pasajero en la cabeza, esa gran película y no tan gran continuaciones. Pues, además, soy co-leader en el Barcelona Jack, el Java User Group de Barcelona, con más de 1.500 miembros ya. También soy cofundador de la conferencia JVC and Conf, que hacemos cada año en Barcelona. ¿Cuándo es la próxima? En 2021, julio, del 12 al 14. ¿Apuntado? Esperamos que todos los astros se alineen y nos permitan hacer esta conferencia. Pero entre tantas vacunas que hay y tanta energía que estamos invirtiendo en muchos países, pero por lo que nos toca aquí en Europa, que estamos sufriendo mucho, yo creo que alguna recompensa tenemos que tener. Así que, esperemos que todos se alineen y podamos tener esta conferencia. Y, nada, trabajo en Red Hat, que es lo que básicamente también me ayuda a pagar la hipoteca. A la izquierda tenéis las formas de contactarme. Si tenéis cualquier duda sobre una migración o queréis que os pueda ayudar o consejo, pues no dudéis en contactarme o incluso en mirar en mi blog que también podréis encontrar un artículo sobre la migración y otros artículos interesantes sobre test containers para probar vuestras aplicaciones como si estuvierais en producción. Y, a punto está calentito, a punto está de aparecer cómo crear un operador en Java con Quarkus, que es el ejemplo práctico de una herramienta interna. Así que, bueno, estás pendiente. Y, bueno, Miguel tiene mucho que decir también. Bueno, yo soy product manager de Migration2Key para las aplicaciones, 2Key de migración. Y llevo unos cuantos años en Red Hat de consultor, de solucionáquite, ni antes, pues haciendo un poco de todo. Soy de corazón, soy sysadmin, ya sabes que esto es como ser marines. Una vez que eres sysadmin, eres sysadmin toda la vida. Pero ahora estoy metido a Product Manager y estamos con las migraciones. Y hoy aquí en Opensiv Commons en vivo pues estoy haciendo un poco el papel de moderador y, a la vez, tendré un poquito una cuñita y, al final, de emitea. Pero ahora te dejo que continúe. Gracias. Pues nada, ¿qué os podéis esperar de esta charla? Bueno, espero que al menos un rato entretenido. Espero que al menos ilumine la chispa de la curiosidad en vuestras mentes. Y, básicamente, es mi opinión una forma de migrar, pero hay muchas. Como diría nuestro amigo Mando. This is not the way. Así que espero que encontréis vuestra forma de hacer las cosas. Esta no es una charla que pretendo enseñaros nada. Más que nada, quiero mostraros una experiencia de cómo es un posible camino de poder migrar. Y es algo que funciona. El objetivo no era buscar una migración mega-ultrafantabulosa, sino algo que fuera rápido, que funcionara para poder cotejar. Bueno, si los pasos han sido lo que esperábamos o no. También veis aquí las dos versiones, la 225 para Spring Boot y Quarkus en el momento de la migración era 1.7. Pero ahora ya vamos por la 1.92. Así que, bueno, la cosa se mueve muy rápido. Pues nada, os voy a dar una pequeña descripción y para mantener vuestra mente más divertida para encender esa otra chispa de la diversión. Pues hay unos... En los slides hay unas copias de pantalla de unos juegos que, bueno, para los que ya tenemos cierta edad, pues representan una época que, bueno, pues que la recortamos con cierta melancolía cuando todavía para jugar había que colocar monedas en una ranurita y, generalmente, escaparse de las clases para poder ir a jugar a los salones de máquinas con nosotros. Los cinco días. Exactamente. Exactamente. La run fue mi ruina, desde luego. Qué gran, qué gran juego. Bueno, pues nada, si los tenéis en mente, pues nada, estará bien que lo recordéis y a ver si sois capaces de adivinarlos todos. Oh, perdón. Ya está bien, ya está bien. Hay que dar la primera y hay que ahora ya se arribende. Muy bien. Pues, qué es cuarcus? Pues nada, es un stack tecnológico en el que lo podéis escoger en tres sabores, Java, Scala o Kotlin y que básicamente tus puntales son que ha de ser muy interconectado con Kubernetes, es decir, de forma nativa tiene que poder hablar con Kubernetes, es decir, fácil, gestiona además de contenedores ha de ser fácil. También otra, digamos, otra pata que aguanta la estructura sería que siempre tiene que estar mirando hacia dos destinos. Ha de ser ejecutable en la máquina virtual de Java normal, hotspot pero ha de ser también compilable con Grad VM a aplicación nativa. Y, bueno, pues esto tiene sus grandísimas ventajas, obviamente, luego las veremos, pero bueno, también tiene sus ciertas mochilas tecnológicas que, bueno, que condicionan esa forma de crear cuarcus. Y la tercera pata que yo creo que para mí también es muy interesante y que lo diferencia de alguna otra alternativa que podemos encontrar parecida o similar a cuarcus es que no reinventa la rueda, es decir, no tenemos que volver a aprender cómo manejar un object relationship mapper como hibernate. No hay que volver a plantearse cómo conectarse con REST o cómo tener comunicación reactiva. Pues tenemos vertex, es decir, no hay que reinventar nada, no hay que aprender nada, hay que simplemente utilizar las librerías que estábamos utilizando hasta ahora y que en cuarcus vienen en forma de extensión, que además, pues están optimizadas y, como digo, están riqueadas para que puedan ser compiladas con Grad VM a nativo. Así, unos datos para iluminaros es que tenéis que tener en mente que con cuarcus el objetivo final, el resultado final, perdón, es muchísimo más rápido que lo que habéis estado utilizando hasta ahora, tiene un memory footprint mucho menor que está enfocada, que sea fácil de programar, como os digo, intentando no reinventar la rueda, no teniendo que usar 100.000 anotaciones. La verdad es que es fácil, lo veréis luego, pero es muy fácil. Obviamente Open Source y en mi caso este es el mayor pilar que existe y después tiene un punto muy interesante y es que realmente es una comunidad que hay detrás muy, muy viva. Es decir, no es algo que, bueno, ahí está, hay alguna otra alternativa parecida de alguna gran compañía con bases de datos y ahí ya lo imagináis, si queréis, que tiene unas alternativas pero que probablemente no tienen tanto movimiento, tanta cobertura, pues en el caso de cuarcus es fantástico. Cada dos semanas hay una release, es decir, hay muchísimo movimiento y es muy interesante. Y luego tiene un montón de extensiones que son las librerías que os he comentado, pues desde Camel, Kafka, Keycloak o Jagger, Flyway, podéis ver, obviamente, herramientas de las cuales Red Hat tiene una comunidad fuerte de comiters, pero hay otras que no e incluso hay alguna otra, como, bueno, creo que Neo4j hay algunas otras empresas que incluso han creado sus extensiones para cuarcus, así que, la verdad es que es una comunidad, un ecosistema muy vivo y, bueno, que lo que hace es lo habitual ahora, lo hace más rápido y que consuma menos memoria. Un poco para que tengáis la idea también de cuál es la evolución, pues bueno, no ha sido más de dos años. Desde finales del 2018 hasta, pues, ahora, estamos a finales del 2020 son dos años y hemos pasado de la versión 001 a la 192 si no voy mal que sea la última, pero cada dos semanas hubo una minor version, así que, realmente, hay muchísimo movimiento y muchísimo trabajo detrás. Para abrir boca con cuarcus hay que pensar, como os he dicho, que consume mucha menos memoria. Bueno, pues aquí tenéis un ejemplo en el que un... con el cloud native stack tradicional pues nos vamos en cuarcus en la JVM, es decir, sin ir a compilación nativa y ya estamos consumiendo la mitad. Bueno, es interesante, ¿no? La disminución, estamos yendo a la mitad. Son megas, no, no son gigas, no son megas. No, no, no, no. Son megas. Es que, a ver, para los desistemas que con Java siempre tenemos el cuidado de tras saber cuánto me van a pedir dos, tres gigas, diez gigas, quince gigas, aquí estamos, volvemos a hablar de megas. O sea, que es que, realmente, es 73 megas. Es poquísimo. Y eso es compilado sobre o sea, con Java o M. Exacto. Pasamos de 140 a 173 porque, en este caso, también la aplicación es muy pequeñita. Yo digo que el beneficio es grande, pero bueno, tampoco es dramático, es la mitad, pero, como tú dices, esto es en un momento muy concreto de la aplicación, muy probablemente al inicio, que luego todos sabemos cómo se desmadra la vida de una aplicación Java con el tiempo. Así que, tal vez, reducir a la mitad, y estamos hablando de dos gigas y pasamos a un giga, pues bueno, oye, pues, al mejor, sí que ya tiene interés. Pero, a donde voy es que ya lo otro es dramático. Y pasamos de 136 de 23, bueno, la mitad, pero caramba es que vamos con compilación nativa, es decir, sin tocar nuestro código para nada, lo único que le hacemos es un minus p native y poca cosa más en la línea de compilación de Maiden. Lo estamos pasando a 12 megas. Es decir, la densidad de aplicaciones en el cluster la pudo multiplicar por 10. Es decir, donde antes tenía una, ahora puedo tener 10 aplicaciones. Bueno, pues... Ahí sí que creo... Claro, ahí sí que creo que realmente la cosa ya es wow, como María, mi hija... Pero fíjate, hay otra cosa que me gustaría que veas. La memoria te he dejado un poco flipando, ¿no? Pero si te cuento ahora que el tiempo y arranque de la... apongamos la aplicación similar, vale más de cuatro segundos, a más o menos un segundo, bueno, ya son tres segundos de menos, pero no estamos en subsec con todavía. Pero es que si yo voy con nativo, es decir, vuelvo, la misma aplicación que no hay que tocar código, tan solo es decirle en la línea de Maiden, en vez de Maiden Clean install Maiden Clean Package menos Pnative listo, varisto, ya está. Con eso conseguimos que la misma aplicación ahora consuma 16 milisegundos. Hemos pasado de cuatro segundos a 16 milisegundos. Esto cuando queremos hacer otro escalado y sacar nuevos contenedores del mismo es clave, porque claro, si quieres implementar, o sea, lanzar nuevos contenedores, nuevas instancias del contenedor, si se levantarían, vamos, bueno, pues eso, estamos hablando de centésimas, no de segundos, de centésimas de segundos, claro, para coherentes es clave, ¿no? Claro, al final yo le pongo en un tema importante, es decir, tampoco vendamos sumo, es decir, si tú tienes tu aplicación, una aplicación ahí que tienes en una máquina, un premis, en tu hierro, 200 peticiones al día, 1.000 le haces el reboot los lunes por la mañana para evitar los memory leaks y ya está. Olvídate, no, esto no es para ti. Es, es otro concepto. Si tú lo que quieres que creo que la mayoría de empresas grandes, sobre todo consumidores grandes tú lo que tienes son muchos servicios, esto para mí nos da dos opciones y las dos se reducen en algo muy sencillo que es dinero. La primera opción noto con mi código aumento a la densidad por lo tanto puedo reducir el número de máquinas que estoy usando porque puedo meter más información entre el mismo nodo o las máquinas virtuales que yo pido para Amazon pueden ser de un tipo mucho menor porque resulta que ahora para hacer lo mismo consumo diez veces menos memoria y consumo muchísimo menos tiempo pues puedo hacer un escalado vertical de hierro y decirle a Amazon oye pues ya no me hagas una mx5 haráme una mx2 por decir algo y eso ya significará que ahorro dinero. Esta es la visión así sencillita sin complicarme mucho la vida pero y si te digo que ahora tu aplicación que jamás pensaste que la podías utilizar en serverless ahora o que si la habías pensado habías decidido usar Python, Node.js ahora la misma aplicación si la divides en microservicios podrás tener como serverless porque arrancan en 16 milisegundos y encima vas a pagar solo por los tiempos de proceso todo el tiempo que esa aplicación no está funcionando no paga con lo cual el escalado hacia arriba maravilloso pero lo más fantástico aún es el escalado a cero el escalado a cero te va a proporcionar ahorro económico, es decir ahora sí que nos podemos plantear Java en serverless ¿Cómo lo ves esto? Pues que tiene todo el sentido es decir que es la modernización completa de Java y el tenerlo a un entorno cloud net de hoy en día totalmente a ver yo entiendo cuando hablo con personas trabajando en empresas con proyectos grandes y demás pues normalmente los equipos que muestran más interés en Quarkus precisamente somos que están con Spring Boot que dicen oye pues esto está muy bien pero y de repente empiezan a probar Quarkus por la velocidad y por el rendimiento y acaban quedándose por la productividad porque resulta que se vuelven más productivos y que sí vamos es lo que me está llegando de la gente que está en muchos sitios en muchas empresas con las que tengo la suerte de contactar y hablar y escucharles claro porque hasta ahora nuestras aplicaciones Java con Spring Boot serán un poquito un elefante de barro eso no lo mueves, ¿dónde lo pongo? es algo que arranca en 4 segundos y que encima me consume 136 megas en esta opción más pequeñita si lo ponemos en opciones reales va a subir más como vamos a ver luego pues oye ya no me planteó otros horizontes esto es lo que hay pero ahora se han abierto unas opciones fantásticas yo le llamo la tierra prometida pero vamos a ver vamos a ir hasta allí vamos a movernos un poquito más en los slides y vamos a ver si la hierba de esa tierra prometida es tan verde como nos la imaginamos menos o incluso más ahora os quiero mostrar simplemente para que veáis la magnitud de Quarkus las copias de pantalla de Github para que veáis que hay un montón de comitres detrás hay 75 autores gente de Red Hat que no son de Red Hat y bueno ahí 6300 stars en el repositorio y bueno pues no hace mucho la versión 192 es decir que hay un movimiento que esta es una comunidad activa y que no es un proyecto que se esté dejando en ningún caso es un proyecto super vivo y con mucha gente empujando y cada vez más pues ahora que ya tenemos claro a que hemos venido aquí ya que tenemos claro porque en este caso yo decidí hacer la migración de la aplicación ya tenemos claro más o menos que es Quarkus pues vamos a hablar concretamente de esta migración y vamos a abrir nuestra mente pensando en este maravilloso juego que además tiene gracia porque mira que jugué veces y veces y dinero invertido así que me hizo mucha ilusión poner Stage 2 aquí porque jamás llegué al Stage 2 me hizo mucha gracia poner esto pero bueno vamos al lío entonces vamos a ver el por qué migrar pues como os he dicho antes la experiencia pasada mía con Spring Boot hay que reconocer que es muy fácil programar con Spring Boot tienes un montón de anotaciones tienes tu clase con mil anotaciones pero no te preocupas porque para eso Dios inventó la rueda en el ratón y puedes hacer scroll y scroll hasta que encuentras el public class pero aparte de eso la aplicación es que tarda una eternidad en levantarse tarda muchísimo oye que en cada test tienes que levantar el contexto generalmente igual se puede hacer mejor pero eso qué pasa que hace que la se terminece luego la aplicación cuando estás en aplicaciones Real World consumen una barbaridad o sea bueno es muchísimo lo que consume una aplicación con Spring Boot de las de Real World las Hello World y hay otra cosa que tampoco no me ha acabado de gustar nunca mucho y es que tu arrancas tu aplicación le pusiste cuatro properties en el property para levantar un Tomcat un Yeti lo que sea y poco más pero empiezas a revisar el log y empiezas a ver ahí un montón de cosas que se están arrancando de las cuales tu no tenías ni idea pues eso a mi tampoco no me hacía mucha gracia y como había visto la cierra prometida de Quarkus pues que en realidad es fácil de desarrollar aplicaciones va a ser mucho más rápido va a consumir mucha menos memoria y encima va a ser compatible con Graal para hacer compilación nativa por lo que podemos ir a serverless o funciona su service, llámale como quieras en lambdas, en Amazon o otros servicios y eso significa menos dinero de costa de mantenimiento de la aplicación así que pues no sé, me lo pintan fantabuloso pues este fue el motivo de la cual, dime si, la semana pasada tuvimos en Opecif Commons en vivo a Alex Soto que quizá más es amigo de tuyo y a Aurea Muñoz nos estuvieron haciendo una demo de Quarkus no nos contaron tanto detalle de los beneficios pero sobre todo hice una demo muy práctica de cómo programar en Quarkus y si nos estáis viendo y queréis ver más de Quarkus os recomiendo que vayáis a Opecif Commons en vivo y que busqueis el capítulo de la semana pasada y así veis la demo de Quarkus y la recomiendo totalmente los dos son unos carácter no son unos carácter si, si pues eso, solo recordadlo ahora, si, de esprimo de la Quarkus no hablamos esto es de nuevo en Opecif Commons en vivo perfecto pues vamos a ver esta aplicación que se quiere migrar cuál es que contiene puede ser un Hello World bueno pues no así que te decidió usar una aplicación que estuviéramos seguros que ya estaba bien hecho de tal manera que si lo hacemos mal lo hacemos mal solo en un lado uno de los dos así que se cogió Spring Boot Tech Clinic Rest es decir la aplicación con el código producido por Spring por Pivotal digamos así y bueno pues cojamos ese como referencia vamos a ver si obtenemos lo mismo y que cambios hay que hacer pues para empezar esta aplicación contiene lo que la mayoría de aplicaciones al menos en las que estado yo contienen hay otros módulos que se pueden añadir los que tiene esta aplicación generalmente están en todos Spring Data, Spring Web para Rest Security la Swagger actuators para obtener las métricas MicroMeter para registrarlas CDI obviamente AOP bueno AOP aunque es muy potente a mí me gusta mucho la programación de aspectos pero la verdad que yo creo que la mayoría de la gente no la usa aquí se usa para obtener métricas sobre toda la capa de de repositorio pero bueno vamos a ver que magia podemos hacer nosotros tener lo mismo y también Local Caching pues bueno utiliza Spring Cache y tiene un PetHashList en memoria y listo pues para eso tenemos Quarkus Cache que en realidad utilizo una librería interna que se llama Caffeine así que más o menos tenemos lo mismo JaveNet Panache para Spring Data JaxRS para Web Quarkus Security, OpenATI en este caso además la estándar Small Right Health Micro Profile Metrics again la estándar CediSpec la estándar es decir oye nos estamos moviendo en estándares y en librerías que todo el mundo conoce y que a mí me ha usado por ahí ya me va gustando ¿Qué es lo que no se migró de esta aplicación? pues bueno esta aplicación viene en tres gustos de persistencia Spring Data Spring JPA JDBC Nos entramos en JPA porque es lo que más se usa y por motivos de tiempo y para centrarse en obtener una aplicación que sea fácilmente comparable si queréis utilizar JBC Directo pues hay una extensión agroal y os permitirá hacer lo mismo Y luego JMX porque dependiendo de lo que es pues hay opiniones contrastadas pero básicamente no hay un mensaje oficial directo sobre que GRAL-VM permite JMX así que para no entrar en terrenos pantanosos pues no entre en JMX Pues bueno vamos a por los pasos de la migración es decir que cambios hay que hacer en el código porque ya tenemos claro aparte de lo que teníamos anteriormente que proyecto vamos a migrar que partes tiene que son muy parecidas y que estamos además utilizando una aplicación que contiene lo más utilizado lo más común en todas las aplicaciones así que es algo extrapolable pues vamos con los pasos pero antes de nada pensad en este juego porque además creo que fue el primero que tuvo un simulador y en el cual este además me acuerdo perfectamente que me escapaba de las clases para ir a jugar este sí, en este lo reconozco I'm guilty si habías visto Topkan ya te emocionabas ahí además era la época así que todos nos creíamos maverick así que sin duda perfecto pues vamos a ver qué cambios lo hacemos si todavía seguís utilizando AutoWire oye pasados ya a Inject aunque no paséis a Quarkus pero cambiadlo por algo estándar pues en este caso si utilizabais ya algo estándar no hay nada que cambiar la definición de los links en este caso pues utilizando ApplicationScope y lo tendremos podíamos utilizar también Singleton pero bueno vamos a utilizar ApplicationScope también hay otras Scopes como Session en este caso nos centramos en ApplicationScope y básicamente pues tiene autoinjectión de los constructores como el otro y además en este caso es LaceByDefault que nos va perfecto para obtener buenos rendimientos en arranque y que aquellos bins que se inicialicen sea porque realmente alguien los usa en este caso pues la verdad es que la migración fue muy sencilla no hay funcionalidades que che de menos y además también en las últimas ya versiones nos permite anotar los bins para que se inyecten dependiendo del profile que se está determinando en la línea de comando incluso en properties del fichero de properties así que muy muy similar y la verdad es que muy fácil por otro lado con la acceso a datos bueno pues esto es muy fácil creamos una clase Repository que implementa Panache Repository en este caso fui un paso más allá y tuve que implementar Panache Repository base simplemente porque en el proyecto las clases o los tipos identity para las entities en la versión de Spring son integers y en la versión de Panache son long así que para no cambiar todo el código en todos los find, buy y bla bla bla lo que hice fue bueno voy a crear una Panache Repository me voy a la base y le especifico que la clase Identity ahora es un integer y ya está y con esto tendremos en tiempo de ejecución para manejar todas las entities como veis aquí list, find, persist, delete lo normal hay una cosa que no os he comentado antes que creo que es interesante y es que una forma de ver Quarkus es como algo que funciona en tiempo de compilación es decir básicamente Quarkus va a acoger todo el código va a inspeccionar todo lo necesario todo lo que haga falta para hacer todo el trabajo posible durante la compilación para que no sea necesario hacer ese trabajo en tiempo de ejecución y de ahí es que las métricas de performance en mucho mejores porque todo el trabajo se hace en compilación un tiempo en el cual no estamos muy preocupados si tarda más o menos en compilar porque lo hace nuestro entorno a integración continua y ya está un poco no hay tanto problema la única funcionalidad que no encontré es que en Panache no tenemos los queries el método que son aquellos que podéis utilizar como find, by name y bla bla pues estos no están de tal manera que lo que hay que hacer es crear esos métodos o bien inyectar la query por anotación o bien colocarla dentro del cuerpo en el método tampoco no hay tanto problema y podéis personalizar mucho mejor la query en cuanto a rest pues esto es pasar de spring rest a jacrs de nuevo nos movemos de algo es spring en su entorno en su mundo, en su burbuja y nos vamos algo abierto estándar y utilizado por las aplicaciones y múltiples compañías que es jacrs de tal manera que básicamente era cambiar una anotación por otra excepto request mapping que lo que hay que hacer es dividirla en tres porque en Quarkus en jacrs hay que definir pues el path el get y el post y el get y el path param los hay que ponerlos en tres anotaciones diferentes así que básicamente ese fue el cambio pero poca cosa más en cuanto a la seguridad pues también ha sido muy sencillo básicamente reemplazamos la anotación pre-authorize con las rows o la web y ya está hay que hay que especificar la extensión en el pump y poca cosa más la única diferencia que encontré es que en el pre-authorize como podéis ver aquí hay un lenguaje de expresión es decir podéis hacer unas expresiones más complejas en la versión de Quarkus no encontré la forma de hacer lo mismo y la opción que encontré es simplemente incluir los diferentes roles están permitidos entrar a ese método si no vais a tener que hacer cosas complejas que creo que puede ser el caso de la mayoría os sirve perfectamente si no habría que buscar un workaround en cuanto a la asistencia de la seguridad en este caso la tenía toda persistida en base de datos para eso utilizamos la dependencia elitron security jdbc y automáticamente todo esto quedará gestionado transparente directamente exactamente te añaden estas properties en el property y ya está no hay que tocar el código es que hay una cosa que nos contaron el otro día Alexi y Auri sobre properties y de cómo definir por ejemplo para hacerte tus imágenes directamente en el properties es decir el properties que vas a poner en Quarkus es súper completo es decir, te va desde el acceso a base de datos a cómo voy a construir mis imágenes a cómo las voy a despegar a la configuración interna es fantástico desde haber como luego lo despliego esta aplicación en base de datos está todo en el properties todo en el properties además el properties te permite tener los diferentes perfiles es decir puedes tener el de depth el de prod y el de test es muy potente y en las properties hay un montón que lo que harán será condicionar cómo se comporta Quarkus en el momento de generar nuestra aplicación fantástico si no hay código envuelto en esto, mejor porque el mejor código es el que no falla y el que código que no falla es el código que no existe así que eso es lo mejor no encontré ninguna diferencia solo como os he explicado el lenguaje de expresión en cuanto al cross origin como dijo Miguel hace un momento de nuevo se configura en el properties y ya está automáticamente ya tendremos el course aplicado a nuestros controladores la única cosa que yo al menos no encontré es en Spring puedes tener el course configurado a nivel de controlador y en Quarkus se hace en el properties y se hace en forma global yo no encontré forma de hacerlo por controlador pero tampoco en este caso en este proyecto no hubo necesidad pero bueno, me parecía adecuado mencionar los puntos que encontré que no había un paralelismo directo en cuanto a las métricas es muy sencillo también es añadir la extensión en el POM y automáticamente ya tendremos las métricas de sistema igual que con Spring y para los métricas custom los de usuario pues bueno, lo que podemos hacer es anotar aquellos métodos de los cuales queramos tener métricas con el counted y el timet y automáticamente saldrán en el listado de métricas hay que tener en cuenta que Spring utiliza micrometer y micrometer utiliza micrometer notation que quiere decir que la nomenclatura de las métricas no es exactamente la misma así que para tener para que vuestros dashboards de grafana por ejemplo no fallen pues habría que tener la misma nomenclatura pues para eso el equipo de Quarkus creó un toggle que lo veis abajo que es micrometer compatibility true y automáticamente el naming de las métricas será el mismo que el de micrometer perfecto Podríamos mantener el histórico de la aplicación antes y después de migras en métricas Exactamente, sí De hecho la migración la hice con con microprofenmetrics pero porque no estaba en aquel momento pero luego ha salido la extensión micrometer que significa que no tenéis que tocar el código simplemente cambiáis la dependencia y Quarkus sigue usando esos interfaces que vosotros usáis en vuestro código y los usa para generar el código que va a usar luego si hay algo de micrometer en vuestra aplicación no lo toquéis colocáis la extensión de micrometer y listo La única pega es que nosotros no tenemos a OPE no tenemos programación orientada a aspectos así que cómo hacemos para obtener las métricas que Spring está obteniendo de todos los métodos de la persistencia pues no os vayáis y en un segundo os lo explico de momento lo que os voy a explicar es cómo funciona el tema de la validación pues vamos a pasar de Spring Validation a Hibernate Validator si miráis el código es muy parecido simplemente pasamos pues de un Controller Advice a una implementación de Exception Mapper por qué cosa más el código es casi casi igual y los dos se basan en el Valid y en las constraints estándar de un pollo para definir cuáles son las validaciones así que en este aspecto es bastante sencillo no hay que tocar gran cosa en cuanto a su agreg pues es fácil añadís la extensión OpenAPI y ya están todos vuestros resursos publicados que queréis añadir información de cabecera a la API como es normal pues creáis una clase y extendéis aplicación con esta notación OpenAPI Definition automáticamente tendréis la posibilidad de definir la cabecera de lo que es la API y con esta extensión tenemos el swagger UI out of the box en test pero si queréis lo podéis activar también para Prod es muy sencillo la única cosa en la que no vi paralelismo es que en Spring se puede especificar qué paz queréis que se escane para incluir información en swagger es decir si queréis ocultar algún endpoint y en Quarkus no encontré la forma era bueno que todo lo que hay en tu código aparece publicado en swagger imagino que hay alguna forma pero no la encontré es sencilla y tampoco la exploré mucho porque no era el caso, en este caso el proyecto no estaba escondiendo ningún enpoint pero no vi una forma directa y rápida de hacer lo mismo imagino que sí que la habrá pero no la encontré pues ahora volvemos a las métricas cómo lo hace Spring para obtener las métricas sobre todos los métodos que dependan de clases de repository pues muy sencillo veis esta expresión en el around a la izquierda y con esto cubrimos todos esos métodos de hecho todos los métodos de la clase repository que lo van a llamar todos los repositories que vosotros creéis y es muy sencillo con esto cubrimos todos esos métodos y obtenemos la métrica bueno y en el caso de Quarkus pues caramba hay que generar las anotaciones una por una en todos los métodos sería una forma podríamos usar interceptores de CDI también sería otra forma pero hay otra forma más sencilla poner esta property en las properties en la que le decimos que hibernate nos guarde métricas y ya tendremos las mismas métricas en nuestro en nuestro output de métricas sobre todas las todo el uso de hibernate que es más o menos el mismo uso que se le estaba dando a AOP en el dado de Spring en este proyecto así que para este caso en concreto con una línea en el properties hemos arreglado así que fantástico en cuanto al catching pues como podéis ver las clases son muy parecidas concurra en Heisman concurra en Linkin Heisman al caso vamos a tener el mismo resultado y lo único que hay que hacer es cambiar la anotación que en vez de catch pasamos a catch result especificamos el nombre del catch y en el properties de nuevo configuramos la capacidad inicial el tamaño máximo de ese catch bueno el comportamiento que le quedamos dar y realmente ha sido muy sencillo un replay en cuanto al testing bueno cuanto al testing es un poquito más complejo porque aquí sí que hay que cambiar código pasamos de mock and busy a rest assured y hay que reprogramar el test de todas maneras yo prefiero el código que hay que generar para rest assured para mí es mucho más claro más conciso, se ve mucho mejor pero es un tema de gustos pero es cierto hay que cambiar hay que cambiar el código bueno, no hay más, no hay otra la diferencia básica que en un sitio usamos json path y en el otro gpath y en el groovy para verificar los payloads de resultantes pero bueno es básicamente igual la única contra es que en Spring podemos simular roles es decir que podemos probar la seguridad de un método especificando un rol en Quarkus hay que crear un usuario asignarlo a un rol y inyectar al usuario en el test o al menos no encontré forma de hacer lo mismo en ese momento y bueno esta es la única diferencia que encontré en el test en cuanto a los resources porque claro esta aplicación corre contra un posgre pero en test no vamos a levantar un posgre o si mi consejo es que si no me gustan las simulaciones aunque tengo unas gafas de realidad virtual que me encantan pero en estos casos prefiero conectarme a la realidad por lo que... no me cabe un posgre o no a ver si yo voy con el de sistemas de las botas me cabe claro lo que pasa es que muy buena pregunta porque eso me da me encanta que me hagas esa pregunta porque eso me da paso a hablar por ejemplo en una de las aplicaciones que hemos hecho en el equipo utilizamos una herramienta que se llama test containers en la que puedes instanciar contenedores dentro de tu test y adivina uno de ellos de hecho dos son posgre en nuestro test que corre en integración continua cada vez que alguien hace una public request se levantan ocho contenedores con ocho capas diferentes hay incluso aplicaciones internas de Red Hat que se levantan por un docker file tenemos el entorno de producción en nuestro test de integración dos motores de posgre levantados con la configuración que nosotros queremos con la versión que nosotros queremos que es la misma de producción y nuestra base de datos se conecta o sea nuestra aplicación se conecta a esas bases de datos ¿por qué es bueno esto? por una sencilla razón H2 no es posgre con lo cual si yo tengo Flyway una herramienta para gestionar los actualizaciones de la base de datos resulta que yo puedo estar poniendo instrucciones que van contra posgre que no me funcionan en H2 de tal manera que tengo que generar un segundo juego de instrucciones para H2 porque el niño no es igual que el papá así que prefiero en este caso una herramienta reales pero eso es otra historia en la que nos ocupa había que levantar un H2 así que se levantó un H2 pues para ello lo que hacemos es utilizar Quarkuster Resource y especificamos qué clase de recurso queremos en este caso H2 y levantará una H2 para que nuestros tests se conecten a ella y listo en cuanto a testing mocking en este caso pues es fácil queremos moquear bins pues vamos a moquear bins utilizaremos IncheckMock y utilizaremos QuarkutJunit5Mockito y ya está pues hemos llegado al punto en el que os digo paparruchas patrañas nada de esto que os he contado vale la pena hay alguna forma mucho mejor de hacer todo esto que es utilizar la API Spring de Quarkus y que es eso pues que utilizamos Spring Web pues llegamos utilizando Spring Web simplemente cambiamos la dependencia en el POM y no toquemos nuestro código y Quarkus va a utilizar esos interfaces y va a generar el código ejecutable que él necesita y además será compilable con graal y que ¡hanza! no toquéis el código seguid utilizando lo que estáis utilizando hasta ahora esto es muy bonito pero hay algunas cosas que las extensiones pueden no cubrir así que es bueno que mireis si cada extensión está cubriendo exactamente lo que vosotros usáis si sois muy avanzados utilizáis unos casos como decimos corner cases en español casos esquina pues si utilizáis casos esquina complicados a lo mejor la extensión no lo cubre así que tenéis que revisar la extensión pero si utilizáis los casos comunes no hay que tocar código y la inyección de dependencias tampoco no hay que tocar nada mantenéis vuestras clases sin tocar y cambiáis la extensión en el POM y listo con con data lo mismo no toquéis nada cambiáis la extensión seguís utilizando los métodos incluso ahora o vuestros findByNameOrderBy perfecto solo si no en caso de que utilizéis alguna cosa que la extensión no cubre como habéis dicho antes pues habría que buscar una alternativa pero si ese no es el caso no hace falta cambiar no cambiéis si queréis migrar una gran aplicación y obviamente el tiempo es una de las patas interesantes tiempo calidad y dinero pues no lo toquéis seguís con vuestras clases tal como están que ya funcionan y cambiáis la extensión y con la security igual y en este caso incluso tenemos expression language en los para definir la seguridad así que no hay problema no toquéis esas clases mantélenlas como están simplemente cambiar la extensión y ya está pues ya hemos llegado a un punto en el que ok ya hemos visto por qué estamos aquí ya hemos visto que es cuarcus ya hemos visto por qué se me ocurrió migrar ya hemos visto qué hemos migrado y ya hemos visto los pasos para hacer esa migración que tenéis dos sabores vainilla y fresa cambiar a librerías estándar es un buen movimiento la verdad pero conlleva un tiempo obviamente y seguir el camino de las losas amarillas que conlleva pues como siempre riesgo una inseguridad o utilizar las extensiones spring en el cual bueno pues podemos entenderlo como un límite que tiende a modificación cero dependiendo de lo que utilicéis pero ahora vamos a ver todo esto algo todo esto me da un beneficio porque esto es un trabajado al final no lo voy a sacar redito a esto pues me dedico yo desde al macramé a como viene el otro día un reportaje a la danza con perros hay competiciones europeas al menos bueno no sé hay muchas cosas que podemos hacer pues vamos a ver qué números aquello de todo esto pues vamos a fijarnos primero en tiempo de compilación tenemos spring boot que tarda 4 segundos y 48 megas genera un artefacto de 48 megas bueno el uber jar el que contiene todas las librerías en quarkus para la jvm en hotspot 13 segundos bueno ya no vamos bien tres veces más de tiempo y el artefacto más o menos es una misma tamaño de momento macramé va ganando y si me voy a agrar al uber me compilación nativa uah, está pasando de 13 segundos a 185 y de 42 megas a 97 está clarísimo que me dedico al macramé no sé ni lo que es pero es un tema que vale a la pena explorar con estos números si nos vamos a tiempo de ejecución porque creo que a todos nos preocupa el tiempo de ejecución el de compilación nos lo hace nuestro amigo travis oye yo qué sé que tarde el tiempo que necesite el muchacho no nos preocupa pero el tiempo de ejecución que es donde ahí lo tenemos en producción y donde nuestros clientes vamos sufriendo estos tiempos pues vamos a ver casi 7 segundos bueno hay gente que en menos tiempo se ve una cerveza pero son 7 segundos para arrancar y 630 megabatts de memoria al arranque tal como arranca, pum, 630 megas se han ido y en cuarcus pues con la JOTO BM pasamos de casi 7 a poco más de 2 y medio bueno hemos ganado las que sí se ha ganado y hemos pasado a menos de la mitad de memoria pues hombre también ya sólo aquí al menos hemos ganado más de la mitad en tiempo y más de la mitad en memoria donde antes tenía una aplicación de spring boot ahora puedo tener 2 con cuarcus consumiendo más o menos lo mismo pero luego la versión engral oye y lo verifique varias veces que no me he equivocado pues no señor no me equivoqué menos de medio segundo calibrado 7 segundos medio segundo hay que pensar que arrancar en este caso en este proyecto significa obviamente levantarlo necesario en la CDI conectarse a posgre verificar que tablas existen crear todas las tablas insertar los registros por defecto y tener el el motor web arrancado eso es lo que se hace así que pasamos de 7 segundos a menos de medio segundo y pasamos de 630 megas a 21 megas es decir donde antes tenía una aplicación de spring boot pues ahora puedo tener conle 2 y 7 puedo tener 14 aplicaciones cuarcus gral por tiempo de arranque y por memoria puedo tener 10 20 30 30 aplicaciones corriendo es decir ha aumentado la densidad como mínimo por 20 puedo misma hasta 30 bueno hombre pues la verdad dependiendo de los recursos los que estemos contando bueno yo le veo un beneficio muy interesante yo cuando vi este número dije esto si esto si es la tierra prometida alta unos ríos con agua cristalina maravillosa y una temperatura perfecta de 25 grados bueno eso es la descripción de Tenerife pero aparte para mi era perfecto porque ahora sí que nos podemos ir a serverles y cambiar estructura así cambiar planes de pago me parece que eso ya es una un cambio radical y además esto no es un hello world es la aplicación que se emplea para hacer una demostración de splimbo buena puntualización porque hay hello world que están tuneados, tuqueados pero esto no es ningún hello world esto es una aplicación que tiene tres o cuatro servicios rest que tiene varias entities que se conecta una base de datos y que hace dos o tres funcionalidades puede ser un pequeño microservicio que en splimbo me lleve siete segundos y 630 megas pues eso no es un microservicio eso es un mastodonte en cambio con cuarcos y gral eso sí que son microservicios ahí sí que podemos ir a diferentes estructuras infraestructuras y diseños arquitecturales pues bueno un poquito hasta aquí es el tema de la migración pero bueno por favor este juego tenedlo muy en memoria porque este lleva desde no sé muchísimos años, esta es una versión moderna pero el chico este con el arco y la flauta o la ocarina tenéis que saber cuáles tú sí que lo sabes sí sí sí pues nada hasta aquí era un poco mostraros las referencias quieres continuar tú con las referencias o te doy paso con cuando hablemos de mediar no, estaba viendo que precisamente te has creado un repo en tu usuario de github con el resultado de migrar del original que está arriba en el splimrespedpilic al cuarcus prespedpilic y está ahí por si alguien quiere echar un ojo ¿no? mandarte un purrequest y te dices llegué esto y quedaba mejor perfecto perfecto intenté hacer comics pequeños para que se pudieran ver todos los cambios así que bien me ha encantado he aprendido bastante porque hay cosillas por ahí que está uno aprendiendo aprendiendo, además como te digo siendo más bien de sistemas el bucear dentro del mundo de Java siempre es algo bueno para aprender y muy interesante así que ahora si me permites hago yo una pequeña cuña de unos segunditos porque tampoco tenemos mucho tiempo permites que comparta yo la pantalla ah si, si claro quieres compartir esto si me lo permites claro, ahora todo tuya comparto pantalla y bueno tenías aquí otras referencias que está bien enseñarlas tenemos un curso de Quarkus en developers.reja.com para que te puedas poner al día y de nuestro amigo Alexoto la hoja del chichi de Quarkus para que te acuerdes de dónde está todo y luego para empezar a programar recuerdo el programa que tuvimos la semana pasada con Alex y con Auri que nos mostró precisamente esto en www.quarkus.io donde te seleccionas las extensiones que quieres utilizar te bajas un zip lo descomprimes y a empezar está ahí todo y ahora la pequeña cuña de Megasintook for applications que es una herramienta que te ayuda a revisar código java tanto binarios como código fuente y eliges un target que en este caso tenemos un target que va a salir la semana próxima aunque ya está disponible en la web de Quarkus entonces te vas a red.html y te lo descargas y ahí tienes la aplicación entonces puedes analizar una aplicación por el ecomotar red parkus que te vaya dando pistas todo lo que habéis visto que ha contado Jonathan pues lo hemos letido como reglas para que luego te vaya diciendo esto lo puedes cambiar por esto esto lo puedes tocar aquí y entonces te va guiando la nueva versión y además un interfaz superchulo que es que bueno ya lo habéis visto a mí es que me encanta tenemos los iconos aquí todos coherentes bonitos y luego un interfaz para crearte tus propias reglas de quiero detectar este cuando detectes esto quiero que me mande a esta wikinterna que tenemos para decirla a todos mis compañeros programadores que oye que yo lo resulto así que creo que está la forma de hacerlo pues por supuesto hemos incluido como decía las reglas de sprint buta parkus 24 reglas ni más ni menos hemos tenido la suerte de algún compañero roman martín nos ha ayudado a probarlas con código real es un consultor que trabaja con distintos clientes y le ha dado una vuelta y nos ha dado muy buenos consejos que hemos incluido ya directamente en esta versión 510 para que podáis utilizarlos y bueno un ejemplo de las reglas que se pueden detectar para migrar de sprint buta parkus se va la aplicación enseñando oye esto es lo que puedes hacer por ejemplo aquí reemplazamos el artefacto en el sprint but property con la extensión y por supuesto si tienes un IDE como clipse visual studio code o clipse che o también las versiones que hacemos en redfark que están ya empaquetadas como code ready studio que es la versión de clipse o code ready watch spaces que es la versión de clipse che y un operador que aquí ha hecho en su mayor parte de jonathan y que nos contaba otro día como lo ha hecho con quarkus para poder desplegar esta herramienta migrésin toque for applications en opelsir y todo es todo disponible y unos cuantos casos reales de empresas que están usando quarkus los transatomic hacia castietto el caso de modafone tiene un detalle que me ha gustado mucho que es que no solo han mejorado el rendimiento sino que que después de pasarse a quarkus han reducido la cantidad de código que necesitan para hacer lo mismo entonces como diría jonathan el código que no existe es el que no falla pues si reduces tu número de líneas de código para hacer lo mismo pues menos código que hay que mantener que estudias de meter errores o de meter fallos de seguridad un código más seguro, un código más limpio y más fácil de mantener y hasta aquí hasta aquí lo que os estábamos contando jonathan alguna cosilla más que se me olvida algo que quieras comentar tu para despedirnos no ha sido un placer sobre todo que exploréis aunque no vayáis a migrar o todo lo que erais en el Grimfield explorad esta alternativa porque la verdad es muy interesante bueno es una tendencia que al menos hay que tener un ojo en ella porque realmente está dando bien duro un vaya que sí pues muchísimas gracias jonathan por estar aquí en oposición como es en vivo y nos vemos nos vemos en el próximo chau nos vemos nos vemos nos vemos