 Hola, Jonathan. Hola, ¿cómo estáis? ¿Hay echo? ¿Es porque estoy mal? ¿Tengo algo mal? No, no. Está bien. Ok, perfecto. Lo siento porque me lié y creí que estaba ahí, llevaba ahí el rato y... Perdón. Entonces, tú hoy es un ingeniero de software en RedHead, ¿correcto? Sí, sí, sí. Bueno, hasta hace poco trabajaba en el equipo de Migration Toolkit, pero desde hace tres meses ahora estoy en KeyCloud Cloud Native. Oh, I love KeyCloud. Ok, muy bueno. Entonces, por favor, puedes compartir tu pantalla. No voy a tomar mucho tiempo. Ok, bueno, estaré aquí. Ok. Nada. Pues nada, ante todo, muchas gracias a todos por estar aquí y espero que os sea amena e interesante y que, al menos, esta charla encienda una chispa de curiosidad y de ganas de aprender un poquito más sobre Quarkus y sobre cómo migrar desde Springputa Quarkus. Primero, os voy a presentar qué es lo que vais a ver. Primero, pues voy a presentarme a mí mismo para que sepáis quién os presenta. Luego, os voy a comentar qué es lo que podéis esperar de la presentación. Luego, un tema importante es por qué migrar de Springputa Quarkus. La verdad es que si pienso un poco se me ocurren 100.000 otras cosas que podría hacer con mi tiempo. Obviamente, llevo a la conclusión de que debo migrar, así que os explicaré cuáles son los pasos que seguí para migrar una aplicación existente en Springput a su réplica en Quarkus. Luego pasaremos a un tema interesante, y es decir, ok, yo decidí migrar basado en unas ideas, pero luego vamos a ver si eso que yo esperaba se cumple y qué grado se cumple. Finalmente, unas referencias de información que creo que puede ser útil para vosotros, para ir más allá y poder seguir qué migración hice, y si queréis, bueno, pues aprender un poco más. Y eso será todo, os enseñaré también una aplicación en la que yo trabajaba antes, que os puede ayudar también a hacer la migración, así que, pues nada, este señor que hay aquí al que le están pintando la cara, soy yo. Pues, bueno, soy Java Champion, soy co-leader en el Barcelona Java User Group, también cofundador de la conferencia JBCNConf, que es de julio pasado, decimos la sexta edición, y el julio del año que viene intentaremos hacer la presencial y será la séptima edición. Y bueno, trabajo como hemos dicho en Red Hat y soy co-leader del equipo de Keycloak en el subteam de Cloud Native. Tenéis mi Twitter, mi e-mail, el blog donde podéis encontrar información sobre esta migración y sobre otros asuntos, como test containers, por ejemplo, o como testear Apache Camel, o incluso como dar presentaciones, porque seguí un curso en Red Hat sobre ello. Así que, os invito a que visitéis el blog. Y por último, pues el link a mis proyectos de GitHub, donde encontraréis el código fuente para esta migración, y también todo lo referente a mi trabajo, porque todo lo hago allí en GitHub. Así que, ¿qué es lo que podéis esperar de esta charla? Lo digo para que penséis, si os preferís quedar o queréis ir a tomar un rato el aire o incluso queréis ir a buscar un blog de notas porque vais a querer tomar notas, ¿no? Vosotros decidís. Pues lo que vais a esperar aquí es simplemente mi opinión, mi experiencia migrando una aplicación y no os voy a dar ninguna charla magistral de nada. Es decir, no os voy a enseñar cómo hacer cosas. Os voy a mostrar cómo las hice yo. A partir de ahí, espero que vosotros pues aprendáis o simplemente busquéis otras mejores formas de hacer las cosas. También es algo que simplemente funciona. Es decir, no, el objetivo no era hacer una migración súper ideal y súper espectacular. Era intentar hacer una migración que costara el menor tiempo posible para ver qué resultado podía obtener. Y como ya os he dicho, no es la forma de hacer las cosas como diría nuestro amigo Mando. No es the way, así que espero que encontréis el vuestro y experimentéis y bueno, luego ya veremos y que podéis llegar a hacer diferentes combinaciones para hacer migraciones. Por cierto, las versiones utilizadas son para Spring Boot, fue la 2.4.2 y para Quarkus pues actualice el proyecto recientemente y está utilizando la versión 2.4.0 que es de hace poco. Para aquellos que no os sepáis todavía qué es Quarkus os voy a dar una pequeña introducción. A parte, durante mi presentación vais a ver imágenes de los juegos de los 80 y 90. Pues nada, si os hacen sonreír un pelín y viajar un poquito unos años atrás pues será divertido. Pues vamos con la descripción de Quarkus. Quarkus es un stack tecnológico que podéis utilizarlo con Java, Scala o Kotlin que básicamente es Kubernetes native, es decir se entiende perfectamente con Kubernetes y está pensado para que consuma poca memoria y sea muy rápido. Para ello tiene siempre un punto digamos así que lo define y es que siempre es compatible con Graalbian de tal manera que podemos generar artefactos nativos es decir, que corren sin necesidad de tener una máquina virtual instalada en la máquina. Corren en los dos sistemas tanto con código nativo como si queremos ejecutarlo dentro de una JVM y un punto muy importante que a mí es el que más me gustó de las diferentes opciones similares es que no está inventando la rueda. Es decir, desde el primer día lo que está haciendo es utilizar librerías open source que ya existen y que probablemente muchos de vosotros ya usáis desde hace mucho tiempo. Pongo por ejemplo Kafka Hibernate, Rest easy Overtex No está reinventando nada. Está utilizando librerías que ya estaban ahí. Simplemente las está optimizando para su posible compilación nativa y para reducir el trabajo que necesitan hacer en runtime. Los temas los puntos más importantes de Quarkus es aparte de los números lo importante es que os quedéis en que tiende a ser el código generado mucho más rápido que el habitual, pues ya va. Tiende a ser bastante más pequeño y un tema también muy importante es que está enfocado a que no necesitéis aprender mucho para poder empezar. Es decir, la curva de aprendizaje es pequeña a mí desde cero a poder hacer algo no me costó gran cosa y realmente se basa en interfaces que ya existen en librerías que ya existen así que no tuve que aprender gran cosa. Obviamente Open Source que eso es muy importante al menos desde mi punto de vista, tiene un tema muy importante y es que la cadencia de releases o de minor releases es muy alta de tal manera que están constantemente innovando y añadiendo librerías y mejorando el sistema así que es un elemento muy vivo, no es algo residual o que hay un pequeño grupo detrás y por último tiene un montón de extensiones ya funcionando para Quarkus, ahora veremos que son las extensiones. Pues estas extensiones no son más que esas librerías que os estoy comentando Open Source que ya habéis utilizado en otros proyectos que nada tenían que ver con Quarkus Kafka, Camel, Keycloak Spring, Vertex Rest easy, Micro Profile Open Shift pero hasta 150, bueno más de 150 es decir hay un montón de librerías ya utilizando esto y aparte existe lo que se le llama el Quarkiverse que es un repositorio donde otras compañías otras comunidades, otras personas están añadiendo extensiones o elementos que enriquecen el universo de Quarkus así que es un elemento muy vivo y que no solo tiene contribuciones de Red Hat. Para dar un poquito de idea de la evolución, pues a finales de 2018 es cuando empezó Quarkus la primera release y más o menos en un año se pasó a la primera release en seis meses se pasó, perdón de la primera release se ha necesitado un año y medio para pasar a la release 2 y hasta la que estamos ahora que es la 241 han sido necesarios 5 meses para pasar de la 2 a la 241 pero me refiero que hay infinidad de minor releases o los he mostrado las grandes y para que veas que es un proyecto super vivo esta es la imagen que acostumbra a acompañar cualquier presentación sobre Quarkus y básicamente aparte de los números que son muy susceptibles de ser afectados por la configuración de la máquina, por las estrellas, lo que sea la idea es que en una aplicación tradicional con Java podemos estar del orden de 140 MB da igual lo que haga esa aplicación el tema es que la misma aplicación ofreciendo el mismo valor es decir haciendo la misma funcionalidad si la pasamos a Quarkus y seguimos ejecutando en la JVM pasamos a la mitad más o menos pero si el mismo código pasamos a nativo estamos pasando de 74 por decir algo a 12, es decir estamos yendo de 140 a 12 quiere decir que estamos yendo más de 10 veces menos en cuanto a la memoria que está consumiendo es importante porque donde teniais dos servicios ahora podéis tener 10, ocupando la misma memoria tenete en cuenta que al final los resursos, tanto memoria como CPU es dinero, así que esto es un tema también importante en cuanto a en cuanto a a la velocidad de respuesta pues, mirad desde más de 4 segundos a un segundo y de un segundo pasamos a 16 milisegundos, es decir estamos pasando de unas magnitudes a otras que son muy diferentes por lo tanto ahora podéis plantearos por ejemplo, poner vuestras aplicaciones en Java como librerías en serverless cosa que antes teniais que hacer con Python o Node.js ahora lo podéis hacer con Java porque el tiempo que va a consumir es realmente interesante para moverse a ese espacio así que, bueno, esta es la idea para que lo tengáis presente y por cierto para pasar de Quarkus JVM a Quarkus nativo básicamente lo único que hay que hacer es añadir en la línea de comando de Maven menos D menos P native eso es todo, no tenéis que tocar el código no tenéis que hacer nada más para que tengáis una idea de el proyecto de Quarkus bueno, simplemente he cogido un mes y aquí veis la cantidad de issues que se están cerrando, abriendo realmente es proyecto muy vivo ya hay más de 500 contributores al proyecto lo cual cada mes van subiendo y van subiendo estos contributores así que da idea de lo vivo que está el proyecto como os comenté, el Quarkiverse Hub que es un lugar para poner las extensiones aquí como veis ya hay 39 repositorios dentro de este Hub es decir, es un tema muy vivo en cuanto a la migración y es muy interesante esta imagen porque yo nunca llegué al Stage 2 de este juego pero me gustó ponerlo aquí vamos a ver y por qué decidí yo migrar porque mi experiencia con Spring Boot es que es muy fácil desarrollar perfecto pero tarda mucho en arrancar los tests se hacen eternos y la aplicación que generaba era muy grande y consumía mucha memoria y luego hay un montón de cosas que suceden que no, de las cuales no soy consciente pero que así vais al lock veréis un montón de cosas que suceden que en ningún momento yo había especificado en cambio a mí se me comentó que Quarkus pues era fácil generaba un artefacto que era rápido en arrancar que era ligero en memoria y que era compatible con Grail para producir artefactos nativos y que por tanto podíamos ir a serverless y que por tanto eso al final implicaba menos dinero invertido en Clouds Públicos pues entonces lo que decidí fue coger una aplicación de Spring la Spring Pet Clinic Rest que contiene estos módulos Spring Data, Spring Web, Security Documentation actuators, MicroMetal, CDI, AOP y Cache porque creí que bueno esto más o menos es lo muy habitual la mayoría de proyectos con Spring que sean rest tendrán todos estos módulos muy probablemente pues la su correspondencia con Quarkus es Hibernate Panache, JAXRS Quarkus Security, OpenAPI Small Right Hell Micro Profile Metrics la especificación CDI no hay opción de utilizar AOP y luego Quarkus Cache que es una librería llamada Caffeine que es la que nos da el Local Cache pues vamos a hablar así rápidamente de los steps de migración para que veáis lo difícil y lo fácil que es pues básicamente para cualquier bin si seguíais utilizando el AutoWire vamos a pasar a la anotación la estándar Inject para la definición de los bins en vez de utilizar el Component el Service, vamos a utilizar Application Scope en la mayoría de nuestros bins y ya está y voilà, vamos a tener la auto injection en los constructores y además es lazy by default, así que es interesante para arrancar rápido en este caso no encontré absolutamente ningún problema, todo fue fácil incluso podemos hacer que los bins que se van a inyectar dependan del Profile que se está pasando en la ejecución o bien una propiedad de la configuración y de esa manera pues nos generará un artefacto u otro no hay miembros privados en la inyección es decir, todos los donde inyectemos tiene que ser al menos Package en cuanto a los repositorios JPA, es decir la conexión con la base de datos, pues en este caso es simplemente utilizar generar clases de repositorio basadas en el Panarch Repositori en este caso, yo me fui a Panarch Repositori Base porque la clase tipo para Identity de cada Entity es el Long pero en cambio, en la versión esta que teníamos en Spring estamos usando Integer, entonces para no tener que tocar todo el código pues lo que hice fue modificar irme a Repositori Base y aquí especifico que el Integer es la clase para el Identity y ya está con esto vamos a tener los métodos habituales para persistir, para listar, para encontrar para borrar las entidades fácilmente lo único que no tenemos son los Direct Query Methods, esos de Find by Name and Age bla, bla, bla pues esos no los tenemos, hay que crear nuestros métodos con una anotación para inyectar la query pero bueno, yo casi que prefiero esa otra cosa en cuanto a Spring Rest hay que pasarlo a Jacksrs bueno, hay que obviamente hacer un Stream Replays de las anotaciones y en el caso que ya has utilizado un Request Mapping Annotation para Spring hay que dividirlo en las anotaciones individuales de Jacksrs porque la Request Mapping puede contener los tres elementos pero básicamente es un Stream Replays y poca cosa más lo demás funciona bien no hay nada que mencionar en cuanto a la seguridad es simplemente utilizar Quarkus Security y tenemos prácticamente lo mismo donde un sitio es pre-authorized en el otro es Rolls-Allowed la única así cosa diferente es que pre-authorized te permitía utilizar expresiones como veis aquí el Has Roll y en cambio el Rolls-Allowed lo que me hace es identificarle la lista de roles que están aceptados pero en este caso este proyecto no era ningún problema pero esta seguridad del proyecto estaba persistida en una base de datos es decir, los usuarios, los roles los pasos estaban en base de datos por lo único que tenemos que hacer es utilizar a Litron Security y entonces esto lo que hará será que la seguridad la va a ir a buscar a la base de datos no hay ni que programa siquiera con el fichero de Properties especificando los diferentes elementos y ya está, no tiene más misterios especifica el acuery para obtener cada elemento y ya está lo único que no tiene es, como ya os he comentado son los language expressions en cuanto al Cross Origin es fácil simplemente añadir estas dos Properties en el fichero Properties y ya está la única diferencia que encontré es que en Spring podías especificar el Cores a nivel de controlador y en Quarkus al menos yo no supe la manera de hacerlo y parece que es a nivel global pero por lo demás, nada más en cuanto a las métricas simplemente añadimos las tensiones More Right Metrics y tendremos las más o menos las mismas métricas como podéis ver, izquierda Spring Boot derecha Quarkus es prácticamente lo mismo si queremos tener más compatibilidad con la salida de las métricas podemos poner una property como veis abajo en el properties para hacer compatible el output con Micrometer que es lo que utiliza Spring y de esa manera tendremos una anotación muy parecida porque si no, no son iguales y luego para tener Custom Metrics como veis aquí las anotaciones pero esto ya es Micro Profile utilizáis las anotaciones y tendréis las métricas Custom incluso si queréis un poquito más allá se trata de utilizar la extensión de Micrometer y así ya tendréis exactamente lo mismo y si tuvierais métricas personalizadas ya no tendríais ni que tocarlas así que la única diferencia es que como ya os comenté al principio no hay AOP aspecto Oriented en Quarkus y en este proyecto la AOP se utilizaba para obtener las métricas de acceso a los datos que con una línea es muy fácil afectar un montón de métodos y obtener los timings sobre todo pero ahora veremos como podemos hacer lo mismo en cuanto a la validación pues vamos a pasar Spring Validation at Hibernate Validator y es prácticamente igual simplemente que en el caso de Quarkus pues vamos a utilizar un Provider de CDI y vamos a implementar Exception Mapper y el cuerpo del método va a ser muy muy muy parecido en cuanto a Swagger y la documentación de la API pues es muy sencillo añadís la extensión de OpenApp y voilà si luego queréis personalizar un poco más para que haya pues un título, una descripción lo que queráis perdón, para vuestra API simplemente creáis una clase que extienda la resta application y ya está le añadís esas anotaciones o bien hacéis lo mismo pero utilizando las properties en vuestro fichero de properties como lo veis a la derecha es muy sencillo es una migración directa súper fácil además tenemos el Swagger UI out of the box para el testing y si lo queréis para producción también lo podéis activar la única cosa que yo no encontré es que tú podías especificar qué paquetes escanear para encontrar los controladores en el caso de que quieras esconder algún endpoint en el caso de Quarkus yo no encontré la forma de hacerlo es la única diferencia como os había comentado teníamos la aspecto oriente para las métricas como veis a la izquierda estamos generando un aspecto y decimos que todos las clases del interface repository esto afecta a todas esas clases y vamos a hacer que en todos los métodos estamos teniendo un stopwatch para ver cuánto tiempo darle esto no lo podemos hacer de una forma directa o bien anotamos mano a mano cada uno de los métodos para tener estos tiempos o bien lo utilizamos interceptores de CDI que lo que vamos a hacer va a ser algo parecido a esto o bien hacemos algo mucho más sencillo que es para obtener el mismo resultado que es tener métricas de acceso a datos hibernate nos da una property que si la activamos automáticamente tendremos aquellas métricas que teníamos en una sprint y muchas más en la salida de métricas cosa que es súper súper interesante y que además en la otra opción no teníamos aquí es muy fácil, una línea en el properties y ya está, ya lo tenemos como ya os he comentado no tenemos la AOP así que tendríamos que utilizar algunas de las dos opciones interceptores o métodos manuales anotando cada uno de los métodos en cuanto al catching pues utilizan una una aproximación parecida en este caso vamos a utilizar Caffeine, que utiliza un concurso en Linked Hatch Map pero que es básicamente lo mismo y nada, es añadir la extensión y luego hacer un replays de la anotación y colocar el catch result y ponemos el nombre del catch que si luego queremos podemos personalizarlo en las properties la capacidad inicial o el tamaño máximo para ese para ese catch muy fácil la verdad en cuanto al testing aquí ya vienen las cosas un poco más duras en cuanto al testing hay que cambiarlo todo ¿Por qué? porque en este caso estamos pasando de Mock and Visit al Rest Assure y el código como podéis ver no se parecen en nada bueno, de todas formas yo prefiero el de Rest Assure me siento mucho más cómodo incluso antes de utilizar Quarkus y la verdad estoy bastante... me siento muy cómodo con él puede ser que incluso en vuestra aplicación Spring pudiera usar Rest Assure no lo sé total, en resumen es que hay que cambiar el código a la librería standard, claro con Mock and Visit como es propietario de Spring pues no podemos utilizarlo las diferencias en Spring permitía la opción de simular roles sin tener que crear usuarios para testear el acceso a métodos con Quarkus al menos yo no encontré la forma y lo que hacía era crear unos usuarios de test asignados a unos roles y entonces inyectaba el usuario y a partir de ahí testeaba bueno al final no hubo mayor problema pero es la diferencia y luego, bueno, si lo podéis cambiar pero básicamente el lenguaje de expresión para comprobar los valores del body retornado cambia de JSON Path a GPath que son parecidos pero no son iguales en cuanto a los terresurses pues obviamente cuando estamos en testing no vamos a levantar bases de datos enteras lo que vamos a hacer va a ser levantar unas bases de datos de test en este caso vamos a utilizar Quarkus Test para tener un test y Quarkus Terresurs para levantar una base de datos de memoria en este caso vamos a levantar una base de datos h2 y esto lo que hará es que cuando se levanta el test se levantará la base de datos h2 en memoria y nuestro test ejecutará contra esa base de datos yo prefiero utilizar test containers para tener bases de datos reales que están corriendo en contenedores pero no hay problema también podéis utilizar esta aproximación en cuanto a los mocs pues es muy fácil simplemente Quarkus Unit 5 moquitos la extensión que hay que añadir y entonces pues nada podéis inyectar vuestros bins y automáticamente tendréis un mock para ese bin muy sencillo y hemos llegado a un punto en el que os digo que os olvidéis de todo lo que os he dicho que es más fácil de migrar una aplicación Spring a Quarkus y que implica invertir mucho menos tiempo ¿cuál es esa opción? ¿puedes utilizar las extensiones Spring de Quarkus? ¿qué son estas extensiones? bueno pues en realidad Quarkus genera toda una serie de interfaces que son iguales a los interfaces de Spring de tal manera que para vuestro código todo funciona igual porque hay alguien que responde a ese interface pero Quarkus en tiempo de compilación va a generar el código que realmente necesita tal manera que para vuestro código es transparente tenemos extensiones para inyección de dependencias para web, para data jpa, para rest para security para cloud config para las properties para el catch y para el schedule así que tenemos un montón de extensiones para no tener que casi ni tocar nuestro código por ejemplo si utilizáis Spring web pues no hay que tocar nada de vuestro código automáticamente la extensión de Spring web soporta todas estas anotaciones y no vais a tener que tocar nada en cuanto a la dependencia de inyecciones la inyección de dependencias perdón pues es lo mismo hay todo lo que soporta la extensión un montón de anotaciones y no tenéis que tocar esa clase hay que puntualizar que para cada una de estas extensiones tenéis que revisar bien aquellos puntos que no cubre de tal manera que puede ser que si estáis utilizando algo muy explícito o bueno algo muy concreto que la extensión no cubre o un caso un cornercase que se llama en algunos casos no son el más común pues puede ser que no sea lo más adecuado pero en la mayoría de los casos la extensión funcionará perfectamente y no tendréis que tocar nada en cuanto al Spring Data lo mismo no tenéis que tocar vuestras vuestros entities perdón vuestros repositoris vuestros JPA repositoris e incluso en este caso pues los métodos de querydsl funcionan así que no tenéis que complicaros la vida no tocais nada y vuestro código funciona directamente en Quarkus con Spring Security lo mismo aquí tenéis todas las expresiones que se permiten y todas las notaciones es decir incluso en este caso las expresiones para los roles están soportadas así que no hay que tocar nada y tenéis vuestro código pues lo que hice fue coger esa aplicación de Spring la compilé la ejecuté cogí la aplicación de Spring migrada a Quarkus estándar la primera parte de la presentación lo mismo compilé y ejecuté luego la pasé a nativa compilé y ejecuté y luego cogí la versión en Spring con las extensiones de Spring en nativo y la compilé y ejecuté aquí tenéis los tiempos el tiempo de generación de construcción es alto cuando vamos a nativo es muy alto comparativamente porque tiene que hacer un montón de cosas en tiempo de construcción ya Quarkus multiplica por 3 el tiempo de compilación en realidad esta es la gran ventaja mucho de lo que hace Spring en Runtime Quarkus lo hace en build time por eso cuando se están ejecutando en teoría Quarkus tarda mucho menos pero sinceramente yo no estoy preocupado por el build time porque además eso se lo dejo a mi entorno de si hay y no es algo que yo haga yo si estoy en test utilizaré el Quarkus dep que lo que hace es ejecuta la aplicación y automáticamente yo voy modificando mis clases y él va modificando las clases en esa ejecución así que puedo testear muy fácil no tengo que compilar todo cada vez una serie de cosas lo que estoy preocupado es que en tiempo de ejecución como va a funcionar y especialmente esto en un cluster pues el tiempo de ejecución en Spring son casi 5 segundos y consume 630 mb si en JBM con Quarkus estamos pasando a 3,4 segundos es decir 1,5 segundos ya que Spring y consume la mitad de memoria pero si nos vamos a nativo pues resulta que estamos pasando a medio segundo con 21 MB y en el Quarkus estándar y más o menos el mismo tiempo no le hagáis mucho caso a la diferencia más o menos son el mismo tiempo todo depende del momento de cómo esté la máquina pero lo que es importante es el orden de magnitud no el número exacto y concreto estamos hablando que de una magnitud de alrededor de 5 segundos pasamos a un segundo y algo menos con JBM en Quarkus y pasamos a fracciones de segundo en nativo y estamos cambiando el paradigma completamente porque hay que tener en cuenta que esto lo que hace es levantarse, crear todas las tablas en Postgre y luego rellenar los datos y luego levantar todos los controladores y todo lo que haga falta así que realmente para mí es impresionante la diferencia y ahora lo que me gustaría compartir con vosotros y vosotras es un conjunto de referencias pues para empezar el repositorio de Spring y el de Quarkus básicamente está en mi usuario y tenéis la rama Quarkus donde está el proyecto migrado a Quarkus luego tenéis otra rama que es Quarkus Spring o Spring Extensions no recuerdo y es donde tengo el código que está usando las extensiones de Spring luego tenéis la página de Quarkus en la cuenta de Twitter es muy interesante en Developer Red Hat hay un montón de tutoriales e información que podéis utilizar para formaros sobre Quarkus luego el mailing list donde os podrán ayudar un montón de gente que está siguiendo Quarkus luego los tutoriales interactivos os lo recomiendo mucho porque tenéis el tutorial que os da información y luego tenéis una IDE y luego tenéis incluso una consola de OpenShift para ver la ejecución y ver cómo está funcionando y no tocais nada de vuestra máquina y aprendéis desde empezar hasta las extensiones de Spring utilizar Kafka Hibernate o Prometheus hay un montón de tutoriales luego tenemos Quarchit que la publica mi colega y amigo Alexoto que os recomiendo completamente que las sigáis porque todas las versiones él va publicando las diferencias que hay con cada una de ellas luego si queréis empezar a programar con Quarkus pues vais a code.quarkus.io seleccionaréis librerías las tecnologías que queréis usar y ahora automáticamente os generará un zip o incluso os creará un Github con toda la estructura inicial a partir de la cual podéis ejecutar incluso os genera los dockerfile todo lo configurable para el POM y para los la compilación nativa para seguir os quería mostrar una aplicación que se llama MTA Migration Toolkit for Applications es una aplicación open source free que podéis descargar y usar como queráis que en realidad lo que hace es analizar estáticamente aplicaciones y dependiendo de lo que le llamamos migration paths es decir desde donde quiero migrar hasta donde quiero migrar analizará el código y os propondrá todos los cambios que tenéis que realizar hay un montón de tecnologías a cubrir desde camel a cloud native de oracle JDK adoptable in JDK hay un montón de migration paths pero el de quarkus cubre un montón de elementos para migrar desde spring a quarkus y lo que hace es daros una idea de de magnitud de la migración os dice cuántos issues tenéis y cuántos más o menos total story points tenéis para cada migración para cada fichero que está incumpliendo o que tiene una sugerencia os mostrará pues todas las sugerencias y los ficheros afectados y dentro de cada fichero veréis la línea de código que está afectada por ese cambio y pues el cambio que os propone e incluso un link a la guía de la que habla para cómo hacer ese cambio también existe un plugin para clipsche clipsche y vscode que hace lo mismo pero analiza directamente el código fuente y podéis aplicar incluso los quick fixes directamente en vuestro código ya casi que por último os quiero aconsejar que visitéis estos links de compañías grandes y reales que ya han hecho migraciones de spring a quarkus sobre todo la de bodafón en Grecia que migró todo spring boot a quarkus y obtuvo muchísima ventaja así que es importante también ver experiencias grandes compañías que ya lo han adoptado que no es algo que se adopta en startups y en pequeños proyectos sino que se hacen en grandes compañías también y ahora sí por último pues nada me gusta acabar mis charlas recomendando libros que nada tienen que ver con esta presentación así que si queréis leeros alguna novela pues tenéis la catedral del mar me encantó muchísimo el último catón también fantástico sobre cómo funciona nuestro cerebro pues thinking fast and slow que es muy bueno y drive sobre motivación y sobre ciencia ficción el congreso de futurología es un libro pequeño de Stanislav Lev que lo conoceréis por Solaris es muy divertido y muy interesante o Ubik de Philip Kadik que es fantástico sobre realidad simulada y eso fue todo muchísimas gracias a todos por estar ahí si tenéis preguntas pues la responderé y si no pues podéis preguntarme a twitter o a mi email me podéis contactar como queréis muchas gracias por todo