Node.js: Más hilos de los que piensas

Entonces, dado que hemos estado hablando mucho sobre front-ends hoy, es hora de hacerles sufrir con un poco de back-ends. Mientras puedas correr ahora, si no lo haces, de lo contrario, buena suerte. Así que hay mucho en lo desconocido. Ustedes son principalmente, supongo, ingenieros de front-end, que trabajan con Node en muchos sistemas hoy en día, lo que significa que usan Node, pero en realidad no usan Node, lo cual es algo asombroso para mí. Y veamos qué significa para ustedes.

La introducción original está bastante bien, así que voy a omitir esta. Solo quiero que sepan que vengo de la región más pequeña y menos conocida de Italia, y todos ustedes deberían visitarla porque es simplemente increíble. ¿OK? OK. Así que Node.js ya no es single-threaded. ¿Todavía creen que en realidad es single-threaded? Levanten la mano si piensan que sí. OK, solo váyanse. No ha sido single-threaded desde hace mucho tiempo. Así que Anna Emingsen presentó los Node worker threads en 2018. Y ha sido estable desde 2018, junio, en Node 10. Ahora estamos en 25 con el módulo de worker threads.

Así que amigos, por favor. La cuestión es que este enfoque tiene una gran ventaja porque cada hilo tiene un bucle de eventos independiente. Así que pueden hacer cosas totalmente independientes. Pero a diferencia de otros sistemas, realmente no tienen que preocuparse, a menos que realmente tengan que hacerlo, por la sincronización, el acceso compartido a cosas, y demás. Así que es muy, muy, muy bueno. Y también es muy, muy bueno para descargar parte de la carga intensiva de CPU fuera del hilo principal. Como saben, Node está destinado a ser intensivo en IO, no intensivo en CPU. Así que si hacen cosas intensivas en CPU, están matando su hilo principal, que a menudo es su único hilo, así que están acabados. Ven el problema, ¿verdad?

¿Por qué te importa? Bueno, la cuestión es, ¿cómo escalas Node.js en producción? ¿Quién está realmente sirviendo tu brillante aplicación SSR? Y no me importa el framework. SSR. Hablemos solo de SSR. ¿Quién está sirviendo tu SSR? Node. ¿Cómo lo sirves en producción? ¿Cómo lo escalas en producción? Bien. Bien. Ahora quiero hablar sobre una historia familiar que todos hemos estado viendo durante los últimos 20 años, 30 años. Quiero decir, al final de la diapositiva, les preguntaré, ¿quién está familiarizado con esto? Tenemos una situación. Tienes un pico de tráfico. Tienes varios pods en tu clúster de Kubernetes, ¿verdad? Ahora el problema es que si vas a tu panel de Grafana, verás que el pod del uno al 10 están como al 30% y otros dos pods están al 100%. Así que las solicitudes están realmente bloqueadas. Tu tasa de error está escalando al 8%. Entonces, ¿qué quieres hacer usualmente? Lo único que realmente puedes hacer es sobreaprovisionar tu clúster. Así que agregas más recursos. Agregas más recursos para que puedas tomar nuevas solicitudes. En algún momento, esos pods también se acumulan y vuelves al problema original. Mientras tanto, estarás desperdiciando mucho dinero en eso. Ahora, si piensas que esto se trata solo de aprovisionamiento, no se trata solo de aprovisionamiento. Porque si tienes una coordinación entre APIs o micro frontends o lo que sea que quieras, si tienes un retraso de 185 milisegundos en una API, en otra API, en otra API, es medio segundo de retraso para el usuario. Ya perdiste un usuario. Hay deserción de clientes. Ahora, levanta la mano si estás familiarizado con esta situación, por favor. El resto de ustedes son solo mentirosos para que conste, porque sabemos eso. Sabemos que están familiarizados con esto. Sabemos. Entonces, ¿cómo manejamos la escalabilidad dentro del nodo?

Desde Node 0.6, que es de 2011, y tal vez algunos de ustedes ni siquiera habían nacido entonces, se agregó el módulo cluster. El módulo cluster básicamente es una técnica muy inteligente que básicamente dice, tengo un proceso maestro que simplemente tomará conexiones y básicamente las enrutará a través de trabajadores, usando sockets Unix. Es muy, muy inteligente. Funcionó durante varios años. Es la base de PM2, que es un orquestador familiar para este tipo de aplicaciones de múltiples instancias.

Es la base de PM2, que es un orquestador familiar para este tipo de aplicaciones de múltiples instancias. ¿Alguien está usando PM2 aquí? Por favor, levante la mano. Bien. Entonces sabes cómo funciona. El problema es que esta IPC, es decir, Inter-Process Communication, a través de un socket web Unix, está añadiendo a cada una de tus solicitudes un 30% de sobrecarga en el tiempo de respuesta. Estás desperdiciando un 30% de tu lógica de aplicación, lógica de negocio, y demás. Así que esa es la idea. Acabo de hablar de esto, pero esa es la representación gráfica.

Así que básicamente, el nodo maestro hablará básicamente con el sistema operativo para manejar la capa de red, aceptar conexiones, enrutarlas a uno de los posibles trabajadores, y luego eventualmente enviar la respuesta de vuelta. Pero ahí está la sobrecarga. Luego hay otro problema, que es bastante peculiar de Node.js. Cuando el sistema está sobrecargado, idealmente, en lugar de aceptar nuevas conexiones y empeorar la situación, tal vez quieras devolver al cliente una respuesta 503. El problema es que el servidor puede rechazar esto muy temprano y decir, ¿sabes qué? Estoy ocupado. Vuelve más tarde. Sé que no es agradable, pero es mejor que dejarte esperar 20 segundos.

Así que inmediatamente rechazan con 503. El problema es que esto no es posible en Node, porque la idea es que para rechazar una solicitud, tienes que rechazarla cuando realmente la procesas. Y para procesarla, tienes que aceptarla en el bucle de eventos. Para cuando llegas a procesar esa solicitud, el cliente ya ha esperado durante mucho tiempo. Y además, lo que lo hace aún peor, esta solicitud todavía está en el bucle de eventos. Así que todas las solicitudes asociadas, sockets de red, datos ya cargados, y demás, todavía están en tu RAM sin ninguna razón. Quiero decir, estás llenando tu RAM con solicitudes que ni siquiera estás procesando. Quiero decir, estamos entrando en escenarios muy horribles, ¿verdad? Y dado que acabamos de hablar de Next.js en la charla anterior con Wyatt, Next.js, pero incluso otros frameworks, solo estoy hablando de Next porque es nuestro estudio de caso hoy, pero esto es generalmente cierto para todos los demás frameworks como ese, TimeStack, Nuxt, lo que sea que quieras pensar.

Este tipo de framework para SSR lo empeora aún más, porque para decidir qué hacer con esa solicitud y rechazarla, primero tienen que cargar la solicitud, precargar algunos datos, y luego debe ocurrir el enrutamiento dinámico, y luego en algún momento, dicen, está bien, sabes qué, no puedo atender esta solicitud. Hay muchos recursos que has estado desperdiciando tanto en la RAM como en la CPU para procesar algo que simplemente descartas de inmediato. La obtención de datos, quiero decir, hay muchas cosas que suceden antes de que incluso llegues a la toma de decisiones y digas, sabes qué, no puedo atender esta solicitud en este momento. Así que ese no es un enfoque viable de rechazo temprano en Node en absoluto.

Y por supuesto, como ya dije antes, la latencia compone este efecto a lo largo de los microservicios o micro-frontends, porque básicamente tienes que sumar todos los retrasos. Y con los pods de CPU único o PM2, si algunas solicitudes están desequilibradas, este efecto se compone mucho. Ese es el mayor problema que estábamos viendo en todos nuestros clientes a lo largo de todos los posibles escenarios, no solo en frontend. Ese es el problema.

Por supuesto, ya que estoy aquí, tengo algo mejor que decirte. De hecho, resolvimos este problema. Lo más asombroso de cómo resolvimos este problema fue en realidad que nuestra base técnica es una API que ha existido durante 12 años en un solo sistema operativo y porque te diré en un minuto por qué y en realidad nadie la está usando, lo cual es asombroso. Es algo que en realidad no y no puedo explicar. Base técnica. TCP SO reuse port.

Por curiosidad, levante la mano si realmente sabe de qué estoy hablando. ¿Alguien aquí? Ni uno solo. Genial. Bien. Así que, esa es la idea. Usualmente en Unix o en realidad en Windows o incluso en Mac, si intentas escuchar dos veces en la misma máquina en el mismo puerto, obtienes un error que es E, add in use, ¿verdad? Porque, por supuesto, el puerto está ocupado. Con este flag, si básicamente quieres crear tu socket, configuras este flag a nivel de C, en realidad ya no obtienes ese error. Puedes tener múltiples procesos escuchando en el mismo puerto.

¿Cómo funciona? El kernel básicamente cuando llega una nueva solicitud de socket, una nueva conexión llega a tu servidor, básicamente creará una IP de origen, puerto de origen, IP de destino y el puerto de destino si sabes de qué estoy hablando son los cuadrantes del paquete TCP básicamente, calculará un hash y asignará este hash a uno de los workers, uno de los procesos que escucha. A partir de ese momento, cada vez que una nueva conexión venga del mismo socket, irá al mismo worker. Así que, básicamente el kernel hará el round robin o cualquier otra política de algoritmo, en realidad hay algunos algoritmos más complejos para ti, se comportará como un router y básicamente permitirá que más workers escuchen en el mismo puerto TCP.

Hay afinidad de conexión. Hay distribución. No hay necesidad de ninguna coordinación porque ni siquiera ves esta cosa. Esto se hace totalmente a nivel del kernel y un flag en Node habilita esto. Cuando creas un net server create, dirías reuse port true y listo. Eso cambia la vida en esto. Te mostraré por qué esto es muy, muy revolucionario. Lo curioso es que esto ha estado disponible desde el kernel 3.9 en Linux y digo un sistema operativo y medio porque también es compatible en Mac, así que técnicamente puedes usar el flag pero el round robin no funciona.

Así que solo uno de tus workers eventualmente recibirá el tráfico por alguna razón. Siempre es el mismo porque el enrutamiento está totalmente roto, pero al menos puedes probar si tienes un solo worker con la misma lógica y eventualmente desplegar en Linux sin tener que cambiar las flags en tu código. Mejor que nada. Adivina qué sistema operativo falta en la lista de sistemas operativos soportados y seguimos adelante.

Para aprovechar S o reuse port creamos VAT. VAT es el servidor de aplicaciones Node. Lo digo de una manera muy audaz porque simplemente rockeamos Foxhike. No quiero presumir, pero resolvemos muchos problemas y creamos una arquitectura única que aprovecha todas las pruebas inteligentes que puedes hacer en Node. Por ejemplo, este diagrama que te estoy mostrando aquí es básicamente la arquitectura básica de VAT. Déjame también quitarme del retrato. La idea es que cuando una solicitud llega a VAT, puedes eventualmente y opcionalmente usar un gateway que es el punto de entrada, el gateway platformatic. El gateway platformatic enruta tu solicitud de acuerdo básicamente con la URL de la solicitud a uno de los posibles servicios dentro.

Nota que ni el servicio Fastify ni el servicio Next.js están realmente expuestos al mundo exterior. Puedes tener servicios que son solo internos para servir a otros servicios y así sucesivamente. Lo bueno es que cuando digo enviar solicitud a API.plt.local o frontend.plt.local no estoy usando TCP. Estoy usando HTTP pero sin la capa de red. Estamos usando comunicación entre hilos que es mucho más rápida que cualquier red posible, incluyendo la red en localhost. Así que todo lo interno sucede a través de hilos de trabajo. Además, VAT está listo para producción. Hemos estado probando en varios sistemas de producción y tenemos el monitoreo, registro, trazado y verificaciones de salud integrados. ¿Por qué es esto importante? Porque en VAT, el único requisito técnico que te damos es que nunca ejecutes en el hilo principal. ¿Por qué es eso? Porque reservamos el hilo principal para hacer la coordinación y verificación de salud de otros hilos. Ahora podrías pensar, ¿por qué es esto importante, Paolo? Bueno, piensa en esto, en Node, cualquier sistema de verificación de salud que insertes en tu servicio en tu hilo principal, tengo una pregunta para ti. Si el bucle de eventos está totalmente lleno y no puede procesar ningún pequeño dato, ¿cuándo se está ejecutando realmente la verificación de salud para notificar a alguien que realmente estás fallando? Está totalmente atascado. Así que tienes que esperar eventualmente a que ese hilo se desbloquee ligeramente tal vez en un minuto a partir de ahora y notificar a alguien, digamos Kubernetes, que realmente estás atascado. No funcionará. En cambio, con VAT, el hilo principal que no ejecuta ningún servicio es solo para el monitoreo de otros hilos y podemos decir inmediatamente, este hilo está atascado, reinícialo. Lo que nos lleva a otra buena característica de VAT. Así que esta es la arquitectura de VAT, de la que ya hablé. La cuestión es que dado que usamos SUS reuse port, aceptamos directamente la conexión a nivel del kernel.

Pero eso no es importante ahora. Lo importante aquí es la orquestación de procesos. Si lo que te estaba diciendo, si un hilo está fallando, el hilo principal puede detectarlo y detenerlo inmediatamente y comenzar uno nuevo. Y somos tan flexibles que lo que realmente podemos hacer es iniciar un nuevo hilo cuando el hilo está listo. Así que incluso si tu aplicación tiene un tiempo de inicio largo, no tienes tiempo de inactividad porque esperamos que tu aplicación informe que está lista y luego intercambiamos el hilo en el enrutamiento y no hay tiempo de inactividad para el usuario. Por la misma razón, podemos hacer un apagado elegante.

Y como ya te estaba diciendo, tenemos monitoreo y métricas integradas. La mayor ventaja aquí en comparación con PM2 u otros sistemas es que podemos inmediatamente, en cuestión de un segundo, por ejemplo, la resolución mínima que podemos darte es un segundo, verificar que el bucle ART está bloqueado, si hay un agotamiento de la memoria IP del nodo. Estoy diciendo IP y no RAM porque es una historia totalmente diferente, pero considera que en Kubernetes nunca debes usar el uso de CPU y el uso de RAM para monitorear nodos porque no funcionará. La utilización del bucle de eventos y el uso de IP, eso es lo que estás buscando.

Y podemos instrumentarlo y monitorearlo inmediatamente y automáticamente. Y podemos reemplazar un trabajador fallido en su lugar sin tiempo de inactividad en absoluto. Y digo sin tiempo de inactividad porque sufrí durante muchos días para garantizar que no pierdas ni una sola solicitud. Fue un PR de sufrimiento que envié a Watt para esto, así que sé de lo que estoy hablando. Y dado que estábamos hablando sobre el componente de caché, también implementamos caché HTTP compartida. Y también implementamos, en el caso de Next, caché compartida de componentes de React.

¿Qué significa esto para ti? Si tienes una caché compartida, básicamente puedes tener a todos tus trabajadores dentro del pod compartiendo la misma memoria. Así que básicamente un trabajador renderizará en la página SSR. Cuando llega a otro trabajador, el resultado ya está allí para ser servido al cliente. Así que la respuesta será inmediata aunque vaya a otro trabajador. Y si pones esta caché dentro de Redis, incluso puedes tener esta caché compartida en todos los pods. Así que eso es inmediato. Básicamente nunca implementas la regla DRY, no te repitas, en su máxima expresión. Nunca haces la misma operación dos veces a menos que uses la clave de caché incorrecta. Pero esto es tu culpa, no la mía.

La cuestión es que los tiempos de respuesta son sobresalientes. Ahora, hasta ahora estábamos hablando de localhost, ¿verdad? Pasemos a las instalaciones locales. Ya que ves mi camiseta, ¿verdad? Así que vamos a las instalaciones locales. Hablemos de Kubernetes. ¿Cómo despliegas VAT eficientemente en Kubernetes para obtener el mayor rendimiento posible? Optamos por una arquitectura muy simple, de dos capas. Tenemos servidores Kubernetes, que actuarán como el enrutador de entrada y dirán, recibo una conexión. Déjame ver a qué pod debo enviar esta conexión. Y luego dentro de cada pod, hacemos otro escalado con soporte VAT y SORU. La cuestión es que este enfoque garantiza el mejor aislamiento estadístico posible y distribución de todo tu grupo de solicitudes. Y lo verificamos.

Porque la cuestión es que al final del día, obtienes el procesamiento más independiente de solicitudes dentro del pod y dentro del clúster. Hay la menor variación posible de tiempo de respuesta porque es mucho mejor que el puro round robin porque si un trabajador está bloqueado, otro trabajador tomará el relevo y eso está totalmente bien, porque este kernel se encargará de eso por ti. Y hay una mejor utilización porque un solo pod no será bloqueado por un solo trabajador que se caiga porque son totalmente independientes. Además, dentro de los pods, obtienes otros pequeños beneficios, como tener una sola capa de red. Tienes solo una copia de la aplicación porque Node cargará tu aplicación desde el sistema de archivos una vez y luego eventualmente generará varios trabajadores, porque almacenamos en caché lo que realmente requerimos. Y hay menos paginación del kernel, lo que significa que usas tu RAM físicamente de manera más eficiente.

Ahora, hablemos sobre el rendimiento, porque todo lo que te importa, sobre este tipo murmurando sobre Node es ¿qué tan rápido es esto? Hicimos un benchmark. Desplegamos una aplicación Next en un clúster ETS AWS. La probamos durante dos minutos con una carga sostenida de mil solicitudes por segundo. Había tres nodos en este clúster, y probamos con K6 en otra instancia grande con una ejecución de tasa de llegada constante, y las unidades virtuales fueron preasignadas para garantizar la menor variación posible.

¿Cuáles fueron las configuraciones? Probamos tres casos. En primer lugar, tenemos un clúster de Kubernetes, seis pods, cada pod tiene un CPU completo, así que seis CPUs en total. Luego tenemos PM2, para el cual tenemos tres réplicas con dos CPUs cada una. Una vez más, seis CPUs en total. Y luego tenemos BAT con la misma configuración de PM2, pero usamos dos enfoques diferentes, clúster versus S o reuse port.

¿Cuáles fueron los resultados? Estos fueron los resultados. Así que puedes ver en los gráficos que básicamente sobresalimos en todos los casos posibles. Puedo dejar los gráficos para mí. La idea es que somos 933% más rápidos que PM2. Somos 81% más rápidos que la latencia P95. Somos 92% más rápidos que un solo CPU, y esto es solo la latencia. Luego tenemos la disponibilidad de rendimiento. Primero te damos un 10% más que PM2, pero ofrecemos casi un 100% de tasa de éxito. Con PM2, obtienes una gran cantidad de solicitudes perdidas.

Ahora, ¿por qué es esto posible? El primer problema es que PM2 está perdiendo mucho rendimiento en la configuración maestro-esclavo, socket único, y así sucesivamente. Así que pagas un 30% de sobrecarga incluso cuando no estás cargado. ¿Y por qué el CPU único tiene un rendimiento inferior? Porque está aislado y desequilibrado. El round-robin no es un buen algoritmo, por lo que algunos posts podrían estar al 100% porque están llenos, y se sobrecargan por el enfoque round-robin. Mientras que otros están al 30%, no pueden reequilibrarse, desperdicias dinero. Esa es la idea. Es triste, pero como ya te estoy diciendo, aprovechas la distribución de kernel sin sobrecarga a través del puerto de S4U.

Y así como una mejor multiplexación estadística de tus solicitudes está al 99% de fiabilidad. Si quieres, te daré un segundo para compartir esto, escanear este QR, o puedes encontrar fácilmente en nuestras guías de platformatic. Déjame moverme, lo siento. Si quieres echar un vistazo, o puedes escanear mi camiseta. No estoy seguro si me enviaron aquí porque soy el tipo más grande en platform, la mayor área de superficie para el QR, pero lo acepto, está totalmente bien para mí. Eso es todo. Usualmente termino mis charlas con citas de personas sabias, así que encontré esta, que es increíble en esta industria, que es cuando básicamente pretendemos trabajar, pero en realidad jugamos y aprendemos, y lo sabemos. Así que siempre eres un estudiante, nunca eres un maestro, y básicamente tienes que seguir avanzando.

A esto le añado, avanza sabiamente, no cometas demasiados errores. Dicho esto, he terminado. Muchas gracias, amigos. Me encanta la temática de las preguntas. Digamos anónimo, quienquiera que sea. Tiene un sentido del humor muy único en la forma, especialmente en la forma en que reaccionan a reutilizable. Realmente aprecié cómo dijiste, puedo garantizarte que hay cero tiempo de inactividad debido al sufrimiento que se puso en esa solicitud de extracción. Así que apreciamos el arduo trabajo que has venido y has compartido con nosotros hoy.

Pasemos directamente a las preguntas. Y me encanta esta, la voy a leer tal cual. ¿Cómo es legal SO reuse port? Pensé que enlazar dos veces al mismo puerto era un crimen castigado con un fallo de segmentación. Lo cual tiene todo el sentido. Vivimos ordenando noticias, ¿verdad? La cuestión es que es legal porque es simplemente inteligente. Porque si lo piensas, cuando una solicitud llega al socket, el sistema operativo dirá, OK, este puerto está realmente asignado a un proceso, ¿verdad? Así es como funciona el kernel. Ahora, probablemente el kernel dirá, oh, tengo un conjunto de puertos, ¿por qué no? Esa es una idea muy sabia y en realidad una idea muy antigua que nadie usa. Como múltiples hilos en Node, ¿sabes? Es la misma idea. No, me encanta. Me encanta. Me encanta. Y la siguiente es, ¿funciona también para web sockets? Absolutamente, absolutamente. La cuestión es que no es específico para la web, no es específico para nada. Es solo que una vez que un byte entra en una computadora, el kernel lo envía a algún lugar. El contenido de, y por supuesto lo mismo ocurre para el lado saliente. Y el kernel no tiene idea de lo que está haciendo tu aplicación. Porque no estamos en el nivel cuatro de la pila. Estamos en el nivel tres, o incluso dos. Así que puedes hacer lo que quieras porque es mucho antes de la capa de aplicación. Wow, eso es increíble. Para ser justos, hay un ingeniero de backend a quien voy a enviar esta charla para que maneje esto por mí, para ser honesto. Y tal vez algunas otras personas aquí tengan lo mismo. La siguiente es, sí, usándolo para multi-, lo siento, si SO reuse port permite que múltiples procesos se enlacen al mismo puerto, ¿es esto balanceo de carga o brujería? Brujería. Brujería. Eso es lo que estás preguntando. No estás preguntando. Y luego esta, creo que la cubriste, pero repasémosla de nuevo. ¿Cómo decide el kernel qué proceso obtiene la conexión? ¿Es round robin, basado en hash, o el trabajador que tomó más café hoy? Supongo que el último por lo que sé. Porque la cuestión es que nunca miro en los detalles de la implementación. Lo que realmente sé, pero si estás interesado, contáctame y descubriremos juntos, porque no estoy 100% seguro, es que al principio es un round robin balanceado.

Entonces, no es un round robin puro, sino que considera varias cosas como la CPU y demás del proceso. Después de eso está la afinidad de conexión. Así que, si una nueva conexión proviene de la misma fuente, intentará asignarla al mismo trabajador. Pero en la primera, intenta gestionar la conexión de manera eficiente. No estoy seguro de cómo, porque incluso podría cambiar entre diferentes versiones de Linux y probablemente tener varios algoritmos en los que puedes optar, así que no es una respuesta general. Pero la idea es que el mejor balanceo al principio, en la primera conexión, y luego la afinidad de conexión.

Y recuerda, también, si quieres venir y tener una charla, él estará abajo en la sesión de preguntas y respuestas en persona, así que puedes ir a hacer un seguimiento y tal vez obtener más detalles a tus preguntas. Lo que me encantó, los gráficos de rendimiento que mostraste y lo rápido que es, ¿funciona solo con Kubernetes? No. No, pero funciona con todo. No necesita Kubernetes ni nada por el estilo. Para Kubernetes, tenemos otro producto, que es el producto de código abierto, que es el Intelligent Combine Center, que es un orquestador para Kubernetes, que también es de código abierto, por cierto. Solo estoy hablando de cosas de código abierto, amigos. Pero es solo el servidor de aplicaciones que se puede desplegar en cualquier lugar. Depende de ti. Si, por supuesto, integras con ICC, que desplegamos, probablemente sea la mejor configuración para ti, pero no es un requisito.

Bien. Y el siguiente, mostraste el gráfico que comparaba PM2 versus qué. Esta persona pregunta, ¿hay alguna ventaja en usar qué para ejecutar? Usan PM2 para ejecutar su front end en CI pipelines. ¿Hay alguna ventaja de usar qué, además de solo velocidad? Si entiendo el caso de uso que usas en los CI pipelines, quiero decir, asumo que hablas sobre pruebas en pipelines y demás. Obtienes un mejor rendimiento allí, lo que significa menos duración de pipeline y probablemente menos dinero gastado, supongo.

Bien. El siguiente son opiniones sobre Deno. Entonces, si usas Node, ¿estás hablando de múltiples hilos? Estás pidiendo la opinión de un miembro de Node.tsc sobre Deno. ¿En serio, chicos? ¿En serio? En serio. Vamos, por favor. Sigamos adelante. Sigamos adelante. Sigamos adelante.

Luego una persona preguntó sobre estándar abierto... Lo tenemos. Lo tenemos. Lo tenemos totalmente. En lo que obtienes gratis, métricas de Prometheus e instrumentación de open telemetry para HTTP y lo hacemos muy fácil para agregar tu propia instrumentación. Por ejemplo, en nuestro cliente de Kafka, también tenemos la open telemetry lista para usar y demás. Así que si hay algún caso de uso que hemos estado perdiendo, asegúrate de dejar un issue en GitHub o envíanos un mensaje para que podamos encargarnos de eso. Y alguien más preguntó, este es sobre Redis. ¿Necesitamos usar algo como Redis para que todos los procesos compartan el mismo estado? Absolutamente, sí. Piensa en esto. Ese es un problema que también tienes hoy. Básicamente, tienes tu aplicación, tienes un clúster de Kubernetes.

Básicamente, hoy en día, con NextJS de fábrica, no estoy hablando de ninguna configuración específica, con NextJS, tu aplicación llega a una instancia de NextJS. Lo siento, tu solicitud llega a una instancia de NextJS. Se almacena en caché en esa instancia local. Luego, el usuario actualiza la página y va a otro pod que no tiene la caché. Así que, en primer lugar, estás computando la misma página dos veces. Y también has mencionado que tu computación produce los mismos resultados. De lo contrario, el usuario verá resultados diferentes dependiendo de qué pod está realmente accediendo. Ves el problema, ¿verdad?

Y quiero decir, hay chistes malos en Italia sobre lo que pasó la última vez que metieron la pata con el almacenamiento en caché en un sitio del gobierno. Así que puedes buscarlo y realmente pasó algo malo. Así que realmente quieres hacer esto de la manera correcta. De lo contrario, tienes que hacer una declaración en las noticias diciendo, oh, ¿sabes que cometimos un error? Hemos sido hackeados. Ya sabes. Clásico. Clásico, sí. Así que hablaste de esto específicamente con el hosting de AWS también, pero hay muchos diferentes proveedores de nube. Sí, sí.

Esta persona está preguntando sobre Vercel. ¿Cómo se solucionó esto? No, bueno, tal vez me expliqué mal. No estábamos probando en el hosting de AWS. Solo usamos EKS para la provisión de los recursos. Podría haber sido una prueba en las instalaciones con el mismo resultado. Simplemente resultó ser EKS, pero podría ser en Google. Somos totalmente agnósticos al proveedor. No nos importa. El hosting de Vercel no es un hosting directo de tus recursos, así que no nos integramos con eso porque simplemente no ejecutan ni PM2 ni VAT. Tienen su propia infraestructura. Nuestro caso de uso para VAT es cuando tienes en las instalaciones. Cuando digo en las instalaciones, también me refiero a la nube en las instalaciones, si sabes a lo que me refiero.

Básicamente, cuando gestionas directamente tus servidores o si estás en la nube, lo que significa que estás gestionando dejando que alguien más gestione tus servidores, lo cual es un tema diferente.

La siguiente pregunta, han dicho que la arquitectura de VAT les recuerda al modelo de Elixir o Erlang. ¿Cuál es el escenario de recuperación cuando un hilo de trabajo falla? Lo mismo en Elixir y Erlang. Tomamos prestada la idea, no la idea formal, pero la inspiración para eso vino de Elixir y Erlang. Nadie escribe Erlang, pero solo sabemos cómo están haciendo Elixir. Esa es la misma idea.

Dado que envolvemos toda tu aplicación en un trabajador, puedes aproximadamente, y considera que no escribo Erlang, así que perdóname por cualquier rareza que te esté diciendo ahora mismo. Puedes asumir que un trabajador se convierte en un actor y dejamos que el actor falle como en Erlang. El trabajador puede fallar y lo reemplazamos de inmediato. La cuestión es que, ¿por qué esto es mejor? Porque reiniciar un trabajador es mucho más rápido que reiniciar una aplicación completa porque tienes que cargar el tiempo de ejecución y demás. En cambio, solo reinicias el trabajador. El código binario ya ha sido almacenado en caché. Solo tienes que re-ejecutarlo. Dejamos que el actor falle y seguimos con nuestras vidas.

Esta, tenemos algunas preguntas más divertidas. La primera, ¿todavía se llama escalado horizontal si todos los procesos están literalmente en el mismo lugar? Es una pregunta divertida porque hacemos, quiero decir, déjame elaborar esta. De hecho, hacemos T-scaling. Porque dentro de VAT, lo usamos para llamarlo escalador vertical, el escalado vertical de la aplicación porque puedes, una cosa que olvidé mencionar hoy es que dentro de VAT, puedes también obtener un gran beneficio en rendimiento porque te permitimos, gracias al soporte SORU, tener múltiples instancias de la misma aplicación ejecutándose dentro de VAT.

Puedes tener cinco trabajadores sirviendo next. Si tienes cinco trabajadores sirviendo next, obtienes una mejora de rendimiento lineal. Cinco trabajadores significan 500 de salida más. Ese es nuestro escalado vertical. En Kubernetes, tenemos el escalado horizontal. Así que básicamente, al final del día, estamos haciendo el escalado en forma de T, como el conjunto de habilidades del que estamos hablando hoy en día. Lo encuentro hilarante porque creo que la persona que lo escribió y definitivamente yo cuando lo leí fue una pregunta de broma divertida. De hecho, tuviste una muy buena respuesta técnica.

Sí, absolutamente. Realmente disfruté eso. Realmente disfruté eso. Y la última, todos dicen que definitivamente necesitamos actualizar nuestras aplicaciones Node V6. Creo que deberían. Estás como, en lo que estamos ahora, estamos dependiendo en los 20s. Así que como 14 versiones atrás. Pobre chico. De hecho, también tengo una pregunta, una respuesta para ti. Hay un amigo mío, Marco, que trabaja para Erodev. Ellos gestionan versiones obsoletas. Habla con ellos si no quieres actualizar a V6. Vas a hacer su vida miserable, y te lo agradeceré por eso. Muy bien. Muchas gracias.

Esto es todo el tiempo que tenemos para hoy. ¿Podemos dar un aplauso más, Paolo? Gracias. Gracias.