 Bienvenido, buenos días, buenas tardes, buenas noches. Dependiendo en dónde están, bienvenido al OpenShift Commons en vivo. Hoy tenemos Miguel Perez Colino y Roman Nissen para explicar un poquito de OpenShift MTA. Es un sujeto muy interesante porque hay mucha gente que quiere saber cómo puedo mover las aplicaciones al contenedores y ahora estamos compartiendo un poquito de información sobre una herramienta que se llama MTA. Y con eso yo introduzco a ellos y, ya, Dinos, ¿qué ustedes tienen para nosotros hoy? Hola, Scott. Pues, bueno, primero me presento y dejo que se presente Ramón. Soy Miguel Perez Colino y soy el Product Manager de MTA o Migration Toolkit for Applications, el Toolkit de Migración de Aplicaciones que estamos desarrollando en Red Hat. Y, bueno, Ramón, ¿qué es presentar de tú? Bueno, yo soy Ramón Robán, soy arquitecto senior de desarrollo de aplicaciones del equipo de Iberia Consulting aquí en España. Como puedes ver por nuestro acento, españoles de España y uno más soy del sur, así que espero que se entienda mi acento. ¿De qué? Claro, más o menos. Vamos a ver si conseguimos no decir palabras más orantes de Sudamérica y adaptarnos a nuestros compañeros de LATAM, a los que mandamos un saludo muy grande y os contamos más cosas de MTA. ¿Puedes pasar de positiva, Ramón? Gracias. Lo primero de MTA, los casos de uso. MTA, pues, como decimos, es para revisar el código de las aplicaciones. Aquí no hacemos magia ni de ponemos polvos de estrellas, sino que realmente queremos ayudar a modernizar las aplicaciones. Y los casos que tratamos son, sobre todo, pues eso, todo lo que sea modernización, que estás utilizando una máquina JVM de Java que sea de oracle, por ejemplo, y estás usando clases de propietarias, pues, a lo mejor, te lo quieres traer a OpenJDK y utilizar solo clases abiertas. Si tienes middleware de terceros, como puede ser WebLogic, por ejemplo, y quieres traerlo a JVM API, JVM API, pues puedes utilizarlo y también traerlo. Si estás usando Tomcat, si estás usando Spring Boot y quieres usar el Tomcat que se utiliza dentro de OpenJDK, también te ayuda. Si estás usando cosas de comunidad y dices, ay, Dios mío, lo voy a poner en producción y quiero soporte, ¿cómo lo hago? Pues también te ayudamos. Y luego, hay un caso nuevo que es Apache Camel, la gente que está utilizando patrones de integración con Apache Camel 2 y quiere pasarse a Apache Camel 3. Apache Camel 3 es mucho más amigable con respecto a lo que es ponerlo en contenedores y utilizarlo en Kubernetes y proporcionar, por ejemplo, puntos de lanzamiento de serverless con lo que sería sus patrones de integración, pues, todo lo que tengas en Apache Camel 2, utiliza SMTA y te ayuda a traer todo a Camel 3. ¿Qué más? Pues conterizar aplicaciones, ayuda también a romper aplicaciones masivas, o sea, en los monolitos, dentro en microservicios y, sobre todo, aumentar y extender con integración a Heel, allá de la intervención. ¿Diguiente? Hasta aquí bien, ¿no, Scott? Sí, está bien. Sí. Vale. Bueno, pues entonces, te cuento un poco de las herramientas, ¿vale? Tenemos varias herramientas. Siguiente, por favor. Y todas están enfocadas a lo que es modernización y migración. Normalmente lo ponemos junto, porque te vas a traer código, si quieres hacerlo bien, tienes que tocar un poquito el código. Si quieres, realmente, que se adapte al nuevo contexto, lo bueno es que realmente hacemos que el código sea más portable. Entonces, empezamos desde la primera fase de saber qué es lo que tienes en tu infraestructura. Para eso, tenemos Migration Analytics, que es una herramienta que se conecta a tu vicenter de VMware y te extrae la información y te dice, mira, esto es lo que tienes. Y estas son tus posibilidades, ¿no? Por ejemplo, te detecta si tienes Oracle JKS, cuántos weblogics tienes desplegados, cuántos webseers, si tienes algún Tomcat y dices, bueno, y ahora con todo esto ya puedo hacer una idea. Si tú lo que quieres es hacer un asesment de alto nivel y decir, a ver, ¿cómo estamos en esta empresa a nivel de organización y demás, y poder evaluar tu status, ¿no? Respecto a lo que sería el estado medio de tu vertical, por ejemplo, si estás en banca o en seguros o en retail, pues tienes Ready to Innovate. Y luego, cuando ya dices, no, lo que vamos a hacer es migración de aplicaciones y quiero elegir con qué aplicaciones quiero comenzar. Para eso tienes Pathfinder. Pathfinder lo que hace es, son una serie de preguntas que llevamos muchos años utilizando en todos los trabajos que hacemos de migración con los clientes y que después de años y años y años las hemos ido mejorando, curando y empaquetando hasta el punto de que hemos hecho una aplicación para capturar toda esta información sobre aplicaciones y ayudar a los clientes a decidir por dónde empezar, ¿no? Que empezamos por este grupo de aplicaciones que parecen más complicadas pero que dan mucho más beneficio o empezamos con estas que son más sencillas, no quieren menos beneficio o lo mejor si es posible, ¿no? Encontrar una serie de aplicaciones que son sencillas y tienen mucho beneficio. Una vez que hemos decidido qué queremos migrar, pues vamos al cómo. Y para eso está Migration Turkey for Applications, el turkey de migración de aplicaciones. Que lo que haces es coger tu código Java o también los binarios, si no tienes el código puedes utilizar los binarios, los analiza y te producen los resultados pues para saber dónde tienes que tocar y cómo. Pero eso nos lo va a contar a la mano. ¿Piguente? Pues sí, vamos allá. Si quieres, nos lo cuentas, Ramón. Sí, vamos allá. Bueno, Migration Turkey for Applications, lo primero que os quería decir es que, bueno, la herramienta en realidad ya lleva tiempo en el mercado siendo disponible. Lo que pasa es que lo mismo suena con otro nombre. Antes se llamaba Red Hat Application Migration Turkey. Era un nombre un poco larguillo si me preguntas. Incluso puede sonar como WINDUP, que es el proyecto upstream del que nació la herramienta. Yo personalmente lo he estado utilizando durante años en grandes proyectos de migración. Y cuando digo grandes proyectos de migración, estoy hablando de migración de cientos, incluso miles de aplicaciones en el contexto de clientes. Entonces, vamos a ver un poco de qué va el tema. Bueno, Miguel ya os ha adelantado. Es una herramienta para hacer análisis automatizado de aplicaciones para ver un posible camino de migración hacia un destino concreto. Y, como decía Miguel, se pueden utilizar tanto el código fuente como binarios ya construidos de esas aplicaciones. La idea de la aplicación es permitirte conocer el lab que tienes entre una tecnología origen, por ejemplo, WebSphere o WebLogic o versiones antiguas de JVOS y IP incluso y una tecnología de destino. Y, además, de permitirte conocer ese lab, te permite determinar cuál sería el esfuerzo para realizar esa migración desde el origen al destino. También quiero dejar claro que no necesariamente estamos hablando de migraciones entre servidores de aplicaciones. Digamos, ese fue el origen de la herramienta, pero ha evolucionado muchísimo el tiempo. Y, por ejemplo, también aplica para realizar análisis de Cloud Regulates de una aplicación si está preparada para irse al cloud o, incluso, en las últimas versiones estamos desarrollando reglas para pasar aplicaciones de Spring Boot hacia Quarkus, nuestro framework de desarrollo Cloud. Como decía antes, ya ha abusado nuestra herramienta unos cuantos años en esos grandes proyectos de migración. Y lo que quería era compartir con vosotros un par de casos reales que yo mismo como arquitecto me he encontrado en clientes y en los que he utilizado la herramienta y me ha resultado útil. El primero de ellos es un cliente de administración pública. Y, bueno, ellos se habían desarrollado su propia arquitectura custom utilizando WebLogic y, bueno, las tuvimos utilizando durante una serie de años. Y en un determinado momento, como es bastante frecuente, pues, se vieron que tenían la necesidad de salir de WebLogic básicamente por los costes de licenciamiento de Oracle, y intentaron hacer la migración ellos mismos varias veces hacia JBOG y IP. Y cuando digo varias veces es porque fracasaron en esos intentos. No conseguían hacer que esas aplicaciones se ejecutaran fuera de WebLogic. Al final, hablaron con nosotros y nos pidieron que les echáramos una mano. Y la herramienta que utilizamos básicamente fue este MTA. Y lo que hicimos fue utilizarla para detectar cuáles eran los puntos de acoplamiento de esa arquitectura, de ese conjunto de aplicaciones con WebLogic. Una vez que teníamos determinados esos puntos de acoplamiento, fuimos capaces de hacer las modificaciones necesarias y solo las modificaciones necesarias para hacer que ese código, esas aplicaciones, funcionaran en este caso concreto en EAPSI. Como os he dicho antes, el utilizar MTA no tiene porque ser siempre en el contexto de servidores de aplicaciones. Os voy a contar otro caso, bastante reciente de hecho, que fue con un gran cliente del sector de retail. Y ellos lo que estaban haciendo era una migración de plataformas de control. Se estaban yendo desde DCOS, de Mesosphere DCOS a OpenShift. Y una vez que montaron la nueva plataforma de OpenShift, querían mover subcarga desde DCOS a la nueva plataforma OpenShift. En este caso, se trataban de aplicaciones modernas, ya estaban containerizadas, estaban desarrolladas con Spring Boot. Y ellos estaban utilizando imágenes custom que han construido ellos mismos con Oracle JDK. Claro, como parte de la migración y para tener su suporte completo, la idea era mover esas aplicaciones y colocarlas sobre contenedores con imágenes base, con su suporte, como OpenJDK. Entonces, bueno, hay un gap entre la JK de Oracle y OpenJDK. Y lo que hicimos fue utilizar MTA para detectar, para asegurarnos de que no se nos quedaba nada en el tintero al hacer el cambio de JDK. Y además también utilizamos para asegurarnos que las aplicaciones eran cloud-ready. Porque que una aplicación se containerizaba no necesariamente quiere decir que sea cloud-ready de verdad. Y os puedo decir que me he encontrado cosas de los más varios pintas, como IPs, estáticas o rutas a ceros puntos, no sé qué. O sea, que eso también nos aporta mucho valor para ir sobreseguro en esa migración. Vamos a entrar en detalle. Dime. ¿Os lo quería preguntar algo, tonta? ¿Si funciona con Quarkos? Sí, sí, efectivamente. Sí, sí, sí. En las últimas versiones ya incluyen un set de reglas para hacer migración desde Spring Boot hacia Quarkos. Tenemos un slide para eso, Scott. Te lo cuento nuevo. Me has pillado, me has pillado. Bueno, eso es que resulta interesante y ya empiezan a surgir las primeras dudas. Vamos al dios y voy a contaros ya detalles concretos sobre la herramienta. Bueno, lo primero de todo deciros que hay varias formas en las que se puede utilizar el MTA y varios sabores de la herramienta. La más típica, la más sencilla también, sería el CLI, una línea de comando, muy sencillita. Y la verdad es que poco hay que explicar aquí. Básicamente, en tu línea de comando indicarías dónde se encuentran esos artefactos a analizar y pasarías para métodos de análisis, como cuál es la tecnología de origen y cuál es la tecnología de estino, por ejemplo. Y bueno, el output final sería un répor HTML que luego veremos. Yo enseñaré algunos ejemplos y Miguel lo va a enseñar funcionando todo en una demo. Le he pedido a Ramón que me dejará hacer la demo de algo, por favor, anda, déjame. Venga, vale, pues nada más. Gracias, Ramón. Miguel es todo un experto haciendo la demo y él seguro que lo hace mucho más divertido, más entretenida que yo. A ver, el tener este CLI, este CLI, o como queramos decirlo, es interesante porque permite integrar esos análisis de la herramienta del MTA, ejemplo, dentro de pipeline de 6D. Y aquí me voy a volver otra vez a mi experiencia. Hace unos meses tuve un cliente con el que estábamos ejecutando una migración masiva, también del sector retail, no es el mismo que el de antes, que tenía montado una serie de pipelines en Albu, en Albas en Bamboo, para que sus desarrolladores pudieran hacer análisis bajo demanda de aplicaciones para ver el gap, sin necesidad de tener que montarse la herramienta en local. Para hacer este tipo de análisis, digamos, dentro del contexto de una pipeline, pues puedes utilizar la propia CLI, instalar en algún tipo de agente de esa herramienta de 6D, o incluso si no quieres meterte en el día de tener que instalar en un agente, puedes utilizar el plugin de Maven, y hacer que ese análisis se ejecute dentro del contexto de un build de Maven. Claro, si lo que quieres es tener un lugar centralizado para poder, bajo demanda, y guardarlo resultados, pues hay una solución mejor que tener que integrarlo dentro de un pipeline, pero bueno, para gusto acudir, y eso fue una decisión de este cliente. Pero para hacerlo mejor todavía y más sencillo de utilizar, pues para eso tenemos la web console de MTA. Es especialmente interesante, como decía, cuando quieres tener un punto central y sobre todo compartido para guardar el resultado de esos análisis, y simplificar la integración de los desarrolladores con la herramienta, al final estás utilizando la interfaz visual, no tienes que andar picando comandos y demás, y bueno, hace que las demos de Miguel sean más chulas también, con lo cual me imagino que tiraremos por aquí al diseñado el análisis. Más cosas sobre la consola web, bueno, deciros, pues como decía, como es un punto central donde se van guardando todos los análisis que se van haciendo, pues desde esa misma consola puedes navegar directamente los distintos reportes de los análisis que has ido ejecutando, y no tienes que andar buscando ten directorios o mirar cómo te comparto este análisis, es que no sé dónde me lo has puesto, una carpeta compartida. De esta manera todo es mucho más sencillo y estás entrevistado. Y os he comentado ya con la CLI, con Maven, con la web console que el resultado es un reporte de ese análisis. ¿Qué es lo que obtenemos en ese reporte? Pues como podéis ver, la idea es proporcionar una estimación del esfuerzo necesario para migrar cada aplicación, y como hacemos esta estimación, pues pasándonos en story points. Pero no es lo único que se obtiene con, hay un montón de cosas, Miguel os enseñará muchas de ellas. Voy a enseñar hoy algunas, por ejemplo, puedes obtener un grafo de dependencia de cada una de sus aplicaciones como artefactos de tercero. O para mí lo más interesante es que tienes sugerencias de cómo resolver cada una de las incidencias, las issues, es decir, esos elementos o esas partes del código que tienes que modificar para que eso funcione bien en el entorno destino, por esas sugerencias de qué es lo que tienes que cambiar y cómo cambiarnos, las tienes directamente sobre tu código fuente. No es algo que sea así en genérico, deberían mirar, que no sé qué no se cuenta, sino que tienes sobre tu propio código fuente, esto concreto tienes que cambiarlo de esta manera. Pues eso, la idea al final de la herramienta es proporcionar una solución concreta para cada uno de estos issues o de estos elementos que tienes que cambiar, que vaya encontrando dentro de tu código. ¿Y cómo lo hacemos eso? Con Miguel ya ha dicho antes y ha adelantado que esto no es magia para nada. Básicamente, esto funciona. La manera que tenemos de detectar esos issues y de proponer soluciones para ellos es utilizando un conjunto de reglas. Y esa regla de dónde han salido, es un señor que se ha sentado y se ha puesto a picar reglas porque era muy listo. Pues la verdad que no. Las reglas las hemos ido creando desde el equipo de Consulting de Red Hat, pues a base de muchos años haciendo proyectos de migración. ¿Sólo hemos hecho nosotros? No, porque como todas nuestras herramientas, estos open source y hay una comunidad de track que ha ido aportando reglas y enriqueciendo este sistema para simplificar el proceso de migración. Claro, la base de datos de reglas que tenemos es muy grande, pero de todas maneras si te falta algo, pues es bastante sencillo definirte tú mismo tus reglas custom. Incluso en el caso de que se trabajan un cliente concreto en tu propia compañía y sea algo muy concreto tuyo. Y eso te lo aterrizo como un ejemplo. Imaginaos que un cliente o que vosotros en vuestra compañía utilizáis vuestros propios framework corporativos que habéis desarrollado vosotros y alguno de los elementos que hay que migrar, pues está integrado con alguna pieza propia que debe migrarse de una manera muy concreta, alguna pieza propia vuestra que al migrarse al entorno destino debe migrarse de una manera concreta. Podemos hacer nuestra propia regla que detecte este tipo de elementos y cuando aparezca, pues que nos ponga un puntero a un determinado artículo clicando como se debe migrar. Y con artículo me refiero a nosotros en Consulting, la metodología que tenemos para migrar es construir una gran base de conocimiento de cómo se hacen las migraciones en el contexto de cada proyecto. Entonces, pues tiene mucho sentido para nosotros el poder hacer este tipo de cosas que cuando hay algo muy concreto, poder hacer un puntero a este libro de recetas de migración que vamos creando poco a poco. Y bueno, y si es algo que se nos ha escapado, porque, bueno, algo, yo sé, un gap entre WebSphere y EAP, y te has picado tu propia regla para detectar eso y para ver cómo nos puede solucionar, o siempre se puede contribuir a la comunidad, que para eso somos open source. Finalmente, bueno, hablaros de la última forma de utilizar el MTA y es integrándolo directamente con tu hile, con tu entorno de desarrollo local. Esto es especialmente útil cuando estás ya en la fase real de migración. Digamos lo típico es que nosotros entremos y un grupo de arquitectos hago un análisis máximo de las aplicaciones, y a partir de ahí diseñemos un roadmap de migración para esas aplicaciones. Pero el paso final es que una persona, un desarrollador, un migrador tenga su turno de desarrollo y haga modificaciones. Entonces, la manera más sencilla de que ese desarrollador pueda trabajar y sea productivo y no se vuelva loco cambiando entre pantallas, es que esa sugerencia de qué hay que cambiar y cómo cambiar, aparezcan directamente sobre su código fuente en su hile. Y esto sería un poco el aspecto que tendría, como decía, tendría resalto sobre tu propio código, y directamente podrías consumir esas soluciones sugeridas para hacer las modificaciones para la migración. Y deciros que el plugin está disponible para todos los sabores o para los distintos sabores de clips. Y también está disponible para Visual Studio Code. Y, bueno, que es muy fácil de usar, simplemente. Y ya sí que voy a hacer la palabra a Miguel, que creo que tiene algo que contarnos sobre la última versión de MTA, permitirme que le pase la pantalla. Todo todo, Miguel. A mí me encanta una de las cosas que dices, que has dicho, que estas reglas salen entre otros muchos orígenes de los compañeros de Consulting, que estáis ahí en primera línea de los clientes que están trabajando en modificar sus aplicaciones. Leché un ojo recientemente a ver cuántas reglas teníamos actualmente, y van más de 1.200 reglas incluidas en MTA. Y están completamente disponibles y están publicadas en un repositorio público y cualquiera puede acceder a ellas. Como sé el Produmar ayer, dejadme que os hablo un poquito de roadmap y de lanzamientos. Así que os cuento, hemos lanzado en agosto la versión 5.0 y, pues, lo que ayuda es esto. A través de las aplicaciones también a OpenShift sin magia, sin artefactos extraños realmente sabiendo cómo lo estáis haciendo y adaptándolas a contenedores, a cubernetes, y aprovechando las tecnologías. Como podéis ver en esta imagen, tenemos aquí cuatro ejemplos de cuatro transformaciones. Una sería, por ejemplo, para ir a JP, 7, Gebos y EP, si preferís. Otra sería, con tenización, que son reglas basadas en 12-factor-app, en la definición de 12-factores para las aplicaciones, para que sean lo más con tenizables posibles. Y, entonces, ahí se descubren cosas como, por ejemplo, sesiones compartidas, que no estén realizándose una forma que sea con tener friendly. Luego están reglas para Linux. Por lo que decías tú, Ramón, de ese típico caso, que alguien ha puesto una ruta con 0, 2 puntos, contra barra, bla, bla, bla, bla, bla. Pues, también te detecta cosas como esas, que son específicas de Windows, de tal forma que puedas migrar tu aplicación a Linux y, por supuesto, las reglas de OpenJDK. ¿Qué hemos añadido en la versión 5.0? Pues las reglas de para migrar de Apache Camel 2 a Camel 3, lo cual, pues, para mucha gente que esté utilizando los frimos de integración de Apache Camel, como pueden ser en productos como Fuse, Rajat Fuse, pues ahí, pues, estás utilizando un montón de reglas, la quieres aprovechar para Camel 3 y te las puedes llevar a Camel 3 fácilmente. ¿Qué más? Tenemos una página web nueva con una URL muy sencillita, dejadme que os lo enseñe en un momento. Si pones red.htbarra.mta, te lleva directamente a la página web nueva, tenemos aquí una sección, por supuesto, de inicial, con una demo para que veas cómo funciona, con las características principales. Hay aquí abajo del todo un vídeo con un arquitecto explicando cómo lo consume, pues, más o menos, lo que nos estás contando tú, Ramón, pero por un compañero. Sí, está muy bien. Porque yo revisé hoy para saber lo que se mete solo para ver y sí, está bien. Oye, gracias, Scott. Contaré una visita más a la página web. Menos mal, menos mal. Estamos teniendo más de 1.400 visitantes únicos al día de esta página web. O sea, que parece que sí que está creando bastante expectativa. Aquí tenemos las descargas. Por supuesto, si queréis probar algo, recomiendo que os descargáis el web console, que es justo lo que voy a hacer luego la demo. Y por último, dos secciones, una de Getting Started con un vídeo sobre cómo instalártelo en tu portátil y otro vídeo como desplegarlo en OpenSafe utilizando la plantilla que viene incluida. Por supuesto, documentación. La documentación está francamente bien. Tenemos un equipo de documentación muy bueno y que sé y muy dedicado y nos han dejado una documentación fantástica, así que echadle un ojo. Y por último, los casos de uso y de migración, por si quiere revisar, de dónde a dónde puedo migrar, pues esto lo tienes todo en la web. Es decir, lo que vas a necesitar en un primer paso para entender qué te ofrece MTA y cómo puedes utilizarlo, lo tienes en un vistazo en la web de MTA, que es nueva y que la hemos lanzado en agosto. Hace bien poquito. ¿Qué más os cuento? Aparte de la nueva web, una cuenta de Twitter, por si nos queréis seguir, MTA by Red Hat. Y ahí tenéis todas las novedades que vamos contando del Migrate Center for Applications. Y avisamos de cosas como, por ejemplo, esta sesión. Estamos tuiteados y hemos dicho, oye, ¿qué está aquí la sesión? Podéis vernos. Así que si nos estáis viendo, por favor, seguidnos. ¿Qué es lo que viene? ¿Qué es lo que va por lo que va a venir? Bueno, pues primero el contexto. ¿Por qué hemos cambiado el nombre de la aplicación? No ha sido un porque sí, sino hemos unificado los equipos de migración de distintos tipos. Pues siguiendo un poco la idea de Amazon de las 6Rs, no del Replatform, Reportches, Retire, Retain, Repield. Pues siguiendo esta idea, pues hemos dicho, vamos a ver, vamos a ponerlo todo junto y luego vamos recolocando las Rs. Entonces, para ello, pues la primera ha sido el aplicación Microsoft Toolkit. Lo hemos renombrado como Microsoft Toolkit for application. El Cluster Application of Microsoft Tool, que es una herramienta para migrar contenedores de una versión de OpenShift a otra, de una versión 3 a 4, o también de 4 a 4, por si quieres lo típico que tienes una aplicación aquí, la quieres llevar a otro clúster, por cualquier motivo que necesites, te la llevas. Y por último, se presentó recientemente con la versión 4.5 de OpenShift, lo que es OpenShift Virtualization. Y tenemos una solución para migrar de bien buena la virtualization y vamos a adaptar esa solución para que funcione también para migrar de bien buena OpenShift Virtualization, en el caso de que quieras hacer un lift and shift, es decir, coger tu máquina virtual tal y como está de bien buena y ponerla en OpenShift. Y esto va a ser el migration Toolkit for Virtualization. Y ahora tenemos en un paraguas todas las, todas las herramientas de migración y con un nombre, pues, estandarizado. ¿Qué más tenemos? Pues, aparte de las tres que he mencionado, migration analytics, que es una herramienta que se puede conectar a tu vicenter, como explicado un poquito antes, extraer datos y poderte proponer posibles rutas de migración. Un pequeño disclaimer, los roadmap siempre pueden cambiar o como diría un amigo mío, el roadmap es el roadmap hasta que no es el roadmap. Así que lo que queremos hacer con el Microsoft Toolkit for Application, pues ya habéis visto que hemos actualizado el aplicación Microsoft Toolkit, convirtiendo el Microsoft Toolkit for Applications para analizar aplicaciones y ayudarte a traer tus aplicaciones a modernizarlas, bien sea porque vas a traerte a un servidor de aplicaciones más moderno en una máquina virtual o bien sea porque quieres traerte las contenedores en OpenShift. Y sabéis que tenemos la herramienta de Pathfinder y lo que queremos hacer es unificarlas dentro de una sola herramienta para que con la misma herramienta comienzas tu migración analizando las aplicaciones, eliges cuáles quieres migrar y luego, pues haces el análisis técnico de la misma para poder ejecutar la migración. ¿Qué es lo que viene en la versión 5.1? Pues, Spring Boot a Quarkus. Spring Boot a Quarkus, me lo estáis preguntando a todos y es que el de Quarkus está siendo, está siendo tremendo, está siendo un bombazo. La gente está viendo los números de Quarkus y dicen, madre mía, esto, ¿cómo puede ir Java tan rápido? Pues, pues puede ir Java tan rápido. ¿Cómo puede levantar Java tan rápido? Pues, puede levantar Java tan rápido. Una de las cosas que hace Quarkus, o una de las opciones que provee Quarkus a través de Mandrel, que es uno de los proyectos integral VM, es poder compilar a nativo, lo cual hace que, pues, que eso, que los tiempos de arranque de las aplicaciones con Quarkus sean mínimos y que el consumo de memoria sea mínimo y es realmente eficiente. Esto es especialmente importante cuando te vas a ir a contenedores. ¿Por qué? Porque si quieres hacer serverless, es decir, reducir tu cuenta de contenedores a cero, que no esté consumiendo nada hasta que se produzca un evento, Quarkus es fenomenal para esto, por los tiempos de arranque y porque además puedes programar muy fácilmente en modo, modo reactivo. Entonces, que hemos visto, que muchos equipos que están trabajando con Spring Boot en, en nuestros clientes, son los que están analizando Quarkus, porque son los que realmente quieren hacer este tipo de arquitecturas de, de aplicaciones y están viendo que eso, que Quarkus les da mucha más velocidad. Lo que pasa es que vienen por la velocidad y se acaban quedando por el rende, por, por, por el, la productividad. Lo que está ocurriendo es que en, en, hemos tenido casos y hay un ejemplo público en el cual un, un cliente transmigrara a Quarkus, redujo el código, el, el número de líneas de código para la misma aplicación un 30%. Con lo cual menos mantenimiento, menos exposición a posibles vulnerabilidades, mucha más eficiencia, mucha más rapidez, no solo al desplegar, sino al generar el código. Entonces, lo dicho, normal que ya hemos hecho las reglas de Spring Boot a Quarkus, porque es que nos lo estaban demandando. ¿Qué más? Un nuevo web UI, tenemos un proyecto en Red Hat que se llama Pattern Fly y que, y que le tengo mucho cariño a Pattern Fly, porque está haciendo la cara de todos los productos de Red Hat y incluso he oído a más de un ingeniero decir, estamos Pattern Fly para que, para que se sienta como Red Hat, para que se note como Red Hat. Entonces, Pattern Fly ha sacado una versión, que es la versión 4, que está realmente mejorada y que ayuda mucho a que se entienda el interfaz más rápidamente, más fácilmente. Y nuestros compañeros de User Experience and Design nos han ayudado muchísimo al equipo de ingeniería a desarrollar entre nosotros y ellos este interfaz nuevo, que esperamos que os guste mucho, cuando salga el 4 de diciembre. ¿Y qué más? Un operador. Estamos haciendo un operador para que desplegar MTA en OpenShift, sea como desplegar cualquier otro recurso que puedas tener en el Cluster y mantenerlo sea más fácil con el operador. Inicialmente el operador será solo para despliegue, pero a continuación añadiremos más capacidades como poder actualizar y realizar otras funciones de mantenimiento de MTA para que sea aún más fácil consumir MTA dentro de OpenShift. Esto es lo que viene. Lo he dicho, la fecha el 4 de diciembre es cuando esperamos poder tenerlo público y estamos trabajando para que sea así. ¿Qué más os cuento? Tenemos un e-mail, migratearloja.com o migrate, migrate, arrobaroja.com para cualquier duda, consulta, sugerencia o lo que podáis necesitar. Todo el equipo de migraciones está detrás de este e-mail, así que cualquier cosa que necesitáis nos dejáis un e-mail y responderemos a ello. Ahora os voy a hacer una pequeña demo de cómo funciona MTA. Yo no quería. Pensé que quizás no tienes un demo y no quería presionarte, pero sí, qué bien, perfecto. Tenemos una demo, pero antes tengo que enseñar una cosita, ¿vale? Todas estas herramientas de migración estamos poniéndolas debajo de lo que es un proyecto OpenShift completamente abierto, en el cual ya tenemos colaboradores que no son de Red Hat, que se llama Conveyor. Aquí veis Conveyor.io. Podéis entrar aquí y podéis ver todo lo que estamos haciendo, todo el código. El código de MTA irá viniendo poco a poco aquí. Y de momento tenéis las herramientas de migración para migrar de un Kubernetes a otro, herramientas para migrar a Kubebird, una herramienta para migrar de Cloud Foundry a Kubernetes, una herramienta para medir las métricas más importantes de desarrollo y, por supuesto, Windup, que es el proyecto de MTA, es la herramienta para migrar aplicaciones. Cuéntame. Una pregunta. ¿Cómo funciona Moved Kubernetes? ¿Cómo funciona esto que tiene? Esto lo ha contribuido, no te lo vas a creer. IBM Research desarrollaron esta aplicación y nos la enseñaron y le dijimos por qué no las publicáis y dijeron, ¿cómo la publicamos? Pues eso, porque no hacéis open source, la ponéis en este proyecto, pero a ver, cuéntanoslo, le contamos el detalle inmediatamente, dijeron, sí, adelante, y han publicado esta herramienta. Ya se ha utilizado en bastantes casos reales y lo que hace es que se conecta, por ejemplo, a tu Cloud Foundry y mira a ver las primitivas, los objetos que estás definiendo en Cloud Foundry y te ayuda a definir los mismos objetos en Kubernetes, las rutas, el número de contenedores, etcétera. De tal forma que cuando tú tienes tu aplicación en Cloud Foundry, te crea todo lo que es la estructura en Kubernetes y luego ya solo tienes que meter el código compilado o bueno, depende. Si, eso lo pregunté porque Podman, por ejemplo, tiene un feature que tú puedes traer tu código de compose, mejor dicho, pero y funciona con Swarm y si tienes esa compose, ese yaml, tú puedes traslatar, lo hasta Kubernetes yaml y solo estoy pensando lo que funciona esto. Mejor, quizás. Qué bueno tener aquí al experto en Podman, ¿eh? No, la verdad es con la conmigo. No, quizás podemos contribuir Podman aquí para condenar, para parte de la conversación de emigrar. Tú sabes que mover las aplicaciones. Fantástico, eso. ¿Has visto el e-mail de microtarrobaraja.com? Mandamos un e-mail, nos ponemos en contacto y nos ponemos manos a la hora. A mí me suena como una idea tremenda, Scott. Así que hagámoslo. Y desde el punto de vista de consulting, te digo que todas estas herramientas, nosotros nos vienen de maravilla porque hay mucho. O sea, que Kubernetes es el estándar ahora mismo, ya no lo discute absolutamente nadie y OpenShift es el estándar empresarial de Kubernetes. Entonces, tenemos montones de migraciones de clientes, de Docker, Swarm, de DCOS, de Cloud Foundry, hacia OpenShift. Cuanto más herramientas se hagamos, muchos más sencillos son estos engagement con el cliente. Sí, por fin, el mundo dio cuenta que ya Kubernetes ya ganó. Yo sabía hace tres años, pero todo el mundo ya sabe. Yo mejor esto ser muy precavido. Yo lo que veo es que funciona y que nuestros clientes están contentos y que tenemos cargas en producción de niveles tremendísimos, pero tremendísimos. Es decir, realmente algo de esto de si separa un minuto, estamos perdiendo millones de euros o dolares si prefieres. Pues de esas hemos tenido sobre OpenShift y están en producción. Y la verdad es que uno, después de haber empezado hace 5 o 6 años con las primeras versiones de OpenShift, a lo que hemos llegado, pues es siendo muy orgulloso de lo que se está haciendo. Así que mi felicitación a todos los que han estado contribuyendo, porque es tremendo. Vuelvo al demo, ¿vale? No quería irme sin mencionar Conveyor y no me quería irme sin deciros que eso, que si queréis participar en el proyecto AppStream, este es. Y aquí es donde vamos a estar y aquí es donde nos podéis encontrar. Hay una lista de correo, hay un Slack, hay un Foro. Así que ahí podéis encontrarnos. Sobre un detalle más, me habéis preguntado mucho de Springbutacoarcus. Bueno, pues aquí tenemos en issues.reja.com tenemos todos nuestros tickets y este es el Epic que hemos desarrollado para Springbutacoarcus y estas son las reglas que se han implementado para ir de Springbutacoarcus. Algunas son incluso bugs, porque algún compañero lo ha probado ya con código real de clientes y lo he dicho. Ya está esto prácticamente terminando de cocinarse para salir el 4 de diciembre en la versión 5.1. Por si queréis mirarlo. Como siempre, todo abierto, todo disponible y todo para vosotros. Sobre la demo, ¿qué voy a hacer? Algo muy sencillo. Pues, imaginaos que me vengo aquí a download en nuestra página web red.ht-mta y vengo aquí y me descargo la web console, ¿vale? Esto es un archivo zip y lo único que voy a hacer aquí es pues descomprimirlo. Entonces, en esta carpeta, voy a hacer un poquito más grande, en esta carpeta está directamente lo que hemos descomprimido del archivo zip que hemos descartado. Como sé de sistemas, lo pongo en barra OPT. ¿Por qué se puede poner ejecutables en el home? Me da un poquito de urticaria. Entonces, una vez que lo tenemos, aquí hay un script que se llama run-down-mta y ese es el que hay que ejecutar. Bueno, si estás en Windows, tienes el pad. La dependencia que tiene eso es tener una JDK instalada, preferiblemente OpenJDK8 o OpenJDK11, aunque también soportamos a Oracle JDK8 y 11. Yo arranco este script, te levanta el servidor con su aplicación. Tiene incluso todo un sistema de variación por detrás que se puede habilitar el caso de que queramos poner usuarios y contraseñas. Y una vez que está arrancando, podemos ir a localhost 8080 y cambiar la aplicación. Y vamos a ver si se termina de cargar o le he dado demasiado pronto. ¿Tú qué crees, Scott? Le he dado muy pronto. No, bien. Ahí está, ahí está. Ahí está. La primera vez que lo abrimos, nos hace lo que inautomaticamente con una password bastante sencilla, por lo cual tenemos estos avisos. Y aquí tenemos los proyectos. Entonces, ¿cómo empezaríamos? Pues normalmente creamos un proyecto nuevo y lo llamamos OpenShift Commons en vivo. ¿Bien? Y pues, ¿continuamos? En vivo, eso es. Y ahora añadimos aplicaciones, ¿no? Pues ahora elijo unas pocas aplicaciones para probar y me voy aquí a una carpeta que tengo con aplicaciones de, con unos binarios, ¿vale? Estos binarios. Entonces, ¿tú dices, ¿vale? ¿Vale? ¿Por eso? En vivo. No, no. Esto no es especial para OpenShift en vivo. Al revés, esto lo tenemos publicado por si lo queréis probar vosotros. ¿Ves? Tenemos aquí en GitHub, en Windup, que es el proyecto AppStream de MTA. Hay un proyecto que es Windup Sample Apps. Como puedes ver, y aquí dentro de la carpeta sample binaries te puedes bajar estos cinco binarios para probar tú el MTA. Entonces, cualquiera que quiera probar esta misma demo lo puede hacer muy fácilmente. Te descargas el zip de aquí, te descargas estos binarios de aquí, arrancas el MTA, dejas que suban las aplicaciones y siguiente. Y ahora es cuando configuramos el análisis, ¿vale? Pues vamos a poner las reglas para migrar a AAP-7 que normalmente, además de ayudarnos a migrar a AAP-7, va a hacer que nuestra aplicación sea mucho más conforme a los estándares de JEE, que lleva Enterprise Edition o ya Carta Enterprise Edition, como se llama ahora. Y además lo he dicho, las reglas de Tual Factor Apps, de los 12 factores de aplicaciones para meterlas en contenedores, las reglas de Linux para evitar que tengamos alguna cosa específica de Windows y las reglas de JDK para evitar que tengamos alguna clase propietaria de la JDK de Oracle. Entonces, con estas cuatro reglas, lo que estamos haciendo, además, es estandarizar nuestra aplicación. Es decir, nuestra aplicación se va a poder mover a muchos más destinos y estamos utilizando mucho más código estándar y estamos utilizando menos clases propietarias y menos clases que hacen que nuestra aplicación tenga que ejecutarse solo en un entorno. Tenemos aquí los paquetes que seleccionamos, podemos añadir opciones avanzadas. En este caso, voy a enseñar unas pocas, pero no voy a incluir ninguna. Podríamos incluir, por ejemplo, el skip reports o el habilitar el tattletail, deshabilitar el tattletail. El tattletail es el reporte como sería con las primerísimas versiones que lo mantenemos. Se cree un poco por un homenaje a los que empezaron esta herramienta. Y le damos a guardar y lanzar y entonces hasta ahora se ponen una cola y en un momentito empezará el análisis. Como no os quiero hacer esperar, pues lo que hago es que ya, mira, a veces está empezando el análisis, me voy a proyectos y tengo un proyecto como en los programas de cocina que ya ha terminado el análisis. Y son las mismas cinco aplicaciones. Entonces, cuando yo le doy aquí a los informes, tenemos estas cinco aplicaciones y veis que hay dos que tienen el jbos y epi en verde. Estas son dos aplicaciones que podrías ejecutar en jbos y epi, ¿vale? En jbos y epi. Tiene embargo, hay otros que lo tienen en rojo. Pues yo pulso aquí y me dice, ¿cuáles de las clases que estoy consumiendo están parcialmente soportadas, que son las amarillas o no son válidas para llevarlo a jbos y epi? Luego, ¿cuáles son neutras que las puedes utilizar sin ningún problema y cuáles son verdes que sí que están soportadas? Y aquí podemos ver el soporte que tendríamos, por ejemplo, para jbos y epi. También tenemos el de jbos web server que es la edición, por decirlo así, o la construcción de Apache Tomcat por parte de Red Hat, que está soportada y que también viene incluida con OpenShift. Entonces, en este caso, si quisiéramos moverlo a jbos web server, pues el único que tenemos soportado es el server. Como es lógico, más luego, maybe en web XML las típicas. Entonces, aquí vemos varias aplicaciones y vemos sobre todo aquí los históricos y los puntos que serían requeridos para poder hacer la migración. Esta, como veis, está ya lista para migrar. Esta no hay que hacerle nada. Sin embargo, estas otras, pues sí tienen ciertos story points y tendríamos que revisarlas. Entonces, quiero revisar los issues, las cosas que hay que cambiar dentro de las aplicaciones de las cinco. Pues aquí tengo un sumario de todos los issues y veo que lo que más estoy utilizando aquí es un logger propietario de WebLogic. Es decir, WebLogic tiene una forma de enviar los logs que es solo de WebLogic. Entonces, aquí podemos ir a la documentación de jdk y aquí nos va a explicar cómo podríamos utilizar los logs directamente de jdk. No queremos usar los de jdk, a ver, que vuelva aquí. Que no, pues tenemos los de jbos, los propios de jbos, que también están aquí utilizables. Entonces, con esto ya sabemos que podemos cambiar el código para hacerlo mucho más estándar, para utilizar un logger mucho más estándar. Me puedo meter, por ejemplo, en alguna de estas. Y aquí, como estos eran binarios, no tengo el código, sino lo que es el de compilado de la aplicación. Y me indica aquí en algunos puntos, mira, aquí está una clase propietaria de WebLogic de internacionalización, ¿vale? Que deberías considerar. Aquí hay, pues, annotations y hay una serie de cosas. El logger, este es el que hemos visto hace un momento y dice, ¿dónde está? Entonces, si esto lo hubiéramos hecho con el código fuente, que también se puede, pues nos indicaría exactamente la línea del código fuente donde aparece este iso. Volvemos a los isos y aquí tenemos. Y este tipo de cosas, perdón, este tipo de cosas, en este caso concreto que estamos viendo cosas de WebLogic, pues eran las que se le estaban atragantando este cliente que os comentaba antes, que con una revisión visual, pues se dejaba alguna vez estas cosas dentro de su código, sin cambiar, y después la aplicación no funcionaba en el destino. De esta manera, podemos, de manera automatizada, detectar todos esos puntos de acoplamiento con servidores de aplicaciones distintos o más antiguos y hacer las modificaciones que tengamos que hacer con garantía. Esto nos permite diseñar un plan de migración con garantía para nuestras aplicaciones, y lo que permite que podamos hacer este tipo de migraciones masivas. Así es. No es tanto el encontrar los problemas, sino que no se te escapen. Exacto. Que no se te escapen, y entonces la aplicación no te dé problemas en producción. Ya sabemos que cuanto antes se corrige un problema, más económico es corregirlo. Entonces, esto hace que el coste de migración también se reduzca. ¿Qué más os puede enseñar? Pues, mira, las tecnologías que se están utilizando en estas aplicaciones y las puedo ordenar, pues, ¿acaso hay alguna en la que esté especialmente interesado? Pues, me dice, pues, ¿qué ves las aplicaciones y el orden de las tecnologías que se consumen en cada aplicación? También tenemos el grafo de dependencias, que es siempre muy divertido sacudirlo un poco, pero que, sobre todo, es útil, ¿vale? Hago la broma siempre de sacudir esto, como lo llamamos en así de broma las bólicas, pero un saludo a baladas por lo de las bólicas. Pero vamos, que es útil, porque aquí tenemos las clases que están compartidas entre distintos los artefactos, como los llama Ramón, que me gusta mucho, que están compartidas entre distintas aplicaciones y que, tocando una, pues, nos va a afectar a las dos aplicaciones. Por supuesto, esto está muy benvero así, pero también es importante tener una lista detallada de las dependencias, de lo que serían los artefactos compartidos entre aplicaciones. ¿Y ahora? ¿Permite meter otra morillilla? ¿O las que quieras, por favor? El tema de las dependencias, de los artefactos y demás, es especialmente importante. Por ejemplo, en el ejemplo que exponía antes, muchas veces nos encontramos clientes que utilizan una arquitectura corporativa. Entonces, no voy a migrar en veces esos artefactos para cada aplicación. Me centro en migrar esos artefactos que conforman la arquitectura corporativa y, con eso, ya he hecho gran parte del trabajo de migración de esas aplicaciones. Por eso, el tema de las dependencias es vital para nosotros en este tipo de proyectos de migración masiva. Adelante y perdona. Encantado. Y las veces que haga falta. Scott, tú si tienes preguntas también dispara, no te cortes. No estoy pensando. No entiendo exactamente cómo se ayuda ese, por ejemplo, ese graph de dependencias, cómo se ayuda en migración. Aquí lo que tienes es que tienes, por ejemplo, esto. Aquí hay una clase que es Migration Support, que pertenece a dos aplicaciones. Duplicate Here y Example. Entonces, esta clase, cuando tienes un framework, y se ve mejor cuando tienes muchas aplicaciones, déjame que abra otro con más aplicaciones, ya que me lo pides tan amablemente, pues, mira. Aquí se ve mejor. Aquí tenemos todos estos objetos, estos cinco objetos. Uno, dos, tres, cuatro, cinco. ¿Vale? Están compartidos por todos estos paquetes. Entonces, ¿puedes resolver cuánto esfuerzo tiene necesidad para migrar esta aplicación? Así es. Y, sobre todo, saber que si yo arreglo estos tres, si yo arreglo estos cinco, le va a afectar a estos tres y a estos cuatro, es decir, estos siete aplicaciones, van a haberse afectadas por esto. Entonces, esto solo lo tengo que hacer una vez. ¿Por qué? Porque no voy a ir a cada aplicación a esta dependencia a modificársela. La modifico en una edad, copié las demás. Y, contándote, en un caso práctico, muchas veces, o sea, nosotros cuando estamos haciendo estos proyectos de migración, hablamos con los clientes para identificar estas librerías de arquitectura, estos frameworks que utilizan los clientes, pero muchas veces se olvidan de cosas. Y, entonces, este tipo de análisis nos ayuda a detectar librerías comunes entre aplicaciones que, lo mismo al cliente, se lo ha olvidado siquiera que las estaban utilizando. Sí, que nosotros de alguna forma... Sí, sí, sí, adelante. En que, en algún caso, entonces, es como, ah, pero esto lo seguíamos utilizando, pues esto lo teníamos que pietar. Sí, estábamos. Lo teníamos que haber quitado y no lo hemos quitado. Y, de repente, pues, estás incluso limpiando la aplicación, quitándote deuda técnica, con lo cual más ahorro económico. Y ahora... Nosotros tenemos un broma que estos análisis son como mirar debajo de la elfombra. Todo lo que aquí lo acumulamos hasta el final de 20 años es lo que salen estos análisis y es lo que nos centramos en mirar para que no haya problema. Eso es. Ahora, os enseño aquí el informe para una aplicación en concreto, ¿vale? Esto sería para una aplicación en concreto. Y aquí puedes ver, pues, los incidentes por categoría, ¿vale? Los que son, por ejemplo, obligatorios, Mandatory. Los que son Cloud Mandatory, que estos son, por ejemplo, en este caso, tenemos seis que serían específicos de, oye, si te quieres llevar esta aplicación a contenedores, estos seis los tienes que revisarse o sí. Luego, cuáles son solo de información, etcétera, etcétera. Aquí vemos cuáles parecen triviales, cuáles son complejos si necesitan rediseño o si son un problema de arquitectura. Todos estos son detectiones que se van haciendo y que nos van informando de la aplicación, de qué es lo que tenemos que hacer en la aplicación para ponerla al día. Aquí vemos los issues específicos de esta aplicación. Podemos ver, por ejemplo, aquí en Cloud Mandatory, que se estaban utilizando, pues, métodos como RMI, que no son muy adecuados para utilizarlos en contenedores. Entonces, esto es lo que tendríamos que arreglarle a esta aplicación, además de todas las dependencias de weblog y que tenemos para que sea, para que pudiera funcionar en contenedores. Qué más detalles, pues, el esfuerzo está a ser una aplicación que habría que echarle bastante esfuerzo, que tiene 112 story points. Con esto, dependiendo de equipo que tengas, pues, lo puedes ir repartiendo. Y así puedes hacer una estimación una vez que llegas una velocidad estable de migración, una estimación de la duración exacta de la migración. Qué más, pues, informe de las tecnologías para esta aplicación específica, del gráfico de dependencias de esta aplicación específica, lo que no se ha podido parsear, que también está bien saber, oye, que esto no hemos podido parsearlo. Echale un ojo, porque muchas veces no importa, pero hay veces que aquí te encuentras detalles de, ahí va, esto tengo que cambiarlo también. Y qué más, la lista de dependencias, los Java Bins, los servicios remotos a los que se accede, que estén configurados, por supuesto, los recursos de servidor que se están consumiendo. El TaptelTale, esto es un poco como la información original de las primeras versiones de la aplicación y los archivos que se han ignorado. Y con esto, yo creo que hemos dado un paseo a lo que hace MTA. No me voy a meter en cambiar código. Ya veis que descargarle probarlo en tu portátil es bien fácil. Y bueno, y esta es la demo. ¿Tenéis alguna otra pregunta para mí? Sí, pregunte a Diane para ver si hay unas preguntas. No sé. Bueno. Daron las gracias, Diane, por invitarnos a participar y a todos los que habéis estado viéndonos. Sí. Muy bien. No hay preguntas. Creo que haces un trabajo increíble. Pero voy a picar la próxima semana. Así que si puedes compartir el link, tal vez, a la próxima semana en la chat. Sí, está diciendo, Diane, que no hay preguntas, que le hemos hecho fenomenal, que además hoy estoy muy guapo. ¿Te dice eso, Diane? Pero estoy muy... Guapo, algo así. Estoy muy guapo hoy. Tienes que ver. Muy guapo. Gracias, Diane. Aquí tenéis el enlace. Lo voy a pegar aquí, ¿vale? Opensiv.com.os en vivo. Si buscáis Opensiv.com.os en vivo en internet, lo vais a encontrar. Y si no, Opensiv.com.os.opensiv.com. Y aquí es lo que tenéis. Esta no os la perdáis, de verdad. Porque va a estar Ramón Acedo, que es un buen amigo mío, que además está trabajando en Opensiv sobre OpenStack. Va a estar María Bracho, que es productmana y el que ha trabajado muchísimos años con OpenStack, está trabajando con Opensiv. Son dos grandísimos expertos en Opensiv sobre OpenStack. Y la verdad es que para despliegue grandes, grandes, grandes de Opensiv, esta opción es francamente interesante. No os lo perdáis. Entonces, ajúnteles con nosotros la próxima semana para ver esto. Exacto. La próxima semana, el 12 de noviembre. A esta misma hora. Entonces, por eso creo que tenemos más. Estamos terminados, ya. Tenido. Nos falta que Ramón se despida. ¿Quién es el expediente Ramón? De luego, muchas gracias, Ramón, por invitarme. Y espero veros pronto. Gracias, Ramón. La verdad es que me invito a Ramón porque es que tener alguien que ha estado haciéndolo él mismo con tantos clientes en tantas situaciones. Muchas gracias por todas las morcillitas que metías y por compartir tu experiencia con nosotros, Ramón. Sí, era muy interesante y mucha experiencia que ustedes tienen. Sí, bueno. Gracias. Gracias. Por favor, en cuercas briefing, sometime soon. En briefing de cuercas. With resharples, if you want to. I mean... I love it. No, esa tendrá que ser inoperative commons. Pero yo creo que Ramón, tú te atreverías a preparar un briefing de cuercas o no? No, está grabando. No, no, Daniel. I don't make you take a carcass. Sorry, but I didn't have time for that. I do have the materials, though, but I didn't have the time. Sorry for that. That's okay. Thank you everybody. I apologize for my lack of Spanish skills, but I really appreciate you coming today and taking the time to do this. So take care. I will post this up on YouTube shortly and we will start socializing the Envivo landing page. So that'll be it. All right, take care. Good night, wherever you are. Bye. Good night.