Transcripción
- Audio: https://www.ivoox.com/devs-lives-2-jorge-aguiar-martin-serverless_mf_86468563_feed_1.mp3
- Fuente: retranscripcion automática desde audio con mlx-community/whisper-large-v3-turbo
- Nota: esta versión mejora el ASR respecto a los subtítulos de YouTube, pero todavía no incluye diarización real de hablantes.
[No identificado] (00:00:23): Bienvenidos a Devs Lives, episodio número 2. Hoy tenemos la suerte de contar con uno de los grandes compañeros de Lean Mind, una de las personas con las que he estado compartiendo los últimos meses, pero antes de ello hemos podido compartir grandes momentos, no solo desarrollando, sino pasando muy buenos momentos, echándonos una muy buena risa, no bebiendo cervezas porque no es mi caso, pero bueno, nos lo hemos pasado bastante bien, así que bienvenido al episodio número 2. Jorge, ¿qué tal? Tenemos con nosotros a Jorge Aguiar.
[No identificado] (00:01:01): Buenas, muchas gracias. Sí, es una suerte conocerte, haber podido echarme esas risitas, vacilones varios, que siempre son bienvenidos. Y nada, y por suerte o por desgracia, pues nos ha tocado trabajar juntos estos últimos meses, así que yo personalmente lo estoy disfrutando y estoy aprendiendo mucho también, así que siga así, que siga así. Yo pensaba que ibas a decir que tenías que aguantarme.
[No identificado] (00:01:29): No, no, no, eso es mutuo, eso es mutuo, eso no, nunca es solo en una vía. Mira al lado positivo, soy un peso ligero, o sea…
[No identificado] (00:01:38): Bueno, yo soy el pesado. No, hombre, que no, que no, hay que ver cómo pintas las cosas, chicos, no vas así, no vas así. Pero esto es así todos los días, constantemente. Eso sí, se sacan cositas. Así que, bueno, cuéntanos, Jorge, ¿qué tal? ¿Quién eres? ¿Quién es Jorge Aguiar? Bueno, Jorge Aguiar es un proyecto de ingeniería informática que todavía está en proceso desde 2013. Es lo dicho, es una carrera de fondo, así que con calmita.
[No identificado] (00:02:10): Y nada, yo siempre digo y diré que hago cosas, porque si bien es verdad que hay una cosa que a día de hoy todavía no he sabido manejar y es el CCS, de resto, pues me meto con lo que sea, entonces, pues, mientras no se hace CCS, ahí estoy, para lo que haga falta. El gran temido, ¿no? Siempre que hay algún problema de CCS, hacemos un arroba Mike, por favor, Mike, pásate por aquí, tenemos que hablar contigo. Pero, oye, yo creo que hemos ido mejorando todo, en tu caso también, que poquito a poco, gracias a Michael y trabajando con él,
[No identificado] (00:02:46): Hemos aprendido un montón de CCS y ya nos defendemos, no somos tan palitroques como al principio. Sí, ya soy capaz de poner un borde. He progresado, he progresado. Ya soy capaz de, incluso sé ponerlos redonditos, los bordes, ¿eh? Ojo, cuidado, que se dice rápido, ¿eh? Pero… ¿Pero de cuántos píxeles? ¿De cuántos píxeles? Eh, no sé, tío, yo le suelo poner dos o tres y lo que surja, ¿sabes? Yo me quedo en uno, en cuanto intento ponerle un borde de más de un píxel y ajumoné, esto no me gusta.
[No identificado] (00:03:20): No, está bien, está bien, pero… Bueno, y aparte de… Ya hemos descartado CCS, ¿vale? Sabemos que el CCS no es lo nuestro, ¿vale? Tenemos otra serie de virtudes en nuestro gran elenco de tecnologías a manejar, pero dentro de ese gran elenco de tecnologías a manejar, ¿cuál te representa más? Yo siempre, desde que… Hace unos años, siempre diré y digo que soy fanboy de AWS y de serverless. Yo, ahora mismo es lo que me mola, lo que quiero especializarme y si bien es verdad que le doy a cualquier lenguaje de programación y tal, mientras sea con AWS es mejor todo, entonces…
[No identificado] (00:04:07): O sea, que descartas totalmente a los otros distribuidores, aquí lo demás no… Tengo la suerte o la desgracia de haber trabajado con los tres y con el que más cómodo siempre me he sentido es con AWS. Curiosamente empecé con Azure y, bueno, sí, Azure, pues la documentación y tal no está ni tan mal, pero de nada que empecé a tocar AWS fue todo como mucho más fácil, o por lo menos es mi sensación, esto es la típica, ¿no? Para gustos están colores y en este caso distribuidores. Claro.
[No identificado] (00:04:46): Entonces, con la que más cómodo me siento y la que más fácil siempre se me ha hecho es AWS, sin duda. Vale, vale, vale. Pero claro, aquí entonces llega ahora ya la gran maravillosa pregunta de… Si trabajas con AWS, ¿estás casado con el proveedor? Entonces eso en cuanto a desarrollo tiene ciertas implicaciones y que suele ser lo que más rechazo causa en la comunidad. Al decir, ah, pero es que no me gusta trabajar con temas de serverless o de landas porque al final te casas con el proveedor. Después eso no lo puedes migrar a otras plataformas. Si quieres cambiar de proveedor tienes que rehacer todo.
[No identificado] (00:05:32): Entonces, bueno, cuéntame un poquito tu experiencia porque, hagamos spoiler, yo sé que eso no es así. Creo que compartimos una opinión, pero no hay nadie mejor para hablar de este tema que tú. Así que adelante.
[No identificado] (00:05:48): Justamente es lo que llevo tratando de trabajar en los últimos meses. Tengo pendiente de hacer la charlita en el J610 acerca del tema. Porque si bien es verdad que cuando empezamos a usar una tecnología, pues en parte tenemos ese gap, esa desventaja de que tenemos que seguir usándola. Pero eso no es del todo cierto. Del mismo modo que cuando generamos un backend cualquiera, tenemos las herramientas para poder en un futuro migrar esa base de datos que tenemos en MySQL. Poder pasar la oracle sin afectar, entre comillas, a nuestra parte de código, a una pequeña mínima parte del mismo.
[No identificado] (00:06:33): Lo mismo podemos hacer en este caso con serverless. Yo no dejo de ver serverless como la parte de gestión de controladores. Ya más allá, de resto son más tecnológicos. Es simplemente un RAM que te está haciendo algo por detrás. Solo está levantándome la aplicación. Por lo tanto, lo que haga yo detrás es cosa mía. Entonces, si aplicamos los mismos conceptos de arquitectura hexagonal que aplicamos, por ejemplo, cuando generamos una aplicación de Spring Boot y dejamos el dominio aislado, ese dominio lo puedes exportar a la tecnología que te dé exactamente la gana.
[No identificado] (00:07:07): Entonces, eso es lo que estoy trabajando y lo que voy a tratar de clarificar y de poner en contexto en la charlita del JSD. O sea, básicamente lo que el resumen un poco viene a ser de desacoplar capas. Tenemos por un lado lo que es la parte de AWS, de serverless, que después matizaremos un poquito más, de lo que son las funciones. Esa es tu parte de infraestructura donde tú viajas a tu capa de infraestructura y de ahí a tu capa de dominio se separa.
[No identificado] (00:07:44): Pasarás los datos con tu formato de dominio y demás y de ahí a los sistemas de almacenamiento que utilice AWS en este caso. Creo que era TurboDB o DynamoDB. DynamoDB es una de ellas. RDS es un sistema también que tienes que básicamente te levanta cualquier instancia de base de datos que conozcamos. MySQL, Oracle y tal, lo que son directamente autogestionadas. Toda la parte del escalado de migraciones y todo eso, eso ya lo gestiona el mismo.
[No identificado] (00:08:17): También tenemos el AuroraDB, si no me equivoco. Creo que también pertenece a… Es la no documental propia de Amazon.
[No identificado] (00:08:25): Es lo mismo de siempre. Se trata de dividir conceptos, ¿no? De tratar de que mi código de dominio, que es lo que realmente aporta valor al negocio,
[No identificado] (00:08:37): En su mayoría, ¿no? Porque son las reglas que estamos implementando. Dejarlo de tal manera que yo esa piecita de código pueda migrarla a donde a mí me dé la gana en cualquier momento. Por ejemplo, yo ahora estoy preparando un mini proyectito que probablemente lo use a modo de ejemplo para el tema de la charlita.
[No identificado] (00:08:56): Y es internamente dentro del InMind para poder hacer publicaciones al blog del InMind sin necesidad de que las personas que están ahora mismo gestionando esas publicaciones tengan que tener conocimientos de Git o de GitHub en este caso, ¿no? Por lo tanto, claro, se complica, siempre se ha complicado el tener que probar ese proyectito en general en local, ¿no? Entonces, lo que estoy haciendo es generando la parte de Express.js como parte de… Para ejecutar el proyecto en local. Y ya yo desplegaré en Lambas cuando sea la versión de producción.
[No identificado] (00:09:32): Entonces, realmente lo único que tengo que duplicar es la parte del controlador de… El enrutador de rutas, como quien dice. De resto, el código va a quedar intacto.
[No identificado] (00:09:44): Vale. Te sigo, te sigo, te sigo. Perfecto. Con respecto a eso me surge otra duda. Es que, por ejemplo, ahora has estado hablando del tema de hacer el desarrollo en Express y después subirlo en cuanto a Lambas. ¿Esto se debe a la parte de testing o a la parte de desarrollo o simplemente unas limitaciones de requisitos que no se cuenta con una cuenta de AWS con la que trabajar y por eso te es obligado a usar Express o…? Lo estoy haciendo, uno, a modo de la parte de investigación.
[No identificado] (00:10:18): Dos, como tratar de evitar el hecho de desarrollar directamente sobre AWS para evitarte pagos innecesarios que no me estén aportando nada. O sea, si me aportan, no, porque es la parte de testing y es como… Es esa parte de verificación de lo que yo estoy haciendo. Tiene su… Está bien hecho. Pero como tengo las herramientas para poder probarlo sin necesidad de hacer ese pago, de hacer uso de esos servicios que son de pago, tiro directamente de recursos locales.
[No identificado] (00:10:47): Entonces, yo lo veo como una forma de evitar de tener que tener la cuenta de AWS antes de llegar a entornos de preproducción, en plan, ya hablando de algo a lo mejor un poquito más grande. O incluso de antes de llegar al entorno de producción, en plan, ya finalmente. Vale, o sea que puede ser perfectamente como cuando, en cuanto a arquitectura, solemos decir posterga decisiones técnicas, pues puede ser eso. Sabemos que el enfoque final va a ser AWS, pero de momento, ante la duda, nos enfocamos en el dominio y después lo podemos migrar porque lo estamos diseñando con ese enfoque. Efectivamente.
[No identificado] (00:11:25): Entonces, como en parte necesito diseñar la API, pero sin tener que tenerla en AWS con el API Gateway tirando hacia las landas por detrás, pues me ahorro el tener que… Todo ese código de infraestructura que tengo que generar, única y exclusivamente para eso, justamente para desacoplarme de esa capa. Claro. Y siguiendo un buen approach de tecnología, de capas y demás, entiendo que la migración es muy sencilla.
[No identificado] (00:11:53): Al final es cambiar una única ruta de express que no tiene lógica de dominio, no tiene validación o no tiene nada, por una lambda que al final es una función que es la que va a llamar a tu dominio. Y ni siquiera intercambiar nada, porque pueden ir en paralelo. Yo tal como lo estoy generando, tengo mi pieza de express por un lado y después ya generaré mi pieza de infraestructura de AWS por el otro. Por lo tanto, lo único que tengo que hacer es… Mira, pues en este punto estoy llamando a este punto de dominio, pues es llamarlo desde ambos partes.
[No identificado] (00:12:25): Vale, vale. Y en cuanto al diseño, ¿cómo crees que te repercute el trabajar con AWS? Quiero decir, cuando tú llamas una lambda, estás trabajando con funciones, ¿no? Se supone que las lambdas se levantan en el momento en el que recibe la petición.
[No identificado] (00:12:49): Eso quiere decir que si se sigue un enfoque basado en… Como se hace, por ejemplo, con un Spring Boot, donde tienes tus instancias globales de tus repositories, de tus servicios y demás. Al final la instancia la tienes ahí, no estás instanciando cada vez. Sin embargo, de cara a serverless, cada vez que llamas a tu función, tienes que estar levantando instancias de esas clases en memoria. ¿Consideras que eso tiene algún tipo de repercusión en rendimiento en cuanto a las limitaciones que te pone AWS?
[No identificado] (00:13:23): ¿O es algo que da igual? O sea, no va a repercutir en cómo tú plantees la parte de arquitectura más de tu dominio. Como curiosidad acerca de eso, realmente, y en plan siendo como super mega teóricos, en plan a los hechos super mega exactos, realmente AWS no levanta… Es decir, yo hago una petición a una lambda, ¿no? Y esa lambda no muere de nada que ya deja de ser usado. Tiene un tiempo de vida que se mantiene viva durante un tiempo justamente para evitar eso que tú acabas de decir, ¿no?
[No identificado] (00:14:01): De tener que estar levantando constantemente algo en plan de, pues, vive, muere, vive, mueve, vive, muere. Eso, pues, es justo lo que tú acabas de decir.
[No identificado] (00:14:12): Springboot, por ejemplo, tiene una parte que es de la parte de serverless que te permite trabajar con las lambdas de AWS. Tú imagínate estar levantando un contexto de Springboot cada vez que te hacen una llamada. Eso sería horrible. El tiempo de respuesta es horrible. Entonces, sí es verdad que la primera vez que tú empiezas a generar tráfico va a tardar más tiempo, pero la siguiente vez ya no va a tardar tanto porque esa lambda probablemente seguirá viva durante X periodo de tiempo que AWS estipula. Claro, después, independientemente de que se use o no, AWS sí la mata y vuelves otra vez. Efectivamente.
[No identificado] (00:14:48): Entonces, por ejemplo, cuando son proyectos con mucho tráfico, realmente no van a estar muriendo y viviendo, sino que a lo mejor se levantan tres en simultáneo porque tienes un máximo de tres, cinco peticiones simultáneas y lo que van a estar haciendo es sustituyéndose entre ellas el tráfico.
[No identificado] (00:15:09): Vale, vale, vale, vale, vale. Tiene sentido, tiene sentido. Yo no sabía exactamente que funcionaba así, pero tiene buena pinta. Es un mini detalle que te empiezas a… Son las típicas cosas que empiezas a plantearte cuando ya estás con ello, porque eso es uno de los mayores temores, ¿no?, de la gente, que la primera vez que tú haces una petición a una lambda que acabas de levantar, a lo mejor son 400 milisegundos de respuesta. Claro. Depende de todo lo que tengas dentro. Y 400 milisegundos de respuesta, según el sistema que estemos hablando, es mucho.
[No identificado] (00:15:42): Entonces, si siempre voy a tener esos 400 milisegundos de respuesta, a lo mejor no me conviene, pero si haces de repente la segunda petición, a lo mejor ves que el tiempo de respuesta son 20 milisegundos. Claro. Se reduce mucho. También tienes cosas como AWS ha metido con las distribuciones de CloudFront, puedes hacer cachés directamente de peticiones completas. Por lo tanto, tienes a nivel de CDN distribuidas por todo el mundo, no solo tienes tu aplicación deslocalizada, como quien dice, sino que encima la tienes cacheada, por lo que los tiempos de respuesta aumentan, disminuyen total y absolutamente a nada. Claro, porque lo tienes por CDN.
[No identificado] (00:16:24): Si tienes constantemente lo mismo. Efectivamente. Si estás en Europa, te voy a ir al CDN Europa y da igual donde lo tengas desplegado. Me suena que Google ya tiene algo también parecido en ese sentido, que no va siempre a Estados Unidos.
[No identificado] (00:16:40): Efectivamente. Y en cuanto a restricciones de RAM, sé que hay limitaciones en cuanto a AWS, que no te permite que tus lambdas, o sea, lo que ocupan tus lambdas y las dependencias en memoria ocupen más de X cantidad, pero creo que eso guarda relación también un poco a que una lambda no es un monolito. Quiero decir, es como monolito, microservicio, lambda, ¿no? Es como el siguiente pasito. Eh, postdata, David Prieto, nanoservicios para ti.
[No identificado] (00:17:25): Lo siento, tenía que hacer la broma, pero siempre habíamos dicho eso, ¿no? Al principio decíamos que cuando empezamos a trabajar juntos, pues que realmente los microservicios, pues sí, que estaba bien, pero el concepto como tal es como deberían de ser los servicios en su inicio, pero que se descontrolaron. Entonces la idea de microservicio era, vamos a acotar que hace cada una de las cosas, y efectivamente cuando los microservicios se empezaron a quedar, fragmentamos un poco más, ¿no? Es un poco el meme interno que nos tenemos y que en algún momento saldrían los nanoservicios, no los llamaron nanoservicios, sino que los llamaron lambdas, ¿no?
[No identificado] (00:18:02): Sí, hay gente que ha hecho mucha investigación al respecto.
[No identificado] (00:18:08): Realmente, o por lo menos hasta donde yo he leído, porque tampoco es que haya trabajado en plan, en proyectos super megatochos con esto, es que hubo un tiempo, una orientación de tirar las lambdas, y era que realmente yo incluso llegaba a tener hasta un repo por lambda que yo tiraba. En parte es un chungo, ¿no? Porque tú imagínate tener que, imagínate, típica API pública, ¿no? Que tienes a lo mejor 100 endpoints, tienes 100 repositorios de código distintos.
[No identificado] (00:18:41): Entonces era un poco heavy.
[No identificado] (00:18:44): Siempre hay que, bajo mi punto de vista, ser en ese sentido un poco pragmático, ¿no? El mínimo que AWS te permite, hasta donde yo recuerdo, eran 128 megas.
[No identificado] (00:18:57): Realmente una aplicación que a fin de cuentas termina siendo código, solo que después interpretado, pongamos, por ejemplo, en uno de los peores casos, ¿no?
[No identificado] (00:19:05): Imagínate, pues yo que sé, JavaScript, pero en plan minificado de no sé cuántas formas, o ni siquiera sin minificar, ¿no? Realmente tu fichero va a ocupar K, el nodo de módulos, a lo mejor, sí que se te va por un poquito para arriba, ¿no? Es así, ¿verdad? Tienes que hilar mucho más fino con respecto a qué dependencias metes, qué dependencias no.
[No identificado] (00:19:25): Pero incluso teniendo, por así decirlo, todo el código perteneciente a una misma aplicación, ¿no? Compartiendo todo el código de dominio con todas sus partes de infraestructura, de dominio, etc., etc., etc., realmente te va a ocupar más de esos 128 megas. Es relativamente complicado. Es relativamente complicado. Tienes que hacer algo muy tocho como para realmente plantearte el segregar cada una de esas piecitas de código. Claro, yo me imagino más que los problemas pueden estar cuando incurres en cosas como estás cargando toda tu base de datos en memoria, porque has hecho una query que no es correcta, cuando estás generando un fichero.
[No identificado] (00:20:05): Pero me imagino que para eso también habrán estrategias de, oye, es que el approach que estás siguiendo no es el correcto.
[No identificado] (00:20:12): Está cual, o sea, volvemos a la misma. El mismo problema que te puede pasar en una lambda te puede pasar en una máquina, en un Java, con el Tomcat. Tienes su memoria limitada y hasta ahí llegamos. Y si la lias, la liaste tú. No la estás liando ni la lambda, ni el Tomcat, ni nadie. La estás liando tú. Claro.
[No identificado] (00:20:32): Sí, sí, al final la solución que todos tomaríamos al inicio, ya no, por suerte, pero lo que todos decíamos en su momento, ah, pues métele más RAM. Ah, pues métele más disco duro. Y dice, igual aquí ya cambia porque paga más. O sea, quieres más RAM, paga más. Quieres más RAM, paga más. Efectivamente. Y ahí duele. Efectivamente.
[No identificado] (00:20:53): A ver, si realmente, por ejemplo, yo también he trabajado con AWS en cuanto a haciéndolo máquinas, ¿no? En plan, gestionando máquinas. Volvemos a la misma.
[No identificado] (00:21:03): ¿Te hace falta una máquina de 32 gigas de RAM en un entorno de producción? Pues, entonces tienes un problema muy chungo. Claro. ¿Sabes? Claro, no. En realidad no es un problema de infraestructura. Muy probablemente sea un problema de código. O que estás utilizando la herramienta inadecuada para tus necesidades. Efectivamente. Que también puede ser. ¿Consideras que AWS es la solución para todo? O que hay escenarios donde es preferible… A ver, no te digo de normal. Yo sé que si nos ponemos todo se puede hacer con AWS, pero que hay escenarios donde tú dirás, mira, quizás aquí, en este escenario muy controlado,
[No identificado] (00:21:45): Es la excepción donde AWS a lo mejor no encajaría.
[No identificado] (00:21:50): Sí.
[No identificado] (00:21:51): A ver, siempre están los casos extremos, ¿no? Hay mucha gente que me ha llegado y me ha dicho, no, pero es que serverless es para cosas con poco tráfico. Y yo les pongo el ejemplo de… No, Lego. Mira Lego, por ejemplo. ¿Sabes? Lego tiene toda su parte de… Todo lo que es gestión de Lego en cuanto a infraestructura web, ventas, todo, lo están gestionando a través de Lambda.
[No identificado] (00:22:13): Vale.
[No identificado] (00:22:15): ¿Sabes? Y Lego no es una compañía que sea… O por lo menos, tal como yo lo veo, no es precisamente chiquitita. No. Si no me equivoco, Secotec, toda la parte de las congas y todo esto, lo está haciendo con IoT a través de AWS.
[No identificado] (00:22:31): Netflix, si no me equivoco, todo el procesado… Esto, por lo menos hace unos años. Todo el procesado de los ficheros que les llegaba de las productoras de cine, todo el procesado de esos ficheros los hacía a través de Lambda.
[No identificado] (00:22:45): Claro. Y aún así, me imagino que también parte de… O sea, al final es un producto de Amazon, ¿no? Amazon no es una plataforma precisamente pequeña. Ahora mismo tienen Amazon Music, podcast en Amazon Music, disclaimer. Tienen la parte de Amazon Videos, tienen la parte de… Pues toda la parte de infraestructura que te da de AWS, su propio e-commerce. O sea, es ahora mismo enorme. Y todo eso ellos lo trabajan con este sistema. Efectivamente. AWS realmente nació como necesidad hacia sus propios productos que estaban generando y desarrollando ellos internamente.
[No identificado] (00:23:25): Como anécdota, siempre… Incluso yo fallé en su momento, ¿no? Y ahora la pregunta es, ¿qué servicio crees que fue el primero que se sacó en AWS? AWS. Uf, pregunta trampa. A ver, te diría que por renombre y demás las Lambdas, pero no le veo sentido. ¿Quizás la base de datos?
[No identificado] (00:23:48): Lo primero que se hicieron fueron las colas de mensajes. Vaya. ¿Sí? O sea… El primer servicio que salió de AWS al mercado fue el…
[No identificado] (00:24:02): Chas, no me sé el nombre. Básicamente el que genera colas de mensajes. Ajá. Claro. Ese fue el primer servicio. Entonces, ahí es cuando te planteas la de que probablemente su primera necesidad fue de hacer comunicación asíncrona entre sus servicios, por ejemplo. Claro. Y a partir de ahí empieza a surgir todo lo demás. El cómo… Efectivamente. Crear esos microservicios que al final los acaban minimificando más. Cómo almacenar esos datos de forma atómica para cada uno de esos microservicios. Barra Lambdas.
[No identificado] (00:24:33): Cómo… Vale. Todo, todo, todo. Ya te digo. En cuanto a qué es lo que no se puede hacer con AWS. Pues ahora mismo te diría que nada. ¿Qué es lo que recomendaría no hacer con AWS? Pues a ver, volvemos a la misma. Además, si no te puedes, entre comillas, permitir el gasto de un servicio en el paso del tiempo, está claro que a lo mejor si vas a mantener la máquina 10 años te merece más la pena gastarte tú el dinero en esa pieza de infraestructura.
[No identificado] (00:25:03): Pero siempre hay que tener en cuenta un gasto que siempre se nos olvida en cuanto a hacer cálculos y es el mantenimiento de la misma.
[No identificado] (00:25:11): Efectivamente. Y seguridad. Yo personalmente… Efectivamente. Bueno, seguridad, a fin de cuentas, puedes decir la de, bueno, pues monto el firewall y sé que el único puerto que permito es esto, es este concreto, el 443, porque sé que toda mi plataforma va a ir por HTTPS y mi único tráfico va a venir por este DNS. Punto. Ya está. Eso es lo más aislado que puedes estar del mundo exterior, ¿no? Como quien dice. Y si alguien quiere modificar algo en cuanto a mi pieza de infra, que sea un site. Eso de estar conectándome por SSH, no, ¿no? Porque, lo dicho, puede incurrir en un riesgo de seguridad.
[No identificado] (00:25:48): Pero es esa, ¿no? Pero el mantenimiento de esas máquinas, ¿quién lo hace? Es la de siempre. Yo personalmente, desde que descubrí el serverless, me ha encantado justamente por eso. Porque lo que tengo que hacer de mantenimiento en cuanto a la infraestructura, es el código que yo genero con respecto a esa pieza de infraestructura. Como mucho alguna que otra versión de las APIs que ellos manejan, pero tampoco suele ser un cambio muy drástico. O por lo menos yo todavía no me he topado con ninguno. Bueno, obviamente, pues lo de siempre, eso se paga, ¿no? A ver, es todo, ¿no?
[No identificado] (00:26:25): Pero bueno, al final hoy en día que no se paga.
[No identificado] (00:26:29): Es que es eso también, ¿no? Entonces, yo personalmente, pues, he estado en varios proyectos en los que me ha tocado también, no solo como desarrollador, sino también hacer parte de mantenimiento de infraestructura. Hablando en cuanto a máquinas, del nivel de tener que estar pendiente del Chrome Tab de una máquina, ¿vale? Para saber qué hacíamos o qué dejábamos de hacer.
[No identificado] (00:26:51): Entonces, considero que, si bien es verdad que todas esas cosas aportan valor de forma indirecta, yo me gusta más la otra parte, la otra cara de la moneda, que es el aportar directamente valor al negocio. Claro, te puedes centrar. Y estar más a nivel de servicio, sí. Porque también me permite centrarme más en detalles más generales, en toda la visión completa de todo lo que viene siendo la aplicación. Yo no tengo que estar centrado en específicamente, ¿contra estar al disco lleno? No, paso. Eso ya que se encargue otro.
[No identificado] (00:27:29): Igualmente, cuando montas tu proyecto, tu aplicación, de alguna forma tienes que definir cuáles son tus recursos de infraestructura que vas a utilizar. O sea, quiero decir, igualmente sigues teniendo un control de la infraestructura, pero de la infraestructura vigente, no del mantenimiento. Decir, ah, pues a ver cómo están los discos, ah, pues a ver cómo está esto, sino simplemente necesito esto, necesito esto u otro. ¿Cómo convergen entre sí? Y listo. Sí, yo tal como lo veo, yo no consumo infraestructura, yo consumo servicios. Vale. Tocando serverlo.
[No identificado] (00:28:08): Que necesito una forma de hacer PupSup, pues uso este servicio, punto. Obviamente tienes que configurar en cuanto a nivel de infra, lo que tú dices, ¿no? Pues que este en concreto sea el que va a consumir y este hace el trigger cuando consuma de esta cola, pues va a lanzar esta lambda. A fin de cuentas no deja de ser como si fuera una especie de diagrama de todas las piezas de tu infraestructura que tienes montadas. Pero lejos de eso yo no tengo que estar eso, preocupándome de, contra, ¿habrá salido un parche de seguridad que me pueda afectar? No.
[No identificado] (00:28:43): Solo me preocupa en todo caso de la seguridad del código que yo estoy generando. Claro, tú se pende. Que obviamente tiene, exacto, que es una parte muy importante y por la que podemos liarla muy parda. Yo he visto charlas de gente que han conseguido meterse a través del API Gateway en las landas y modificar el código de dentro. ¿Vale?
[No identificado] (00:29:04): Claro, porque al final… Por una mala configuración, ¿sabes? Claro, pero al final las landas son eso, son ficheros que están ahí donde está el código fuente y que se llaman y se ejecutan. Si tú llegas a ese código fuente, pues ya estás perdido. Es la de siempre, ¿no? La nube… No, la nube es el ordenador de otra persona. Punto.
[No identificado] (00:29:27): Básicamente. Bueno, otro de los principales… A ver, no problemas, pero sí que ataques más comunes. Me resultó muy curioso cuando me lo contaron que es básicamente que ya no te deniegan los servicios. O sea, no… A ver, no te hacen un ataque de denegación de servicios como tal. O sea, cuando te hacen un ataque de denegación de servicios, realmente tú como Lambda o como proveedor de servicios, siempre y cuando no le tengas una configuración extensiva, te va a ir levantando instancias y te va a ir dando… Respondiendo, respondiendo. Pero a mayor consumo, más instancias y a más instancias, más golpe a la cartera, ¿no?
[No identificado] (00:30:10): Otra triquiñuela. Realmente sí hay una especie de límite. ¿Vale? Que son… Si no me equivoco, no sé si eran mil o diez mil Lambdas simultáneas. Vale. Pero volvemos a la misma. Tú vas a tener mil peticiones en simultáneo corriendo. Y dentro de dos, tres segundos, o dentro de veinte milisegundos, otras mil. Y dentro de otras veinte milisegundos, otras mil. Son límites bastante por encima de cualquier sistema de hoy en día que no sea en plan constante darle mucha leña. Claro.
[No identificado] (00:30:44): La cosa es que si alguien te hace un ataque de negocio y de servicio, no te va a tirar el servicio, pero te va a tirar la cartera.
[No identificado] (00:30:53): Efectivamente. Ahí es donde… Siempre…
[No identificado] (00:30:56): En esa parte hay que darle un voto a favor a AWS. Yo me imagino que Azure y Google Cloud Platform también harán lo mismo. Puedes poner avisos en cuanto a tema de cuando llegues a cierto límite de dinero que hayas pasado tú mensualmente, él te pega un aviso en plan de oye mira que ya has llegado a lo que tú tenías pensado llegar. Claro.
[No identificado] (00:31:19): Yo… Sí. Que eso para un negocio igualmente puede ser un golpe porque tú dices bueno, supongamos es a principio de mes, me han hecho un ataque de denegación de cartera, llamémoslo así. Sí. Estamos a día dos del mes, me han suplido todo el capital que tenía para este mes o para este semestre y ahora que hacemos… Cerramos el servicio, echamos cierre por seis meses porque es un poco complicado, pero creo que no es solo un tema que ocurre con AWS, sino que es en sí lo que ocurre hoy con todos los servicios online que escalan.
[No identificado] (00:31:53): Quiero decir, todo aquello que tenga autoescalado pues tienes que hilar muy fino porque… Sí, sí, sí, no, es la de siempre, ¿no? Todo este tipo de cosas siempre hay que tenerlas también en cuenta. Por mucho que digamos que es código lambda y tal, siempre tienes que tener en cuenta cualquier imprevisto que tú no… Yo puedo saber del mismo modo que cualquier otro servicio de qué IP me están tirando. Si tú me estás lanzando 10.000 peticiones de la misma IP, oye, ya te bloqueo, ¿sabes? Y hay mecanismos, incluso no sé si API Gateway provee directamente de algún tipo de bloqueo sobre esto, que creo que sí.
[No identificado] (00:32:31): Te diría que sí, que AWS y el resto de proveedores ya no son tontos. Por decirlo de alguna forma, incluso si te hacen un ataque masificado, descentralizado, con redes, ¿no? Con ataques, con zombies, con bots, pues ya la propia API Gateway te protege y te dice ¡Ey, amigo! No sabemos quién eres, pero te están intentando dar un palo. Este comportamiento no es muy bueno, así que… Que sea usted consciente de que hemos cortado el tráfico en pos de salvar su cartera.
[No identificado] (00:33:07): Y si no siempre lo sube es tener, pues toda la parte de observabilidad, que es otra de las partes en las que sí me gustaría empezar a centrarme después de esto. El cambio de si nos casamos o no con la tecnología, toda la parte de observabilidad es súper importante en cualquier aplicación, no solo serverless. Y volvemos a lo mismo, siempre puedes generar tú tus propios automatismos, ¿no? Si bien tenemos ya soluciones hechas, a mí si de repente me llegan 10.000 peticiones y yo no las esperaba, yo corto servicios. A fin de cuentas puedo entrar con unas credenciales de AWS con permiso suficiente para decir
[No identificado] (00:33:42): ¡Oye, corta el grifo! Despliegame esta landa, que eso a lo mejor no sería tan fácil en cuanto a un… Si no estuviera yo solo manejando servicios, sino realmente tuviese yo una máquina concreta tal.
[No identificado] (00:33:57): Entiendo, entiendo, entiendo, entiendo. Guay. Me surge otra duda, y esto es porque… Bueno, nosotros no inventamos nombres súper guays y demás. Tenemos el concepto de serverless, o sea, trabajamos y desplegamos sin server. Y hemos estado hablando de AWS, serverless, AWS, serverless.
[No identificado] (00:34:20): Pero aquí hay cierta ambigüedad, ¿no? O sea, serverless es ejecución sin servidor, los otros proveedores también te lo dan. Pero también es cierto que hay una librería, un framework entero que se llama serverless. ¿Cierto? ¿O estoy yo equivocado? Sí, lo que viene como librería, no sé si puede ser que te estés refiriendo a serverless framework. Exacto, exacto. Efectivamente. Pero claro, nadie dice serverless framework, todo el mundo dice serverless. No, yo uso serverless y ya te quedas como… Eso ya depende a quién le preguntes, porque AWS tiene el suyo propio, que es AWS SAM, que es serverless application model, ¿vale?
[No identificado] (00:35:01): Que viene a ser, entre comillas, lo mismo, pero sin la parte de única y exclusivamente. O sea, es centrado única y exclusivamente en AWS. Vale. Serverless framework viene a tratar de romper esa barrera que justo estábamos hablando, ¿no? Y es la parte de, oye, yo tengo mis landas, pero yo no quiero solo depender de un servicio, ¿no?
[No identificado] (00:35:28): A mí personalmente, pues me parece que va un poco del palo de Terraform, ¿no? Cuando tú tiras Terraform, en parte siempre, siempre, siempre, o por lo menos el código Terraform que yo he visto, y que por eso tampoco me ha llegado a convencer del todo, es el hecho de que siempre hay algo que es específico de un proveedor concreto. Y lo mismo pasa con serverless framework, porque llega un punto en el que tienes que escribir,
[No identificado] (00:35:57): Por ejemplo, en este caso, por ejemplo, para AWS, AWS tiene su propio lenguaje, ¿cómo quien dice? De definición de recursos de infraestructura, que es CloudTron, ¿vale? Pues llega un punto en serverless framework que tienes que escribir ese CloudTron. Entonces, es la misma, ¿no? Llego a definir ciertas cosas sin estar dependiendo del proveedor, pero al mismo tiempo estoy anclado al mismo, ¿no? Sí. Entonces, a mí personalmente me gusta por la forma en la que tiene de definir de las lambdas y tal, porque me abstrae de la parte de CloudTron de AWS, y porque también tiene como sus propias librerías y sus plugins para hacer cositas chachis,
[No identificado] (00:36:40): Como en plan desacoplar, hacer cada paquetito distinto para una lambda, para tú poder un zip en cada una de ellas distinto.
[No identificado] (00:36:50): Pero es la de siempre. Realmente no estoy completamente 100% desacoplado de la tecnología, que es, entre comillas, la bandera que ellos tiran, ¿no? Claro. También es verdad que tienen su parte de CICD propia, porque tienen su propio servicio de CICD, ¿vale? De integración continua y de despliegue continuo, y su propio sistema de observabilidad, ¿vale? Eso también lo tienen, tienen ellos esa parte. Pero es la de siempre. Es para venderte su propio producto, es normal, es lógico. Yo personalmente lo uso, pues eso, para hacerme la vida más fácil en cuanto a la definición de rutas y cositas del estilo.
[No identificado] (00:37:29): Vamos, al final el símil es como cuando trabajas en una aplicación multiplataforma, cuando haces una app mobile, que dices, oye, mira, pues utilizamos React Native, utilizamos Xamarin, utilizamos Flutter. Dices, a ver, sí, el código de dominio va a estar escrito en el lenguaje que toca, pero siempre cuando ya bajas a muy bajo nivel, hay una parte que tienes, o sea, esa interfaz tienes que implementarla bien para iOS, bien para Android, porque el código nativo no está aún. Entonces es inevitable. Es algo irremediable. Exacto.
[No identificado] (00:38:06): Entonces ellos te cubren por debajo lo que tienen en su mano, pero lo que no está en su mano, pues te va a tocar hacerlo a ti. Entiendo que es un poco eso. Por ejemplo, sería ideal que yo de nada que pongo que voy a tirar de un endpoint en serverless framework, él ya me genere, como quien dice, la pieza… Bueno, mentira, por ejemplo, para el endpoint sí que lo hace, ¿vale? Para el endpoint sí que te genera directamente la pieza de infraestructura de la API Gateway, yo no tengo que estar definiendo el CloudFront debajo, ¿no?
[No identificado] (00:38:33): Pero, por ejemplo, si yo voy a publicar en un topic de SNS, ¿vale? Para típico momento asíncrono, ¿no? De típico PupSup. Ahí yo sí que tengo que declarar debajo el topic de SNS con sus propias definiciones, etc. Sería idílico que yo pusiera la de, oye, pues para esta lambda, para este topic me va a consumir esto y va a publicar aquí. Vale. Pero como no es así todavía, pues no estamos del 100% desacoplados. Es un coñazo para ellos a fin de cuentas, ¿no? Porque no solo está AWS, Google Cloud Platform y en este caso también Azure,
[No identificado] (00:39:13): Que encima después cada uno tendrá sus 20.000 servicios para eso concretamente. Entonces es como, ¿cuál quieres usar, no? Claro. Siempre es el win-win, ¿no? Como quien dice, no todo es perfecto, no todo es maravilloso, sino que hay que saber qué usar en qué momento. Y la de siempre, no tratar de usar un martillo para demoler una casa, sino que usas una herramienta para lo que te pueda aportar, simplemente y llanamente. Claro, claro. Claro, claro. No, a ver, al final es como todo, bien dice. Es una herramienta que es para lo que es y no puede, no sirve como una baja multiuso.
[No identificado] (00:39:56): O sea, tiene sus limitaciones. Te iba a comentar, ¿cómo ves que está yendo la evolución de este uso de servicios en los últimos años? Porque mi sensación al menos es que Tugumbum está en boca de todo el mundo. Sí que hay una gran cantidad de empresas que han abogado por el uso de estas tecnologías, pero hay otras que siguen estando en un approach de monolitos, de microservicios,
[No identificado] (00:40:34): Incluso sin ir a la nube, sino con sus propios servidores y demás. ¿Crees que esto es una situación que se va a mantener bastante en el tiempo? ¿Qué es la tendencia natural a que todo poco a poco se vaya llevando a estos proveedores y se vayan externalizando servicios?
[No identificado] (00:40:52): ¿Cómo lo ves? Un poco tu visión de aquí. Vamos a jugar a hacer la brujita de la bola de cristal. ¿Y qué crees que pasará de aquí a 5 o 10 años?
[No identificado] (00:41:04): Es como todo. Yo creo que seguirá habiendo de todo. Yo creo que la tendencia, y no sé si gracias a Dios o por desgracia, es de hacer tirada siempre más hacia la nube.
[No identificado] (00:41:16): Porque hay una cosa muy importante que tenemos en la nube, y es esa disponibilidad inmediata de si yo necesito, por poner un ejemplo, una máquina con 256 GB de RAM hoy, de hoy a mañana, la puedo tener. Eso es algo que a día de hoy, que yo sepa, no hay ningún proveedor de hardware que te lo monten de un día para otro en tu granja de servidor. Hasta el punto de que a lo mejor ni siquiera la tienes de aquí a 6 meses.
[No identificado] (00:41:49): Porque se ha dado el caso de que pedidas incluso de solo una máquina virtual con X recursos. Estamos hablando de un on-site que tenía su propio VMware. Y solo para poder meter los discos en esa granja y asignarlos, llegamos a pasar más de 7 meses.
[No identificado] (00:42:13): La persona que iba físicamente tenía una demanda de trabajo bastante grave. El rollo es que no había slots. La putada fue que no había slots. Entonces, claro, toda esa versatilidad que ya nos brinda la nube, ya ni siquiera en cuanto a la parte de servicios, sino en cuanto a infra de verdad. Lo que antes se le llamaba el selenio. Toda esa parte de selenio, de poder tener… Lo he dicho, es literalmente un click, como quien dice. Y puedo tener una máquina más grande que lo que antes es toda mi granja de servidores.
[No identificado] (00:42:48): Yo creo que va a ser la tendencia natural.
[No identificado] (00:42:52): Por suerte o por desgracia, lo he dicho. Porque habrá gente que le guste mucho toda la parte de cacharreo. Y de tener sus máquinas personalizadas. Pero yo creo que lo único que no cambia es el dónde tengo la máquina. Para mí, o tal como yo lo veo, si quieres tirar de approach, no voy a llamarlo antiguo porque se sigue haciendo a día de hoy y es la mayoría, tal como tú lo has dicho. Pero si queremos tirar de approach tradicional, de yo customizo mi máquina, solo la tengo con el sistema operativo y a día de ahí yo le voy poniendo cosas.
[No identificado] (00:43:22): Eso lo puedes tener a día de hoy sin problema.
[No identificado] (00:43:26): En cuanto al tema de servicios,
[No identificado] (00:43:29): Estoy de acuerdo en que hubo un boom porque fue como muy novedoso en su momento. Del mismo modo que la parte de Docker y contenedores.
[No identificado] (00:43:40): Pero considero que va a llegar al punto en el que no haya empresa en el que algo no lo tenga de esa manera. Porque a fin de cuentas es como hoy en día el Docker.
[No identificado] (00:43:49): Docker tuvo su boom, un montón de gente lo usó de repente, empezó a dar un montón de problemas.
[No identificado] (00:43:56): ¿Vale? No.
[No identificado] (00:43:58): ¿Vale? Y a día de hoy, pues, por lo menos no hay empresa por la que yo haya pasado que no conozca por lo menos lo que es Docker y que haya tirado o por lo menos hecho sus pruebitas o sus pinitos con Docker, ¿no?
[No identificado] (00:44:13): Entonces, para desgracia de serverless, que diga, ya se está metiendo el mundo de Docker dentro del mundo serverless, yo no estoy de acuerdo. Para mí son cosas distintas. Pero bueno, es lo que toca. Era un paso que realmente es como natural, en cierto modo, a fin de cuentas, viene a ser algo de lo mismo, ¿no? Pero en vez de ser solo una función, como quien dice, que volvemos a la misma. Para mí las lambdas no son solo una función. Para eso esto es otra conversación que puede ser larga y entendida, ¿no? De cuánto código debería estar metido dentro de una lambda.
[No identificado] (00:44:51): Pero considero que a futuro, si bien no va a ir todo por serverless, porque es lógico que no es algo que se esté dando mucho a día de hoy todavía.
[No identificado] (00:45:03): En cuanto a la nube, sí. Pero porque para mí es el paso natural, ¿no? En vez de yo tener que estar manteniendo una granja que alguien me la mantenga y yo solo tenga que conectarme a ella,
[No identificado] (00:45:16): Creo que es una de esas cosas que nos ahorra un montón de problemas. Y quieras o no, solo el ahorrarnos esos problemas ya aporta al negocio. Claro. Es como el negocio de toda la vida. O sea, tú tienes un negocio pequeño. Al ser pequeño, pues no necesitas contratar gente. Tú mismo haces todo. En cuanto empiezas a crecer, que las responsabilidades crecen. Y en un momento en el que dejas de tener el personal especializado para… Entonces empiezas a externalizar esos servicios de lavandería, limpieza, restauración, donde tú dices, mira, si yo soy un hotel, al final o tengo yo a todos los trabajadores
[No identificado] (00:46:02): O si tengo cadenas de, al final tendré que acabar tirando por servicios que me provean a mí y yo centrarme en lo que es lo mío. Muchas empresas de desarrollo pasan, externalizas tus servicios de recursos humanos, externalizas tus servicios de diseño y tú te centras solo en lo que es la programación, por ejemplo. Externalizas tú marketing, porque no tienes capacidad.
[No identificado] (00:46:27): Para mí un ejemplo claro histórico de esto es en cuanto al tema de los repositorios de código. ¿Vale? Yo, una vez más, por suerte, por desgracia, he tenido que trabajar con el papi de IT y de todos estos que se llama CVS, ¿Vale? Que a fin de cuentas era, yo tengo el código, pero lo tengo en una máquina separada y con una especie de cliente yo me conectaba a esa máquina, creaba yo mi versión concreta y ya está, ¿no? A fin de cuentas, todo el mundo era como súper mega reacio. Me imagino que en su momento, cuando salió Git, cuando salió GitHub, SARS-FORCE,
[No identificado] (00:47:06): Creo que se llama la página… Sí, SARS-FORCE. ¿Vale? Que fue como los pioneros de todos esos repositorios remotos, ¿Vale? Cuando eran remotos de… Cuando ya es un remoto de verdad, no que yo lo tengo local en una máquina, rollo en plan, se me jode el disco, olvídate del repositorio, ¿Vale? Sino que ya es lo mismo el ordenador de otra persona, ¿Vale? Esa tendencia ha llegado.
[No identificado] (00:47:33): A pesar de que mucha gente habrá dicho la de… No, es que eso es inseguro, porque no tenemos en nosotros el control del código.
[No identificado] (00:47:41): Ha llegado. ¿Por qué? Porque siempre hay que ser realistas y tratamos siempre de hacernos la vida lo más cómoda posible, ¿no? Entonces, si me puedo ahorrar… Uno, dinero en… Las cosas como son, en dinero, en gente que me mantenga de esas máquinas. Y dos, en gente que sí o sí tenga que estar en una localización concreta, pago el servicio que probablemente me salga más barato y ya tengo el… Ya me suple el mismo problema, ¿no? Esa misma necesidad. Y tienes el soporte. Quiero decir, no es lo mismo cuando tú tienes un problema que tienes que buscar, pues vamos a solucionarlo,
[No identificado] (00:48:21): Vamos a invertir tiempo y recursos, ya sea de personas, ya sea económicos, en solucionarlo o cuando tienes un sistema de soporte que dices, me está fallando tu servicio, es tu servicio, lo solucionas tú y ellos tendrán su personal especializado que en tiempo récord con sus ANS o con lo que quiera que tengan ellos internamente, te lo solucionan. Sí, una cosa que me llamó mucho la atención y que dije, contra, pues voy a hacerme la certificación. Al final nunca lo hice, ¿no? Nosotros en redes trabajábamos con, tuvimos la suerte de trabajar con routers Cisco, ¿vale? Y con switches Cisco. No sé si lo sabes,
[No identificado] (00:48:59): Pero Cisco también tiene sus propias certificaciones, ¿vale? Sí. En cuanto a temas de redes, ¿vale? Sí. Pues, nos contaron una historia, ¿vale? De que el hospital de Candelaria se les cayó no sé qué red, ¿vale? Pues, el colega que tuvieron que pagar para venir, para que solucionase el problema en un día 24, 48 horas, se dejaron 6 mil y pico euros. Sí.
[No identificado] (00:49:29): ¿Vale? Sí. Solo para traerte a esa persona. De hecho, yo estudié, antes de estudiar programación, estudié administración de sistemas informáticos en red y una de las cosas que
[No identificado] (00:49:42): Intentamos hacer fue certificarnos de Cisco precisamente porque ya vamos a entrar en un terreno que no tiene que ver con lo que estamos hablando, pero sí que es verdad que a día de hoy tiene muchísima más salida profesional lo que es el desarrollo de software que lo que es la administración de sistemas informáticos en red, ojo, no estoy desmeritando el trabajo de los compañeros, no estoy diciendo que no sea útil ni estoy diciendo que no haya trabajo, pero de cara a hacer la inserción laboral es más sencillo hacerlo en el mundo del desarrollo. Sí, sí, totalmente de acuerdo. Eso creo que es innegable, ¿sabes?
[No identificado] (00:50:22): ¿Dónde pueden tener cabida todos estos perfiles ahora de administración de sistemas? Pues en todos estos proveedores de cloud. ¿Sabes? Porque incluso aquí en España AWS está montando región en España, si no me equivoco en Zaragoza, puede ser, creo que sí.
[No identificado] (00:50:42): Estaba en principio para, y querían sacarla para 2023 o mis 24. La anunciaron hace un año o dos. Y están montando toda la granja de servidores. Entonces, ¿ahí quién hace falta? Pues ni tú ni yo, ¿sabes? Ahí no hace falta la gente que programe, sino gente que meta ahí cables y que cacharré y que administre todo eso. Claro. Y que además que es algo que es tan específico que obviamente se ganará bien. ¿Qué quiero decir? Efectivamente. Es como el programador de COOL de hoy en día, ¿sabes? Es la misma. Lo siento, pero es que es así. No, no, es así. Nadie quiere trabajar en COOL,
[No identificado] (00:51:20): Pero el que lo sigue haciendo tiene su especialización y tiene que ganarlo por ello, porque además es algo que por A o por B o nadie sabe hacerlo o nadie quiere hacerlo. Entonces, mérito para ti. Oye, chapo, es lo que hay. Es como el mercado de los coches. Que quieres un Lamborghini, pues hay relativamente tan pocos que tienes que pagar por ello. Punto. Eso es el precio y eso es lo que hay. Si te gusta bien y si no, pues búscate otro coche. ¿Sabes? Es lo que toca, ¿no? Pues mira, justo ahora que estamos hablando de la parte monetaria, vamos a dar el salto
[No identificado] (00:51:53): A todo lo opuesto. Estamos hablando de temas de salario, bueno, del coste que tiene. Vámonos a la otra parte, vámonos a la parte open source. ¿Cómo casa ahora mismo AWS con open source? ¿Crees que tiene cabida? ¿Crees que ahora mismo no tiene cabida? Porque al final open source, pues si trabajas con alguno de estos servicios, alguien será quien tenga por detrás que pagar, ¿no? Para desplegar esas lambdas y dar esa… Curiosamente,
[No identificado] (00:52:28): He tenido la suerte de mini colaborar, mini colaborar, porque tampoco ha sido mucho, tras haberme informado, porque da la casualidad de que AWS ofrece 2.000 dólares al año a organizaciones sin ánimo de lucro, ¿vale? Para que se gasten en infraestructura al año ellos, porque volvemos a la misma, si es sin ánimo de lucro, el tema de la financiación por norma general suele ser algo complicado, ¿no? Entonces, tenemos el proyecto este de huella positiva, que el InMine empezó a colaborar, yo ya te digo, yo tuve la suerte de colaborar un tiempo con ellos, y una de las cosas que me siento orgulloso de haber colaborado
[No identificado] (00:53:10): Es justamente eso, de decir, mira, que chicos que sepan que AWS me estoy informando y tiene esta parte, entonces, creo que casa súper bien, volvemos a la misma, como es open source, no tienes un espacio físico, no tienes toda esa parte, a lo mejor, pues, hoy es una persona de Polonia, mañana es una persona de Estados Unidos, y lo mismo mañana es de Japón, ¿no? Entonces, creo que tener esa flexibilidad y tener toda esta parte de poder levantar servicios en el momento en el que tú quieras, y servicios que, por ejemplo, server, les vuelvo a lo mismo, en cuanto a coste,
[No identificado] (00:53:47): Creo que son las primeras 50.000 llamadas, o ponga aquí un número que ahora mismo no me acuerdo, pueden entrar y verlo en la lista de capas gratuitas de AWS, es gratis, ¿vale? Es gratis, y estamos hablando de una cantidad sustanciosa, que a lo mejor una aplicación que ya ni siquiera la típica aplicación de gestión de,
[No identificado] (00:54:11): Pongamos un negocio, típico bar que tiene su facturación, o típica peluquería que lleva su cita, no, no, estamos hablando de aplicaciones mucho más grandes, porque son miles de peticiones, incluso no sé si son millones, creo que es el primer millón o algo así, es una locura, lo tienes gratis, que sí, que después pagas por otras cosas, ¿no? Pero, pero igualmente tienes esos 2.000 euros que te dan.
[No identificado] (00:54:36): Exacto, ¿no? Entonces, quieras o no,
[No identificado] (00:54:39): Obviamente es la de siempre, ¿no? Tienes que escoger muy bien también los servicios que vas a usar, porque como todo hay servicios más caros que otros, yo personalmente, y me llevé una sorpresa en su momento,
[No identificado] (00:54:51): ¿vale? Aquí pongo anécdota personal, estaba yo con mis proyectos personales y estaba probando RDS, ¿vale? RDS no deja de ser un servicio que te provee de una máquina de S2, ¿vale? En la que él te mete dentro una instancia de base de datos, la que tú escogas. Creo que en este caso haya puesto dos res de SQL, da igual, ponga aquí una cualquiera, esa no es la parte relevante. ¿Qué pasa? Como RDS como tal no es solo el servicio de la base de datos, tienes que pagar la base de datos, en sí la gestión de la base de datos, tienes que pagar las migraciones,
[No identificado] (00:55:24): Tienes que pagar la máquina en la que está ejecutándose, etc, etc, etc, y encima cuando tú le das a que duerma, ¿no? A que termine en instancia, él, por maravillosidad de la vida de AWS, cosa que no comparto, no me parece lógica, él, pasado un tiempo te vuelvo a levantar esa instancia en plan de, oye, que esto estaba parado, yo te la levanto por si acaso tú lo necesitabas, yo me llevo una sorpresa de un mes 32 euros a las 12 de la mañana, ¿sabes? Y yo no había usado eso, ¿sabes? Y ya no dormiste más esa noche. No, no, no, no dormí,
[No identificado] (00:55:57): Fue en plan de, pero ¿qué haces? Pero vamos a ver, que yo solo levanté esto un fin de semana, ¿sabes? Y le di a terminar como que 32 euros, entonces tienes que escoger muy bien también los servicios a los que usas, ¿no? Si tienes, pero esto ya es de sentido común, ¿no? Si tengo una financiación limitada, obviamente tengo que escoger muy bien qué servicios uso, ¿no? Y creo que el open source en este sentido, pues, y probablemente no solo AWS provea de temas para organizaciones de ánimo de lucro, porque hasta donde yo sé sin más, JetBrains, los IDEs te los regalas
[No identificado] (00:56:37): Y los vas a usar para ser open source, si no me equivoco, Microsoft tiene parte que es parecido, ¿sabes? Te regala también los IDEs o algún rollo del estilo si lo vas a hacer para open source. Entonces, creo que es una sinergia de cosas, ¿no? En ese sentido, pues, las empresas que saben que el open source aporta valor hoy en día al mercado invierten en ello y después tú como persona que está haciendo open source, pues, también te tienes que buscar los recursos, ¿no? Y lo me he dicho, si eso requiere yo tener una llamada con el comercial de AWS, si tengo que tenerla, pues,
[No identificado] (00:57:16): La tengo. En plan de, mira, ¿te interesa invertir en esto? Porque a lo mejor a mí también me interesa usar tu producto, entonces, quiero que tú estés como partner de este proyecto, ¿no? Sí. Entonces, creo que casa muy bien porque es eso, es la ventaja de la flexibilidad que otorga. Es un win-win y al final es como todo, ¿no? O sea, si nos vamos al punto de vista de a los estudiantes, porque a los estudiantes muchas veces le dan licencias gratuitas porque lo empiezas a usar con licencias gratuitas y después cuando llegas a la vida profesional
[No identificado] (00:57:49): Lo sigues comprando o lo empiezas a comprar porque es la herramienta que conoces, en la que tienes confianza y que te ha dado resultados. En el caso del open source es lo mismo, tú empiezas un proyecto open source, puede ser toda su vida open source o puede que no, puede que te llegue una empresa por detrás, adopte ese proyecto y esa empresa ya tenga los desarrolladores, esa comunidad de desarrolladores trabajando para ella que van a trabajar y que esa empresa externa va a inyectar dinero, ¿dónde? En, inserte aquí su proveedor, AWS, Amazon, AWS, Google, Microsoft, whatever, ¿no?
[No identificado] (00:58:28): Sí, sí, o sea, yo personalmente, pues,
[No identificado] (00:58:32): Mi approach con el open source ha sido relativamente corto y tal, ¿no? Pero si es verdad que, que no consigo proyectos open source con, con cierta iniciativa hacia adelante, ¿no? Me parece muy complicado que hoy en día haya un proyecto open source sin que haya una empresa detrás, las cosas como son. Es muy complicado tirar tú para adelante un proyecto tú solo, ¿vale? Y, y que son horas que todos tenemos también nuestro trabajo, ¿sabes? Si a lo mejor vivo puede ser de cualquier otra cosa y solo me dedico a eso, pues, mi tiempo libre, pues, vale, pero no va a tener el mismo empuje,
[No identificado] (00:59:14): Por ejemplo, que puede tener, pues, no de como proyecto open source, ¿sabes? Detrás hay una empresa o cualquier otro, React, que por detrás está Facebook, Angular, que por detrás está Google, siempre, siempre, siempre tiene que haber alguna empresa por detrás que ponga dinero y bien, pues, puede ser para poner los desarrolladores dentro del proyecto o se puede hacer en cuanto a colaboración de, oye, mira, que en ese caso, pues, dame solo lo necesario para tener esto en la nube y ya con eso vamos tirando, ¿sabes? Igualmente, o sea, también depende del nivel de open source y estamos hablando de servicios o aplicaciones completas open source,
[No identificado] (00:59:53): Pero si al final es una pequeña librería de utilidad, pues, al final eso no necesitas tampoco a AWS para, a lo mejor haces tus pruebas o la comunidad hace sus pruebas, pero con esa capa gratuita que tienes te es más que suficiente y realmente quien tiene que hacer el pago es la persona que se descarga esa librería y que está consumiendo de forma real la AWS.
[No identificado] (01:00:16): Está curioso. Sí, incluso hay o que sepas que Amazon nunca te va a dejar que publiques un token tuyo por ahí. Te llaman al momento en serio, fuera broma. Maravilloso, maravilloso porque tenemos, no son anécdotas mías, por suerte a día de hoy aún no me ha pasado, pero sí conozco compañeros que uy, no configure el gitignore, uy, subamos, git push, uy, que la clave está publicada en GitHub,
[No identificado] (01:00:46): Uy, perdón, eliminemos el cómic, uy, borrémoslos con otro cómic y es como, no, no, pero el histórico está ahí,
[No identificado] (01:00:52): Acuérdate de eliminar también todo. Sí, no, yo tengo dos, tres de esas, de incluso hasta llegar a ignorar el correo en plan de, no, yo sé que esas credenciales a mí me da igual que estén publicadas.
[No identificado] (01:01:03): Dos días más tarde, teléfono de persona inglesa en plan de, mira, que sepas que tienes que modificar esto ya. En serio, o sea, literalmente se llamaron para decir, madre mía. Literalmente dos días después de recibir el correo y tal, directamente me llamaron en plan de, mira, que no, que lo borres, que lo borres, es que si no, no te voy a dejar en paz. Y yo, vale, vale, lo hago hoy, tranquilo.
[No identificado] (01:01:29): Ostras. Bueno, ya no. A fin de cuenta, ya no es tanto borrarlo, sino resetearlo, porque tú dices, bueno, lo borro del repositorio, pero tú no sabes dónde se, qué bot te puede haber cacheado eso, sino, bórralo, pero cámbialo. Sí, sí, sí, no, no, ellos se referían a bórralo de la consola tuya, o sea, desactiva ese usuario que tienes ahí, aunque solo sea, ya te digo, las credenciales eran solo para el transcribe, e incluso solo para usar ese servicio. ¿Qué pasa? Que imagínate que el día de mañana se descubre, por casualidad de la vida, que ese permiso que tenía solo para el transcribe resulta que no,
[No identificado] (01:02:07): Que a través de X motivo de la vida consiguen tener acceso a otra cosa. Ya es un riesgo para ellos, en parte, entonces,
[No identificado] (01:02:15): Están bastante atentos, podemos decir que están bastante atentos. Pues, la verdad es que es precisamente eso lo que decimos, ¿no? Que se agradece un montón el soporte que te dan y que puedas externalizar esos servicios que te den la confianza de que no lo estás, o sea, tiramos un poco al suelo ese dicho de si quieres hacer las cosas bien, hazlas tú mismo, oye, igual no hace falta. En este caso, no, hubiéRamos publicado, imagínate, un token nuestro de la API, yo no me hubiera acoscado nunca, o sea, yo no me hubiera enterado que a lo mejor había subido eso por accidente,
[No identificado] (01:02:46): Y a lo mejor de repente estoy pasando una clave SSH, ¿sabes? El token de una clave SSH o la firma que les permite hacer peticiones ya ni siquiera a nivel de hacia mi API, sino
[No identificado] (01:02:59): Suplantar mi identidad. Claro. Eso es un marrón chungo, ¿eh? Sí, sí, sí, para no dormir por las noches, ya te digo, no que te llamen a las 2 de la mañana, sino que de verdad que hice, tengo todo en riesgo. Me llamaron en el momento de la comida, fue muy divertido. Tienes una suerte durmiendo, comiendo, pues nada, vamos a dejar de evitar, vamos a evitar ese tipo de cosas, no… Es lo que tiene liar la parda, ¿sabes? Hay un dicho por ahí que siempre me dijeron y es no la caga y que no toca, ¿no? A ver, pero es como se aprende también,
[No identificado] (01:03:32): ¿verdad que esas cosas ya no las… No te vuelven a pasar nunca? Jamás y nunca, jamás y nunca, es un fichero separado para el que te ignore, punto. Exacto, exacto. Y además… Después me volví a pasar otras dos veces, pero… Bueno, pero… Porque hacía tiempo que no trabajaba.
[No identificado] (01:03:49): No, son cosas graciosas, son cosas muy graciosas que… Es eso, se aprende tocando, se aprende tocando. Te quedas con las anécdotas, que es lo importante.
[No identificado] (01:04:00): Al igual que la de hacer un rm-rf punto barra y olvidarte del punto, esa fue mitiquísima. Esa es maravillosa, de hecho, siempre que comparto el code with me lo digo, por favor, que nadie haga un rm-rf, que… No quiero yo tener que estar aquí ahora… Tienes la ventaja de que estás en Windows. No, pero con el subsistema. Ah, pero realmente tiene acceso a toda la parte de Windows y tal, pues eso está mal hecho, ¿eh? No, no, no, no, no. Bueno, no lo sé, tengo que probarlo, ahora lo pruebo y si se cortará la grabación, pues ya sabes por lo que… Ya sabemos, ¿no?
[No identificado] (01:04:37): No lo he probado, de hecho, me imagino que no, o sea, es como todo ahí, si no haces un sudo,
[No identificado] (01:04:45): Pues obviamente no te va a dejar, te va a decir, igual estás intentando borrar cosas que no aplica. El problema es que yo tenía el usuario root. Sí, sí, suele pasar que somos un poco kamikaze y hacemos sudo su. Ah, ya está, se acabó. Es que estábamos preparando la máquina. Ya. ¿Qué es lo que te digo? Que estas cosas no pasan con serverless. Yo no tengo por qué tocar la máquina. Eso no hubiera pasado con serverless. Y si no sabes a quién apuntar, a WBS, mira lo que hicieron.
[No identificado] (01:05:18): O sea, está bien, está bien. Qué bueno. Mira, te iba a preguntar, hemos hablado mucho de AWS, de temas de ¿recomendarías algún canal, algún libro? ¿Cómo puede alguien empezar en este mundo? Aparte de el propio Kickstarter que ya te dan los proveedores en concreto, que suele ser bastante guiadito. Hay una persona que yo sigo en YouTube, ¿vale? Y cuando incluso está, si no me equivoco, es AWS Hero. No sé si de serverless concretamente, creo que sí. ¿Vale? Para el que no conozca qué es esto de AWS Serverless Hero. AWS tiene un programa que es el Hero Program
[No identificado] (01:06:02): Que destaca a aquellas personas, ¿no? Y es como una especie de medallita, como quien dice,
[No identificado] (01:06:08): Sobre la labor, sobre en cuanto a comunicación y a difusión sobre contenido relacionado con sus servicios, ¿no? Hacia la comunidad. Entonces, siempre orientado en cuanto a temas de comunidad. Y esta persona concretamente, pues tiene su propio canal de YouTube que es Fubar, ¿vale? Es una mujer que si no me equivoco es de Latinoamérica, creo, pero ahora mismo estaba viviendo para Sueza, no haría, ponga aquí país nórdico, trabajando para AWS. Cada vez que veo un video de ella me encanta por lo fácil que explica las cosas y es maravilloso porque encima el acento es más del nuestro, entonces es como más fácil de entender.
[No identificado] (01:06:46): ¿Te refieres a Canarias? Sí, en cuanto al tema del acento en inglés no es tan marcado, ¿no? Entonces, si te cuesta un poco el inglés y te gusta la parte de serverless y creo que también tiene algún que otro contenido en español, creo que puede ser, ¿vale? He tenido la suerte de asistir a alguna que otra charla online de ella también y lo mismo, maravilloso. La forma que tiene de explicar es divina, o sea, te lo masca todo, te lo deja todo facilísimo. Qué bueno. Entonces, esa persona, no me sé el nombre de la mujer, solo sé que el canal se llama Fuguar. Bueno,
[No identificado] (01:07:20): No pasa nada, lo buscaremos, lo pondremos en los enlaces
[No identificado] (01:07:25): A pie del episodio, bien en Spotify, Amazon Music, iVox, YouTube, cualquier plataforma, los enlaces van a estar a pie del episodio, ¿vale?
[No identificado] (01:07:37): Bueno, no te creas que te vas a librar, Jorge, muchísimas gracias, pero, pero, todos sabemos que persona que pasa por aquí, pues, se tiene que ir con alguna preguntita, sorpresa, maravillosa.
[No identificado] (01:07:53): Entonces, hay dos preguntas preparadas para ti, por el público, ¿vale? Que me gustaría que te mojases y contestases, si no, pues lo podemos evitar, ¿vale? Pero venga, vamos a intentar. Y cómo no, después tienes el comodín de poder hacerme tú a mí alguna pregunta, una, pero no alguna, una, ¿vale?
[No identificado] (01:08:14): ¿Estás preparado? Vengo. ¿Tienes el agua cerca? Ya, ya, bebí traigo, por si acaso. Venga.
[No identificado] (01:08:24): Pues, la primera pregunta es, ¿a qué temperatura crees que tienen que estar los servidores de Amazon
[No identificado] (01:08:32): De forma que nos permita tomarnos una buena cerveza?
[No identificado] (01:08:37): Pero, en plan, dentro, en plan poniendo la cerveza encima. Sí, no, o sea, tú vas a los servidores de Amazon, a su central de servidores y dices, buf, esto tiene que estar a X temperatura y dejar la cervecita ahí un momento para poder tomármela. O sea, ¿cuánto tiempo le darías ahí a la cerveza? ¿Crees que eso está echando fuego? ¿Crees que está a menos 15 grados? Y es en plan de, ya está, ya me la cojo y me la llevo porque… Seguro que bajo cero ni loco, o sea, ni loco. Tuve la suerte, estando en la universidad, tuvimos que preparar un proyectito, tuve la suerte
[No identificado] (01:09:16): De entrar en un CPD aquí en Canarias, ¿vale? En Tenerife y pude entrar en el superordenador más tocho de España en el segundo más tocho y hacía fresquito, ¿eh? O sea, estaba bastante guay, súper agradable la temperatura. Sí. Yo a lo mejor lo dejaría 24 horas, pero porque yo soy de cerveza fría, eso de que esté calentita no mola. Vale, entonces yo diría que si está entre los 10 11 grados, yo lo dejaría y un día de tranquileo, ya al día siguiente vengo, la recojo y me la veo con todo el gusto del mundo. Bueno, bueno, está bien, está bien. Entonces se admite. Vale.
[No identificado] (01:09:54): De hecho, en cuanto a la anécdota que acabas de contar del supercomputador,
[No identificado] (01:10:00): Nosotros también, o sea, concertamos una visita guiada en su momento en plan colegueo, cuando eso ya habíamos terminado de estudiar y dijimos unos colegados vamos a intentar concertarlo y me acuerdo que además era en el sur, o sea, en el sur de la isla además, pantalón corto, camiseta, tal, un calor horrible fuera y entramos y era como por lo que teníamos que habernos traído una chaquetita aquí dentro porque, bueno. Sí, sí, sí. Me pasó exactamente lo mismo. Yo creo que a todos siempre nos pasa, siempre nos pasa. Deberían de avisarlo en plan de recuerde traer su rebequita.
[No identificado] (01:10:42): Yo no sé tú, pero yo tuve que hablar con el director
[No identificado] (01:10:46): Del centro ese y no me di cuenta hasta pasados dos, tres correos en plan de claro, tu estudiante y dices, hostia, que me está hablando el director de la empresa que lleva todo esto y en plan de disculpa,
[No identificado] (01:10:59): Hostia puta, que me está hablando el colega a mí, que me está respondiendo a mí, un plebeio, un universitario, ¿sabes? Que mira, fue bastante acogida, nos acogió muy bien. Yo tuve la suerte de que no lo organicé yo, a mí, por decirlo así, me lo organizaron. Entonces, a mí me dijeron, vienes yo, por supuesto, contigo hasta el fin del mundo y me llevaron. De hecho, de más, me llevaron, no llevé yo el coche ni nada. Y me traje, espérate, estoy acordando de más, me llevaron, me trajeron y ese mismo día por la tarde me llamaron y me dijeron, mira, que si quieres empezar
[No identificado] (01:11:37): Mañana a trabajar. Es verdad, es verdad, ese día me llevó para mi primer trabajo. Sí, sí. Completo entonces, ¿no? Sí, sí, sí, sí. A mí me tocó organizarlo, me tocó llevar coche y
[No identificado] (01:11:54): Toda la pareja en la ley y al año siguiente, sí, es verdad que justo volví a empezar a trabajar en el mismo recinto. Sí, sí, Qué bueno. Pues mira, segunda pregunta que no te salva, ¿vale? Bueno, yo sé, ay, casi, pero esta te va a gustar, esta te va a gustar, igual que sé que te gustan las bandas sonoras, ¿vale? Entonces, dime, tres bandas sonoras para las siguientes situaciones. ¿Te ves capacitado? Venga, vale, vale, vale, además, yo sé que tú eres el típico que cuando pasa una situación tienes la musiquita preparada para la situación, entonces creo que lo vas a tener. Ahora ya no,
[No identificado] (01:12:32): Pero sí, lo puedo tener en la cabeza, depende de lo que sea. Lo vas a tener súper fácil, yo creo que la gente tampoco se lo… O sea, no, no, la gente no es consciente del conocimiento que tienes tú sobre la banda sonora, oh, cuidado, vale, entonces, la primera es una banda sonora para cuando le haces una entrega a un cliente.
[No identificado] (01:12:56): Depende de cómo salga la entrega. Ah, ah.
[No identificado] (01:13:00): Si la entrega en el momento tenso pondría la última que han puesto de la última película de Star Wars, la del despertar de la fuerza, no, el despertar es la primera de la última trilogía. El ascenso de Skywalker puede ser la última de todas. No, esa es la segunda. No, no, es la última. La última, vale, pues del ascenso de Skywalker… Espérate, me acabas de dejar loco. Bueno, independientemente, novena película de Star Wars, por orden cronológico si seguimos toda la línea de tiempo solo de las tres trilogías, que han salido, como tal, obviando
[No identificado] (01:13:40): Historias secundarias, ¿no? Pues la canción que pusieron para el trailer, que era así como súper mega épica, ¿no? Y dependiendo de cómo terminase la entrega, pondría la de… Si sale como… Si sale mal, pondría la lista de Schindler, o sea, clarísimo. Eso es… La lista de Schindler es como la cosa más triste que hay de las bandas sonoras. Madre mía. Y si sale bien,
[No identificado] (01:14:04): Si sale bien, pues esa es la historia más complicada, ¿no? Bueno, podríamos tirar de recursos Star Wars otra vez y pondría la del final de la primera película de la amenaza fantasma. Vale. Esa es la última, la de cuando está… Viene el pueblo… La entrega del premio, como quien dice en Nahu. Vale, vale, te lo compro. Vale, esa es la primera situación, quedan dos, ¿eh? Y has gastado los recursos de Star Wars, o sea, lo has fusilado todo. Bueno, hay muchos recursos en Star Wars, tenemos que decir esto de Anakin… Venga, tira, tira, tira. Venga, vale, vale, vale. Bueno, pues con esta entonces me imagino
[No identificado] (01:14:46): Que igual pones otra de Star Wars. Mientras los test ejecutan… Mientras los test ejecutan… La canciosita de Gladiator cuando está paseando la manita por el trigo, por los campos de trigo. Es como muy relajante, ¿sabes? Es medio tenso al mismo tiempo. Hasta que ves el rojo, ¿no? Cuando ves el rojo… Exacto. Cuando ves el rojo ya te tienes que plantear otras cosas, ¿no?
[No identificado] (01:15:12): El rojo… ¿Qué podríamos poner cuando ves el rojo? No, no, no, no, no. El momento… No, contra, ya que estamos con un detalle. El momento rojo pondría la de… ¿Cómo se llama? La película esta de… La típica forma, ¿eh?
[No identificado] (01:15:31): Ahora mismo no me acuerdo. ¿Scarim Movie? No. No. Podría darse que en el Scarim Movie haya parodia de eso, pero… Puede ser.
[No identificado] (01:15:43): No sé, que le sacaron película hace poco al… Bueno, poco, hace unos años al colega. Que el tío era como un… Que es una escena de un cuchillo, estaba la chica en el… Sí, en el baño encerrada. Efectivamente. Esa. Creo que es Ian Carrier del cuchillo, ¿no? Si no me equivoco. Puede ser, puede ser, puede ser, puede ser. Pues ese momento tenso de… Esa sería los tex en rojo. Y los tex en verde pues tiraría de meme. Tiraría de meme y típico momento Oscar de todo el mundo levantándose, aplaudiendo. Tal cual. Maravilloso. O sea, ya ahí no hace falta ni banda sonora. Vale, vale, vale.
[No identificado] (01:16:19): Es que a mí me sacas de Marvel y complicado lo digo. Pero venga, lo podemos intentar. Bueno, podríamos tirar, si tiramos tex en Marvel,
[No identificado] (01:16:28): El…
[No identificado] (01:16:31): Mentira, no, si son… No sería de Marvel.
[No identificado] (01:16:35): Uy. Uy. No sería de Marvel. Mira, a ver, no me voy a… Iba a poner la de Wonder Woman. La banda sonora de Wonder Woman.
[No identificado] (01:16:43): A ver, te lo compro porque es buena peli, pero no me vayas a decir Wonder Woman en Marvel porque me doy un impacto. O sea, no pudié con episodio. Cortaría aquí tal cual y yo no, por favor. O sea, este episodio no ha ocurrido en la vida. Por eso te dije que no sería de Marvel. No sería de Marvel. Vale, vale, vale. Rectifique. Venga, pues vamos a por la última. Esta es la más clásica. O sea, esta no va a haber duda. Mientras se instalan los paquetes de NPM.
[No identificado] (01:17:15): Chos, pues ahí casi que puede ser una suite de unas cuantas, ¿sabes?
[No identificado] (01:17:21): Yo te diría la de Mercadona. En plan, Mercadona. No, tío. No, no, no. No me destroces el momento. Vale. Interestelar. Interestelar. Interestelar que tiene alguna que otra canción que son más de cinco minutos. Puede colar fácil, ¿sabes? Porque con una sola banda sonora no te da, ¿no? No, no te va a dar. Vaya. A ver, puedes coger momentos claves de una, ¿no? Y hacer una suite completa, ¿no? Ahí sí quedaría de lujo.
[No identificado] (01:17:50): Y si no, pues podemos seguir tirando de Memi y la de… Tanananan
[No identificado] (01:17:57): Esa no falla porque además la puedes poner en book y no acabas. Te vi rápido, te vi rápido. Exacto, exacto, exacto. Eso es porque sabes que tengo la aplicación de los botones. Efectivamente, efectivamente. Bueno, y porque hemos tenido conversaciones interesantes de bandas sonoras y de Marvel, ¿cómo no? ¿Cómo no? Sí, tío, no, yo… Yo soy un friki de las bandas sonoras.
[No identificado] (01:18:24): Bueno, pues perfecto. Pues, Jorge, ha sido un auténtico placer tenerte por aquí.
[No identificado] (01:18:32): Te lo agradezco enormemente. Creo que le has podido resolver un montonazo de dudas a los oyentes, a la gente que nos esté viendo también en YouTube. Y cualquier cosa, cualquier duda, cualquier comentario, abajo en la cajita de comentarios que te haremos llegar las preguntas. Si no, tus redes sociales también estarán abajo para que contacten contigo directamente y te lancen cualquier tipo de… Te pongan en cualquier tipo de aprieto. Ya después verás tú cómo lo solucionas. Yo encantado de la vida. Yo encantado de la vida. Todas esas cosas se aprenden. Perfecto. Pues, ¿qué te digo, Jorge? Muchísimas gracias por estar aquí. Te lo agradezco enormemente.
[No identificado] (01:19:11): Espero que repitas. Espero que te lleves un buen momento y que repitas. Y por invitarme, hombre. Que, joder, es todo un honor que alguien te tengan tan buena estima como para invitarte a hablar de algo.
[No identificado] (01:19:27): Nunca ha sido mi objetivo,
[No identificado] (01:19:30): Pero es como esa satisfacción de, contra, pues, algo tendré que estar haciendo bien como para estar aquí, ¿no? Como quien dice. Quieras o no, es ese pedacito de corazón que te lleva. Te lo has ganado pulso. Eres todo un profesional y te lo has currado un montón y me has enseñado un montón de cosas también. Así que, ¿cómo no? Y vas a estar aquí. Sobre todo en algo que controlas tanto y con lo que le has invertido tantas horas y sobre lo que sigues investigando e intentas promulgar. Así que, es un hecho. Jorge, de nuevo, muchísimas gracias. Gente, gracias por vernos, gracias por estar aquí.
[No identificado] (01:20:10): Nos vemos en el siguiente episodio. No voy a hacer spoiler, no voy a hacer spoiler. Jorge habló antes del inglés y demás, por ahí, muy por encima. Igual tiene algo que ver, igual no. Ya veremos cómo se va dando todo. Así que, muchísimas gracias. Nos vemos en el próximo episodio. Adiós.
[No identificado] (01:20:42): Chau.
[No identificado] (01:20:44): Chau.
[No identificado] (01:20:48): Chau.
[No identificado] (01:20:52): Chau.
[No identificado] (01:20:55): Chau. Chau. Chau.