Me equivoqué con Vercel. Tenemos que hablar de eso de Vercel.
Mira, a mí me parece que es un aprendizaje importante e interesante
porque no pasa nada por equivocarse, lo importante es aprender de los errores.
Y de los errores se aprende.
Así que, el tema es que el otro día hablé de esto, los serverless servers,
que quizás no es el mejor nombre para un servicio,
porque de ahí mi error garrafal pensando en los serverless servers, ¿vale?
Ese es mi problema. El problema es que me equivoqué, me equivoqué.
Y por suerte, alguien de Vercel, Mariano, habló conmigo y me dijo,
oye, que es que te dije en el chat que lo habías explicado así regulinchis y tal,
y a lo mejor no me expliqué bien. Le doy las gracias a Mariano.
Mariano fue la persona que en el chat me intentó corregir y la verdad es que yo le contesté
y le dije, no, no, que es un servidor, que no sé cuánto, que bla, bla, bla, bla.
Y me equivoqué, me equivoqué totalmente. O sea, no era cierto lo que estaba diciendo.
Tenía razón, Mariano. Primero, porque trabaja en Vercel, obviamente.
Y lo segundo, porque me comentó mejor cómo funcionaba esto.
El tema es que es el PM de Compute en Vercel.
Entonces, claro, ahí me comentó mejor la ventaja de los idle times y las desventajas que tiene.
Que claro, entonces ahora entiendo mejor el tema.
¿El problema cuál es?
El problema es eso, perdónanos, Mariano. No, que me perdone a mí, la verdad, porque obviamente me equivoqué.
Y no pasa nada, o sea, prefiero equivocarme y contaros lo mejor, porque si no es un poco mal.
Yo os dije que podía ser más caro.
Me equivocaba porque yo me fié de los comentarios de una persona que en el hilo de Twitter
comentaba que le había salido mucho más caro, ¿vale?
Que es, de hecho, es este de aquí, ¿no?
Lo he probado y he tenido que actualizar para un runtime de funciones mucho más caras
y en 24 horas hemos tenido que pagar mucho lo que usualmente pagaríamos en un mes.
Lo hemos revertido al runtime, al engine anterior, ¿no?
Viendo esto y viendo lo que yo había entendido por eso, pensaba, digo, hostia, claro, es que esto tiene sentido
porque ahora son servidores realmente que tienen tal.
Y no, estaba equivocado totalmente porque realmente no ser como CIO.
¿Cómo que no ser como CIO? No entiendo eso, ¿eh?
El tema es, ¿cómo es el temazo, vale?
No puede salir más caro, no puede salir más caro.
Porque es todo lo contrario, en realidad puede salir más barato porque utilizas los recursos de forma más eficiente, ¿vale?
Entonces, tienes menos gigabytes a la hora por el mismo trabajo, el workload que haría la CPU, ¿no?
Y entonces él me decía que no había habido ningún reporte de ningún cliente todavía
que le había costado más dinero porque lo que pasa es que los tiempos de idle time, o sea, los momentos en los que digamos que tú...
Ah, mira, que no estoy compartiendo la pantalla.
En los momentos en los que tú ves este momento de idle time, que es donde, digamos, que se queda como esperando, ¿no?
No se está utilizando ese tiempo, ¿no?
Entonces, como si tienes mucho tiempo de idle time, al final tienes que pagar en ambas invocaciones.
Si invocas aquí, ¿vale? Pues ahí lo tendrías.
El cambio está ahí, en los idle times.
El tema es que no es que tarde más en levantarse, no es que tenga un servidor...
A ver, servidores siempre hay detrás.
Sino que el tema es que si tienes mucho tiempo de idle time, vas a tener que pagar dos invocaciones
porque lo vas a tener que levantar dos veces, ¿no?
¿Qué es lo que ocurre ahora?
Pues ahora la diferencia es que lo que hace es que, cuando decimos que es concurrente y todo esto,
es que el lugar... Aquí tendríamos la diferencia.
Esto sería el antes, ¿no?
Si tienes el tiempo de idle time, tenías la invocación 1, ¿vale?
Haces la computación, idle time, y termina, y esta es la respuesta.
Y la invocación 2, pues aprovecha aquí, ¿vale?
Idle time y tal.
¿Qué es lo que pasa aquí, ahora, con la concurrencia?
Lo que hace es aprovechar los tiempos en los que se queda como idle.
Es como que se quedaría como esperando.
Que muchas veces... ¿Cómo se queda en idle?
Pues si haces temas asíncronos, por ejemplo, pues ahí se puede quedar en idle.
Y ahí está reaprovechando esos tiempos muertos en los que se queda.
Y entonces lo que hace es que puedes invocar, por ejemplo, dos funciones y aprovechar al máximo ese tiempo.
Y ese es el tema, ¿vale?
O sea, que si tienes mucho tiempo de idle, vas a tener que pagar más, en realidad,
porque tendrías que pagar las dos invocaciones y ahí está.
Ese sería el tema.
O sea, que no se trata de que tengas un servidor ahí que esté corriendo,
sino que si ya tienes una función que está corriendo,
lo que vas a estar haciendo es aprovechar la concurrencia para rellenar estos huecos, ¿vale?
Que ahora mismo, pues no sirven para nada.
Y mientras está como esperando, pues puedas ejecutar otro método, ¿vale?
O sea que, perdón, porque lo expliqué mal totalmente, me equivoqué.
No tengo excusa porque podría decir, no, es que el nombre de serverless servers,
pero en realidad es porque yo, hostia, entendí, sobre todo leyendo el hilo.
Yo creo que mi problema fue que leyendo el hilo, la gente me hizo como entenderlo mal.
Y eso yo creo que fue error mío porque podía haberlo leído aquí,
pero la verdad es que leyéndolo y tal, pensé, digo, ah, pues no, sí, claro, tiene sentido así, ¿no?
Pero no, me equivoqué totalmente.
Dicho esto, claro, sí que es verdad que hay algunos trade-off que tienen sentido.
Por ejemplo, pueden aumentar un poco la latencia,
como lo que estás haciendo aquí, aprovechar los tiempos esos muertos,
al final, al rellenar estos huecos y concatenarlo, puede aumentar la latencia,
pero no el coste.
O sea, sí que puede haber algún tema de cosa mala, ¿ok?
Pero no serían costes, sino que sería más bien la posibilidad de la latencia.
Así que ahí os dejo la explicación, que me equivoqué con Versal y lo dejé.
Y me hubiera gustado explicarlo bien desde el principio.
Ahí os dejo igualmente el artículo, por si lo queréis ver mejor.
Porque yo también entendí, ostras, no entendí para qué son los serverless servers.
A ver, os lo explico más fácil.
Básicamente, los tiempos de idle que pueda tener una función,
que normalmente aquí son tiempos muertos porque la función no está haciendo nada.
Ahora, si activas el modo concurrente, esos huecos los puede rellenar con otra función,
con otra invocación de la función.
Entonces, estos tiempos muertos que normalmente, además, los tienes que pagar,
pues lo que está haciendo es que, en lugar, estos serían dos invocaciones, dos funciones, ¿vale?
Está la función 1, está la función 2.
Y aquí tenemos estos huecos idle y idle.
Lo que está haciendo aquí es rellenar esos huecos y en una sola función puedes invocar las dos, ¿vale?
Y ahí estaría reutilizando la computación que tienes disponible con dos llamadas de dos funciones diferentes.
Esto sería la concurrencia.
Y ahí estarías aprovechando mejor los recursos y ya está.
Ese sería el tema.
En lugar de tener que, como está en idle, pues tener que llamar a dos y tener que pagar dos veces y encima este idle tener que pagarlo,
lo que está haciendo es aprovechar los tiempos muertos para meter ahí, en ese hueco, una función.
Ese sería el tema.
¿No sería más entendible con el nombre concurren serverless?
Puede ser que lo de servers no ayude, puede ser.
Pero aún así, creo que lo de serverless servers no es el mejor nombre porque al final ha hecho muchos chistes,
pero igualmente creo que no es que sea el nombre oficial del producto.
O sea, el nombre al final es in function concurrency, o sea, concurrencia dentro de las funciones y ya está, ¿no?
Midu, Theo hizo un breakdown muy bueno de esto.
A ver, pues le echaré un vistazo y lo miraré.
Claro, yo no me dio tiempo a mirarlo en ese momento y la verdad es que lo entendí mal y lo expliqué mal.
Pero ¿por qué hay tiempos muertos?
Se debería levantar solo cuando se llama.
Claro, pero mira, Wilfredo, tú imagínate que en una API llamas a una base de datos.
Y la base de datos, claro, la base de datos, tú haces la petición a la base de datos,
eso es algo totalmente asíncrono y, por lo tanto, la CPU de ese recurso no se está utilizando
porque estás haciendo una llamada asíncrona a una base de datos.
Entonces, ahí hay un tiempo muerto de esa máquina.
Esa máquina se ha quedado en idel.
En idel significa que no está haciendo nada, que está encendida,
pero no está haciendo nada porque está esperando a que responda a la base de datos.
Y una base de datos, a lo mejor, que puede tardar.
Imagínate que tarda 100 milisegundos, 200 milisegundos.
Pues en lugar de dejar ese tiempo muerto que no haga nada,
lo que va a hacer ahora es aprovechar y decir,
ostras, en este tiempo muerto, si me invoca,
si hay otra función que necesita estos recursos, voy a aprovechar y lo voy a hacer.
¿Cuál es el problema?
Que obviamente no puedes controlar cuándo termina una o cuándo termina otra
y puede aumentar un poco la latencia,
pero estás aprovechando mejor los recursos de computación, ¿sabes?
Porque por cualquier cosa asíncrona que vayas a hacer,
pues ahí lo vas a rellenar, esos huecos, y lo tendríamos.
Serverless, el servidor de otro.
Bueno, eso es el cloud. Serverless es otra cosa.
Serverless, más o menos, sería también como decir,
sin preocuparte de la infraestructura.
Eso sería el tema.
Lo entiendo, pero estaría bueno que hagas un vídeo.
Pues lo intentaré de hacer un vídeo para comentarlo con un ejemplo.
Pero si en un hueco de 100 milisegundos le metes una función que tarda 500 milisegundos,
acabas garantizando la primera.
Ese es el problema de la latencia que decimos, claro.
Ese es el peligro que puede haber.
A ver, Cisney, también es verdad que no sueles tener esos...
O sea, no sueles hacer funciones que tarden 500 milisegundos de computer load,
o sea, de CPU.
Suele ser mala práctica.
O sea, el trabajo síncrono que hace una función suele ser muy pequeñito.
Mapear arrays, a lo mejor transformar un objeto, cosas así, ¿no?
Pero no sueles hacer tanto trabajo.
Suele llamar a una base de datos, escribir en algún sitio,
llamar a otras APIs y cosas así, ¿no?
Entonces, normalmente no sería buena idea porque tendrías problemas en cualquier cosa.
A gran escala debe ahorrar muchísimo.
A gran escala va a ahorrar bastante dinero.
Ahora que lo he entendido mejor, totalmente.
Así que es como sacrificar velocidad que puede impactar al usuario,
pero hacerlo bien implica pagar menos dinero.
A ver, lo de la velocidad es verdad que puede ocurrir,
pero también puede más o menos ser lo mismo, ¿sabes?
O sea, lo mismo o quizás un poquito peor, pero tampoco tan peor.
Es cuestión de ir mirando e ir comparando, ¿eh?
Si tu función no tarda, o sea, si tu función es rápida
y lo que pasa es que hace mucho llamadas a base de datos y tal,
no vas a tener ningún problema, ¿eh?
Así lo vas a tener sin ningún problema.
Y aquí, mira, aquí habla justamente de los trade-offs, ¿no?
Que están limitando el número máximo de invocaciones concurrentes
que se hacen para una sola instancia, que lo irán incrementando,
que claro, hay que tener en cuenta que han visto mejora de rendimiento,
pero que este mecanismo puede incrementar la latencia
de esos trabajos que son puramente de la CPU,
porque es lo que comentábamos.
Pero normalmente las APIs no hacéis trabajo puramente de CPUs, normalmente.
Finalmente, este mecanismo cambia cómo se...
Los procesos de Node.js, cómo administra las invocaciones múltiples concurrentes, ¿no?
Y nada, que a ver, que realmente estos como Node.js
normalmente se ejecuta en producción,
pero que es algo que técnicamente no es compatible hacia atrás.
Esto es interesante, por ejemplo, si tenéis un singleton
o si tenéis una variable que la cambiáis en la API.
Claro, ese estado, tened en cuenta que ahora las dos funciones lo pueden compartir.
Antes, a lo mejor las invocaciones no se reutilizaba el mismo recurso de CPU,
¿vale? Eran dos máquinas distintas y no tenías el problema.
Pero claro, ahora que son in-function concurrency,
que es bastante espectacular, el problema que puede ocurrir
es que puedan compartir algún estado si tenéis un singleton y cosas así.
Solo que lo tengáis en cuenta.
No sería como un socket.
Entiendo la comparación que haces con el socket, primo Fabi,
de dejarlo abierto, pero es una cosa totalmente diferente.
Porque aquí estamos hablando que no tienes por qué ser un socket.
Un socket al final es una conexión que se queda abierta
y está devolviendo datos constantemente.
Y estos son invocaciones totalmente separadas.
Lo que pasa es que está utilizando, digamos, para que lo entiendas,
el mismo ordenador.
Está utilizando el mismo ordenador.
En lugar de decir, voy a crear para cada invocación,
voy a utilizar un ordenador distinto y ya está.
Aquí lo que estamos diciendo, para un poco hiper simplificación,
es voy a utilizar el mismo ordenador y voy a rellenar todos los huecos
en los que está desocupado para que tenga ahí más funciones,
más funciones, más funciones.
Y hasta que eso no pase, que se llena,
no voy a utilizar otro ordenador.
¿Vale? Eso sería un poco.
Es que está intentando utilizar mejor los recursos de la misma máquina.
Eso sería el tema.