Panel Discussion: Node.js en la Nube

Hola a todos. Bienvenidos a nuestra masterclass abierta sobre Node.js en la nube. Estoy muy contento de estar aquí y hoy tenemos un gran grupo de ponentes y expertos. Permítanme pedirles que se presenten y digan de dónde son y qué hacen.

Comencemos con Allie. Hola, soy Allie. Vivo en Chicago en este momento, pero soy un poco nómada digital, así que no me quedo en un solo lugar por mucho tiempo. Soy una defensora senior de desarrolladores en AWS en el equipo de Amplify, así que trabajo principalmente en facilitar la nube un poco más para los desarrolladores de frontend y móviles. Esa es mi especialización, supongo. Genial, gracias.

Aaron, por favor, preséntate. Bueno, buenos días. Soy Aaron Hammer. Estoy basado en Los Galles, California, que está en el Área de la Bahía. Soy el fundador de Sideway, que es un nuevo servicio de streaming donde las historias se presentan dentro de una red social simulada, así que creamos redes sociales de sandbox falsas para crear historias ficticias, y de hecho he pasado los últimos cuatro meses dirigiendo un programa por primera vez en 22 años desde que dejé la escuela de cine. Genial. Ruben, por favor, adelante.

Hola a todos. Así que sí, soy Ruben. Vivo en Brighton, Reino Unido, cerca de Londres, y soy un desarrollador de software en American Express, y principalmente trabajo con el framework Microphone10, que es de código abierto, y compartiré sobre eso más tarde, pero sí, eso soy yo. Genial. Alejandro. Está bien. Hola a todos.

Hola a todos. Bienvenidos a nuestra discusión abierta sobre Node.js en la nube. Estoy muy contento de estar aquí y hoy tenemos un gran grupo de oradores y expertos.

Permítanme pedirles que se presenten y digan de dónde son y qué hacen. Comencemos con Allie. Hola, soy Allie. Vivo en Chicago en este momento, pero soy un poco nómada digital, así que no me quedo en un solo lugar por mucho tiempo. Soy una defensora senior de desarrolladores en AWS en el equipo de Amplify, así que trabajo principalmente en hacer que la nube sea un poco más fácil para los desarrolladores de frontend y móviles. Esa es mi especialización, supongo.

Genial, gracias. Aaron, por favor, preséntate. Bueno, buenos días. Soy Aaron Hammer. Estoy basado en Los Galles, California, que está en el Área de la Bahía. Soy el fundador de Sideway, que es un nuevo servicio de streaming donde las historias se presentan dentro de una red social simulada, así que creamos redes sociales sandbox falsas para crear historias ficticias, y de hecho he pasado los últimos cuatro meses dirigiendo un programa por primera vez en 22 años desde que dejé la escuela de cine.

Genial. Ruben, por favor, adelante. Hola a todos. Así que sí, soy Ruben. Vivo en Brighton, Reino Unido, cerca de Londres, y soy un desarrollador de software en American Express, y trabajo principalmente con el framework Microphone10, que es de código abierto, y compartiré sobre eso más tarde, pero sí, eso soy yo. Genial. Alejandro. Está bien. Hola a todos. Soy Alejandro de Buenos Aires, Argentina. He trabajado principalmente en tecnologías de backend, Node.js. Ayudo con un par de comunidades, tanto locales como algunas internacionales, como NoSchool, y, sí, emocionado de estar aquí. Genial. Y nuestro héroe serverless, Slobodan. Hola.

Soy Alejandro de Buenos Aires, Argentina. He trabajado principalmente en tecnologías de backend, Node.js. Ayudo con un par de comunidades, tanto locales como algunas internacionales, como NoSchool, y, sí, estoy emocionado de estar aquí. Genial. Y nuestro héroe serverless, Slobodan. Hola. Soy Slobodan, y soy cofundador y CTO de Vacation Tracker, un sistema de gestión de seguimiento en vivo. También soy héroe de AWS serverless. Trabajo mucho con serverless y también escribí un libro sobre aplicaciones serverless con Node.js con mi amigo Alexander Simovitch. Genial. Así que empecemos, chicos.

Así que empecemos, chicos. Node.js, como saben, se ha convertido en una opción muy popular en las startups e incluso en las empresas, y especialmente en serverless. Y al construir una nueva aplicación, ¿qué arquitectura les gustaría tener, y cuál es la forma que les gustaría elegir, el enfoque regular con Roads, o la arquitectura serverless, estas funciones? Y si están construyendo una aplicación con las funciones en un entorno serverless, ¿qué nivel de granularidad les gustaría preferir y sugerir a nuestra audiencia? ¿Es una aplicación monolítica, o son servicios, microservicios, o funciones? ¿Y debería comenzar al principio del proyecto desde un monolito y luego profundizar en las funciones? ¿Qué piensan sobre esto?

¿Quién comenzará? ¿Deberíamos empezar con la misma persona? Oh, sí, Slobodan, por favor, porque estoy mirando tu característica. Sí, lo siento. Así que puedo hablar sobre mi perspectiva y lo que estoy haciendo para mi startup, y también mi otra empresa, Cloud Horizon. Básicamente, nuestra startup, Vacation Tracker, ahora es 100% serverless. Está en AWS. Y nuestro enfoque es básicamente comenzar con serverless, porque funciona realmente bien para nosotros. Y luego, si algunas partes no son, si no podemos hacer algo con serverless, si necesitamos hackear algo, entonces simplemente recurrimos a otras cosas como contenedores o tal vez instancias si es necesario. Pero afortunadamente, por ahora, hemos logrado construir todo con serverless sin grandes problemas. Y hasta ahora, funciona realmente bien. Ahora tenemos muchas funciones Lambda en producción. Usamos Monorepo para nuestra aplicación, pero básicamente, tenemos pocos servicios y cada servicio tiene un montón de diferentes funciones Lambda y otros servicios dentro de ese servicio. Por ejemplo, Sistema de Gestión de Leads, luego integración con Slack integración, luego integración con Microsoft Teams, y cosas como estas. Y interactúan entre sí a través de algunas APIs. Y son básicamente una especie de microservicios. Así que para mí, la función Lambda es una pequeña función, pero no veo una función Lambda como una aplicación. Es más como un controlador dentro, digamos, de Happy Framework o Express o algo así. Así que para nosotros, eso funciona realmente bien. Y el costo hasta ahora es realmente bajo. En este momento, nuestros costos de infraestructura son menos del 1% de nuestros ingresos mensuales. Así que sí, eso funciona realmente bien para nosotros. Pero nuevamente, este es un caso de uso diferente. Así que tal vez no será lo mismo para todos.

Genial. Ellie, ¿qué piensas sobre esto? Sí, estaría de acuerdo en que diferentes problemas tienen diferentes soluciones. Y así, dependiendo de su equipo, sus experiencias y lo que necesitan priorizar en su producto, eso es lo que deberían usar. Dicho esto, realmente aprecio el enfoque Serverless porque quita mucho trabajo de los desarrolladores y hace que ese proceso sea mucho menos aterrador. He trabajado para startups la mayor parte de mi carrera y definitivamente he lidiado con mucho tiempo de inactividad y mucho de catástrofes de servidor, y que eso sea gestionado por Serverless, creo que es algo positivo. Así que, esa es la dirección en la que iría, pero hay diferentes soluciones para diferentes problemas.

Genial. Alejandro? ¿Servidor o Serverless, las funciones? Creo que ha habido muchas mejoras en tareas limitadas por CPU que se están moviendo al área de funciones, pero creo que hay mucho margen de mejora allí.

Aún así, para procesos limitados por CPU, todavía creo que es más fácil salir adelante con un servidor con una instancia en funcionamiento que con una función. Y para cosas que tal vez no necesiten ese nivel de rendimiento o granularidad, ya sea que cambies el tamaño de la instancia o la CPU o el número de hilos para eso, yo optaría por funciones para eso. Gracias. Rubén? Sí, volviendo al caso de uso, la primera pregunta que tendría sería la escalabilidad. Tú sabes, si quieres empezar pequeño y luego crecer, entonces serverless es muy útil, porque no tienes que preocuparte por escalar las cosas. No tienes que preocuparte de si vamos a poder manejar la carga desde el principio. Supongo que, aparte de eso, y obviamente, las implicaciones en el pequeño costo, porque solo estás pagando por lo que estás usando, eso es muy atractivo para las startups, porque no tienen que preocuparse por la escalabilidad. Pero ahora, si piensas en grandes empresas, si piensas, ¿deberíamos adoptar una arquitectura serverless, donde ya tenemos una infraestructura en su lugar? Así que creo que la pregunta allí sería, OK, ¿cuáles son los beneficios? Y si ya tenemos algo establecido, entonces, ¿dónde encaja serverless en esa arquitectura? Y también, si vamos a serverless para una tarea específica, así que estábamos discutiendo antes, como, si vamos a continuar con nuestra infraestructura, pero luego queremos probar algunas de las funciones serverless para tareas intensivas en CPU, o para cosas que requieren muchas solicitudes, o que tendrán mucha carga. Creo que esa sería la pregunta sobre la decisión que tenemos que tomar en términos de arquitectura, decidiendo dónde encaja en una gran empresa. Porque, quiero decir, no todos tienen la oportunidad de simplemente diseñar desde cero, como en el mundo de las startups donde puedes tener todo a tu disposición, que puedes elegir la tecnología.

A veces, cuando ya tienes algo establecido, es más difícil tomar esa decisión de adoptar algo diferente. Pero supongo que hay varias áreas que son atractivas para grandes empresas debido a la carga también. Así que, sí. Genial. Gracias. Aaron? Creo que Ally hizo un excelente punto cuando básicamente dijo, sabes, como, tienes que comenzar con lo que te sientas cómodo. Y creo que, sabes, para mí, la economía de los desarrolladores siempre va a ser una clave en la toma de decisiones. Sabes, si yo generalmente, sabes, cuando contrato personas y preguntan, oh, ¿debería usar, sabes, esta tecnología o este framework para comenzar a construir este nuevo servicio? Y yo dije, sabes, bueno, ¿cuánta experiencia tienes con lo que estás sugiriendo? Y es como, bueno, sabes, he estado haciendo, sabes, cinco años de trabajo con, sabes, con este framework, pero he estado escuchando que este es el futuro. Así que debería moverme allí. Y diría, bueno, sabes, comienza con lo que te hará más productivo. Sabes, tú personalmente, el desarrollador, deberías comenzar con la tecnología y la arquitectura y las herramientas con las que te sientas más cómodo. Y luego, a medida que comienzas a construir tu servicio, no tienes que esperar cinco años para hacer esto. Sabes, después de unos meses cuando ya sabes lo que estás haciendo, ya tienes una prueba de concepto que está funcionando. Entonces puedes comenzar a hacerte la pregunta arquitectónica más grande. Y es muy desafiante. Sabes, hay casos de uso para serverless que son obvios. Sabes, haces procesamiento de imágenes, procesamiento de datos, sabes, hay todas estas cosas que Node no es bueno cuando se trata del bucle de eventos. Porque, sabes, si algo está limitado por CPU, toma mucho tiempo, entonces tu servidor está básicamente haciendo una cosa.

Sí, puedes establecer límites y cosas así, pero si estás ejecutando contenedores, dices, mira, solo puedo permitirme ejecutar cinco contenedores de este tamaño. Voy a pagar esta cantidad de dinero cada mes, y, sí, la calidad de mi servicio puede degradarse con el tiempo a medida que tengo más carga, pero al menos puedo decidir, está bien, voy a agregar un servidor más, sé el costo exacto de ese servidor, así que es mucho más fácil para el presupuesto que otros componentes de infraestructura más elásticos. ¿Puedo intervenir rápidamente aquí? Así que, sí, no estoy de acuerdo en que sea más fácil presupuestar, es diferente, así que sí, es más fácil saber cuánto cuesta un servidor, como, digamos, $30 o algo así, y con Lambda Functions, tienes un modelo de precios completamente diferente. Así que personalmente tengo cero idea de cuántos servidores necesito para algo.

Necesitas hacer pruebas de carga en tu aplicación, necesitas ver cuántos usuarios puedes atender con un servidor, y con funciones Lambda, es diferente. Es como si básicamente de costos fijos te estás moviendo a costos variables, y realmente depende de lo que estés construyendo. Eso creo que es la clave de todo. Si estás construyendo un sistema donde tienes un presupuesto limitado, entonces, por supuesto, es mejor optar por algo que puedas predecir fácilmente. Pero si estás construyendo un SaaS o algo así, o incluso una gran empresa donde ganas algo de dinero de tus usuarios, está bien escalar tu infraestructura y todo con más usuarios y, por supuesto, más dinero que estás obteniendo. Y es realmente difícil hacer eso al principio, pero no creo que las funciones sean la parte más importante de serverless. Para nosotros, es realmente importante que no pensemos en la escalabilidad de algunos otros componentes. Por ejemplo, conozco el costo de mis errores. Por ejemplo, tuvimos un error y tuvimos 250 millones de escrituras dentro de nuestra base de datos durante un mes, y eso costó $300. Así que, sí, es algo que podríamos haber prevenido, pero tenemos alarmas en la facturación y todo lo demás. Y, sí, todo escaló. Mi servicio no dejó de funcionar para ellos, y el costo en sí, no es tan grande. Así que para nosotros, la producción es como $250 o algo así. Así que es realmente barato. Es diferente para aplicaciones empresariales, por supuesto, pero, de nuevo, si pagas por servidores de infraestructura, pero también necesitas pagar a las personas que mantendrán estos servidores. Así que, sí, el costo no es tan predecible. No es solo el costo del servidor en sí. Alguien necesita hacer algo sobre ese servidor. Sí, y puedes controlar la cantidad de funciones, ¿verdad? Sí, pero aún depende.

Soy Slobodan, y soy cofundador y CTO de Vacation Tracker, un sistema de gestión de seguimiento en vivo. También soy héroe sin servidor de AWS. Trabajo mucho con sin servidor y también escribí un libro sobre aplicaciones sin servidor con Node.js con mi amigo Alexander Simovitch.

Genial. Así que empecemos, chicos. Node.js, como saben, se ha convertido en una opción muy popular en las startups e incluso en las empresas, y especialmente en sin servidor. Y al construir una nueva aplicación, ¿qué arquitectura te gustaría tener, y cuál es la forma que te gustaría elegir, el enfoque regular con Roads, o la arquitectura sin servidor, estas funciones?

Y si estás construyendo una aplicación con las funciones en un entorno sin servidor, ¿qué nivel de granularidad te gustaría preferir y sugerir a nuestra audiencia? ¿Es una aplicación monolítica, o son servicios, micro-servicios, o funciones? ¿Y debería comenzar al principio del proyecto con un monolito y luego profundizar en las funciones? ¿Qué piensas sobre esto? ¿Quién comenzará?

Sí, lo siento. Así que solo puedo hablar sobre mi perspectiva y lo que estoy haciendo para mi startup, y también mi otra empresa, Cloud Horizon. Básicamente, nuestra startup, Vacation Tracker, ahora es 100% serverless. Está en AWS. Y nuestro enfoque es básicamente comenzar con serverless, porque funciona muy bien para nosotros. Y luego, si algunas partes no, si no podemos hacer algo con serverless, si necesitamos hackear algo, entonces simplemente recurrimos a otras cosas como contenedores o tal vez instancias si es necesario. Pero afortunadamente, por ahora, logramos construir todo con serverless sin grandes problemas. Y hasta ahora, funciona realmente bien. Ahora tenemos muchas funciones Lambda en producción.

Usamos Monorepo para nuestra aplicación, pero básicamente, tenemos pocos servicios y cada servicio tiene un montón de diferentes Lambda funciones y otros servicios dentro de ese servicio. Por ejemplo, Sistema de Gestión de Leads, luego integración con Slack integración, luego integración con Microsoft Teams, y cosas como estas. Y interactúan entre sí a través de algunas APIs. Y son básicamente una especie de microservicios. Así que para mí, la función Lambda es una pequeña función, pero no veo una función Lambda como una aplicación. Es más como un controlador dentro, digamos, de Happy Framework o Express o algo así. Así que para nosotros, eso funciona muy bien. Y el costo hasta ahora es realmente bajo. En este momento, nuestros costos de infraestructura son menos del 1% de nuestros ingresos mensuales. Así que sí, eso funciona realmente bien para nosotros. Pero nuevamente, este es un caso de uso diferente. Así que tal vez no será lo mismo para todos.

Genial. Ellie, ¿qué piensas sobre esto? Sí, estaría de acuerdo en que diferentes problemas tienen diferentes soluciones. Y así, dependiendo de tu equipo, sus experiencias y lo que necesitas priorizar en tu producto, eso es lo que deberías usar. Dicho esto, realmente aprecio el enfoque Serverless porque quita mucho trabajo de los desarrolladores y hace que ese proceso sea mucho menos aterrador. He trabajado para startups la mayor parte de mi carrera y definitivamente he lidiado con mucho tiempo de inactividad y muchas catástrofes de servidores, y que eso sea gestionado por Serverless, creo que es algo positivo. Así que, esa es la dirección en la que iría, pero hay diferentes soluciones para diferentes problemas. Genial. Alejandro? ¿Servidor o Serverless, las funciones?

Alejandro? ¿Servidor o Serverless, las funciones? Creo que ha habido muchas mejoras en tareas limitadas por CPU moviéndose al área de funciones, pero creo que hay mucho margen de mejora allí. Aún así, para procesos limitados por CPU, todavía creo que es más fácil manejarlo con un servidor con una instancia en ejecución que con una función. Y para cosas que tal vez no necesitan ese nivel de rendimiento o granularidad, ya sea que cambies el tamaño de la instancia o la CPU o el número de hilos para eso, yo optaría por funciones para eso. Gracias. ¿Ruben? Sí, volviendo al caso de uso, la primera pregunta que tendría sería sobre la escalabilidad. Tú sabes, si quieres empezar pequeño y luego crecer, entonces serverless es muy útil, porque no tienes que preocuparte por escalar las cosas. No tienes que preocuparte de si vamos a poder manejar la carga desde el principio. Supongo que, aparte de eso, y obviamente, las implicaciones en el costo pequeño, porque solo estás pagando por lo que estás usando, eso es muy atractivo para las startups, porque no tienen que preocuparse por la escalabilidad. Pero ahora, si piensas en grandes empresas, si piensas, ¿deberíamos adoptar una arquitectura serverless, donde ya tenemos una infraestructura en su lugar? Así que creo que la pregunta allí sería, OK, ¿cuáles son los beneficios? Y si ya tenemos algo establecido, entonces, ¿dónde encaja serverless en esa arquitectura? Y también, si vamos a serverless para una tarea específica, así que estábamos discutiendo antes, como, si vamos a continuar con nuestra infraestructura, pero luego queremos probar algunas de las funciones serverless para tareas intensivas en CPU, o para cosas que requieren muchas solicitudes, o que tendrán mucha carga. Creo que esa sería la pregunta sobre la decisión que tenemos que tomar en términos de arquitectura, decidiendo dónde encaja en una gran empresa. Porque, quiero decir, no todos tienen la oportunidad de diseñar desde cero, como en el mundo de las startups donde puedes tener todo a tu disposición, que puedes elegir la tecnología. A veces, cuando ya tienes algo establecido, es más difícil tomar esa decisión de adoptar algo diferente. Pero supongo que hay varias áreas que son atractivas para las grandes empresas debido a la carga también. Así que, sí. Genial. Gracias. ¿Aaron? Creo que Ally hizo un excelente punto cuando básicamente dijo, sabes, como, tienes que empezar con lo que te sientas cómodo. Y creo que, sabes, como para mí, la economía del desarrollador siempre va a ser una clave en la toma de decisiones. Sabes, si yo usualmente, sabes, cuando contrato personas y preguntan, oh, ¿debería usar, sabes, esta tecnología o este framework para empezar a construir este nuevo servicio? Y yo dije, sabes, bueno, ¿qué tan experimentado estás con lo que estás sugiriendo? Y es como, bueno, sabes, he estado haciendo, sabes, cinco años de trabajo con, sabes, con este framework, pero he estado escuchando que este es el futuro. Así que debería moverme allí. Y diría como, bueno, sabes, empieza con lo que te hará más productivo. Sabes, tú personalmente, el desarrollador, deberías empezar con la tecnología y la arquitectura y las herramientas con las que te sientas más cómodo. Y luego, a medida que empieces a construir tu servicio, no tienes que esperar cinco años para hacer esto. Sabes, después de unos meses cuando ya sabes lo que estás haciendo, ya tienes una prueba de concepto que está funcionando. Entonces puedes empezar a hacerte la pregunta arquitectónica más grande. Y es muy desafiante. Sabes, hay casos de uso para serverless que son obvios. Sabes, haces procesamiento de imágenes, procesamiento de datos, sabes, hay todas estas cosas que Node no es bueno cuando se trata del bucle de eventos. Porque, sabes, si algo está limitado por CPU, toma mucho tiempo, entonces tu servidor está básicamente haciendo una cosa. Y ahí es donde, sabes, serverless realmente brilla. Así que, si tienes que redimensionar imágenes para vistas previas, eso es algo obvio. Como, sabes, cualquiera que empiece hoy irá y buscará esa herramienta, independientemente de dónde estén trabajando.

Pero entonces, si solo estás haciendo, está bien, inicias sesión, ¿debería tu inicio de sesión ser un servidor o debería ser una función serverless? Y ahora, estás como, está bien, no hay una solución trivial para eso. Algunas de las, ya sabes, las cosas que se han dicho antes, sí, serverless será mucho más barato para ti cuando empieces, pero probablemente será un poco más caro que los contenedores regulares a medida que escales porque es ilimitado. Porque, básicamente, cuanto más solicitudes recibas, más instancias serverless están potencialmente funcionando. Sí, puedes establecer límites y cosas así, pero si estás ejecutando contenedores, dices, mira, solo puedo permitirme ejecutar cinco contenedores de este tamaño. Voy a pagar esta cantidad de dinero cada mes, y, sí, la calidad de mi servicio puede degradarse con el tiempo a medida que tengo más carga, pero al menos puedo decidir, está bien, voy a agregar un servidor más, sé el costo exacto de ese servidor, así que es mucho más fácil para la presupuestación que otros componentes de infraestructura más elásticos.

¿Puedo intervenir rápidamente aquí? Así que, sí, no estoy de acuerdo en que sea más fácil presupuestar, es diferente, así que sí, es más fácil saber cuánto cuesta un servidor, como, digamos, $30 o algo así, y con Lambda Functions, tienes un modelo de precios completamente diferente. Así que personalmente tengo cero idea de cuántos servidores necesito para algo. Necesitas hacer pruebas de carga en tu aplicación, necesitas ver cuántos usuarios puedes atender con un servidor, y con funciones Lambda, es diferente. Es como si básicamente de costos fijos te estás moviendo a costos variables, y realmente depende de lo que estés construyendo. Eso creo que es la clave de todo. Si estás construyendo un sistema donde tienes un presupuesto limitado, entonces, por supuesto, es mejor optar por algo que puedas predecir fácilmente. Pero si estás construyendo un SaaS o algo así, o incluso una gran empresa donde ganas algo de dinero de tus usuarios, está bien escalar tu infraestructura y todo con más usuarios y, por supuesto, más dinero que estás obteniendo.

Y es realmente difícil hacer eso al principio, pero no creo que las funciones sean la parte más importante de serverless. Para nosotros, es realmente importante que no pensemos en la escalabilidad de algunos otros componentes. Por ejemplo, conozco el costo de mis errores. Por ejemplo, tuvimos un error y tuvimos 250 millones de escrituras dentro de nuestra base de datos durante un mes, y eso costó $300. Así que, sí, es algo que podríamos haber prevenido, pero tenemos alarmas sobre la facturación y todo lo demás. Y, sí, todo escaló. Mi servicio no dejó de funcionar para ellos, y el costo en sí, no es tan grande. Así que para nosotros, la producción es como $250 o algo así. Así que es realmente barato. Es diferente para aplicaciones empresariales, por supuesto, pero, de nuevo, si pagas por servidores de infraestructura, pero también necesitas pagar a las personas que mantendrán estos servidores. Así que, sí, el costo no es tan predecible. No es solo el costo del servidor en sí. Alguien necesita hacer algo sobre ese servidor. Sí, y puedes controlar la cantidad de funciones, ¿verdad? Sí, pero aún depende. Si tienes un número limitado de funciones, entonces algunos de tus usuarios recibirán el error. Con servidores, es diferente. Puedes obtener una carga mayor, pero aún recibirás la respuesta. Así que ese punto es realmente bueno, por supuesto.

Si tienes un número limitado de funciones, entonces algunos de tus usuarios recibirán el error. Con servidores, es diferente. Puedes soportar una carga mayor, pero aún así recibirás la respuesta. Así que ese punto es realmente bueno, por supuesto.

Estoy de acuerdo. Y también, tenemos una pregunta de nuestra audiencia. Es exactamente sobre el caso de uso. Así que la pregunta es, ¿cómo Node.js en la nube ayuda con IoT en la nube? Bueno, depende de lo que quieras hacer con IoT. Así que necesitas procesar algunos datos. Y mientras quieras procesar algunos datos, por supuesto, Node.js puede ayudarte con eso. Y la mayor parte de Node.js está en la nube de todos modos. Es como, si no posees una función serverless, probablemente lo alojas en algún tipo de servidor o algo así, que no tienes en tu sala de estar. Así que, de todos modos, al final, eso es una especie de nube. Pero sí, no tengo mucha experiencia con IoT, pero puedes usar WebSockets con serverless y puedes usar WebSockets con Node.js en servidores tradicionales de Node.js. Así que no creo que haya una gran diferencia.

Y depende de lo que quieras hacer con tus datos. Estoy de acuerdo. Y también podemos usar el IoT Hub, digamos en AWS, sí, y procesar los datos a través de Node.js nuevamente en un flujo.

¿Alguien quisiera agregar algo a esta pregunta? Bien, pasemos a la siguiente pregunta. Así que decidimos qué elegiremos, servidor o serverless. Y considerando los frameworks, chicos, ¿qué piensan de los frameworks actuales como Hapi, Express, Fastify que pueden ayudarnos en un entorno serverless o si prefieren usar un servidor puro de Node.js sin ningún framework y usar un framework serverless y SDK de proveedores de nube populares, ¿tienen suficiente de los SDK listos para usar? ¿O sienten que hay una brecha entre el desarrollo y tienen que estructurar su código manualmente?

¿Qué piensan sobre esto? Comencemos con Aaron. Sabes, para mí esa fue como la pregunta de un millón de dólares durante el último año y medio. Y llegué a dos conclusiones con eso, una es que sí, definitivamente nos faltan herramientas y los frameworks que tenemos hoy están luchando para hacer la transición a este nuevo mundo. Personalmente, he creado Happy y lo he mantenido durante casi una década y el año pasado básicamente decidí que el framework está un poco terminado y el futuro va a ser algo que va a ser nuevo. Los mayores desafíos para los frameworks tradicionales son que todos asumen una arquitectura de larga duración, lo que significa que hacen mucho trabajo por adelantado así que el tiempo de carga es largo. Pero una vez que están en funcionamiento y cargados, proporcionan una gran cantidad de funcionalidades que son extremadamente eficientes y productivas para los desarrolladores. Así que, por ejemplo, tienen todo tipo de caché incorporada. Así que digamos que tienes una aplicación que necesita acceder a datos de países. Los datos de países son estables. No tenemos nuevos países añadidos dinámicamente sobre la marcha, así que no es una de esas cosas que puedes cargar en memoria, puedes procesarlo, puedes almacenarlo en caché, indexarlo y luego no tienes que ir a la base de datos cada vez que tienes una llamada API que trata con datos de países.

De acuerdo. Y también, tenemos una pregunta de nuestra audiencia. Es exactamente sobre el caso de uso. Así que la pregunta es, ¿cómo ayuda Node.js en la nube para IoT en la nube? Bueno, depende de lo que quieras hacer con IoT. Así que necesitas procesar algunos datos. Y mientras quieras procesar algunos datos, por supuesto que Node.js puede ayudarte con eso. Y la mayor parte de Node.js está en la nube de todos modos. Es como, si no posees una función serverless, probablemente lo alojes en algún tipo de servidor o algo así, que no tienes en tu sala de estar. Así que, de todos modos, al final, eso es una especie de nube. Pero sí, no tengo mucha experiencia con IoT, pero puedes usar WebSockets con serverless y puedes usar WebSockets con Node.js con servidores Node.js tradicionales. Así que no creo que haya una gran diferencia. Y depende de lo que quieras hacer con tus datos.

De acuerdo. Y también podemos usar el IoT Hub, digamos en AWS, sí, y procesar los datos a través de Node.js nuevamente en un flujo. ¿Alguien quisiera agregar algo a esta pregunta? Bien, pasemos a la siguiente pregunta. Así que decidimos qué elegiremos, servidor o serverless. Y considerando los frameworks, chicos, ¿qué piensan de los frameworks actuales como Hapi, Express, Fastify? ¿Pueden ayudarnos en un entorno serverless o prefieren usar un servidor Node.js puro sin ningún framework y usar un framework serverless y SDK de proveedores de nube populares? ¿Tienen suficiente de lo que viene con el SDK? ¿O sienten que hay una brecha entre el desarrollo y tienen que estructurar su código manualmente? ¿Qué piensan de esto? Comencemos con Aaron.

Sabes, para mí esa fue como la pregunta de un millón de dólares durante el último año y medio. Y llegué a dos conclusiones con eso, una es que sí, definitivamente nos faltan herramientas y los frameworks que tenemos hoy están luchando para hacer la transición a este nuevo mundo. Personalmente, he creado Happy y lo he mantenido durante casi una década y el año pasado básicamente decidí que el framework está un poco terminado y el futuro va a ser algo que va a ser nuevo. Los mayores desafíos para los frameworks tradicionales son que todos asumen una arquitectura de larga duración, lo que significa que hacen mucho trabajo por adelantado así que el tiempo de carga es largo. Pero una vez que están en funcionamiento y cargados, proporcionan mucha funcionalidad que es extremadamente eficiente y productiva para los desarrolladores. Así que, por ejemplo, tienen todo tipo de caché incorporada. Así que digamos que tienes una aplicación que necesita acceder a datos de países. Los datos de países son estables. No tenemos nuevos países añadidos dinámicamente sobre la marcha, así que no es una de esas cosas que puedes cargar en memoria, puedes procesarlo, puedes almacenarlo en caché, indexarlo y luego no tienes que ir a la base de datos cada vez que tienes una llamada API que trata con datos de países. Lo hace muy eficiente para una arquitectura de contenedor regular, pero luego no puedes usar esta arquitectura para serverless porque cada vez que vas a levantar una instancia, tendrás que ir y cargar toda esta tabla en memoria y procesarla y ahora estás gastando, incluso si son solo 200 milisegundos, primero, todas tus solicitudes son 200 milisegundos más largas, pero también ahora estás pagando por 200 milisegundos de funciones en la nube en cada solicitud como sobrecarga.

cargar toda esta tabla en memoria y procesarla y ahora estás gastando, incluso si son solo 200 milisegundos, primero, todas tus solicitudes son 200 milisegundos más largas, pero también ahora estás pagando por 200 milisegundos de funciones en la nube en cada solicitud como sobrecarga. Así que esta es el área donde creo que siento que los desarrolladores hoy en día se ven obligados a elegir. Así que si estás diciendo, está bien, necesito construir un nuevo endpoint, necesito decidir de antemano dónde lo voy a desplegar. Así que puedes, sabes, puedes escribir la abstracción, puedes escribir una función que tomará una imagen y la redimensionará y luego la guardará en S3 y luego la enviará de vuelta o algo así. Pero tan pronto como pienses en desplegarla, tienes que decidir a dónde va a ir. ¿Va a ser una ruta de express o happy o festify o va a ser una función? Y no creo que eso sea algo bueno para tener en este momento. Creo que eso limita a los desarrolladores tanto en creatividad, flexibilidad y la capacidad de realmente probar cosas en un entorno integrado. Lo que creo que nos falta en este momento es un nuevo enfoque, básicamente lo que yo llamo contenedores para funciones. Así que si podemos escribir nuestro middleware o nuestras rutas de una manera más abstracta, como algún tipo de estándar ligero, y luego poder adaptar esto a un despliegue de framework o un despliegue serverless regular o despliegue de framework, creo que eso sería algo realmente genial. Y eso es lo que he estado explorando durante un año y medio. El problema es que, como proyecto de código abierto, en algún momento, te quedas sin financiación. Y es cuando decidí que era hora de entregar happy a una nueva generación de desarrolladores y jugar con otras cosas al lado. Pero creo que eso va a ser la próxima gran cosa, dejar de pensar en el desarrollo como un o, y comenzar a pensar en cómo podemos ser un poco más fluidos y más flexibles con cómo estamos desarrollando. Así que creo que ese va a ser el mayor desafío. Y cualquier framework, cualquier framework tradicional como happy y express, que no encuentre formas de permitir que su lógica de negocio sea fácilmente extraída de las rutas y desplegada como serverless va a morir. Simplemente no van a tener adopción. Así que quien los esté usando hoy continuará usándolos porque se sienten cómodos y productivos en ese entorno. Pero cualquiera que esté pensando en un nuevo framework hoy mirará el panorama y dirá, como, no sé, ¿debería empezar con happy, express o Festivite hoy desde cero? No lo sé. Básicamente me va a encerrar en una arquitectura antigua.

Eso no va a ser fácil de escalar o mover. Y luego puedes terminar con un entorno probablemente menos maduro porque no viene con 10 años de optimizaciones que los otros frameworks tienen. Así que definitivamente va a haber un cambio aquí. Y podría ser generacional en términos de desarrolladores como yo, que son mayores y más experimentados y han estado haciendo las cosas de la misma manera durante 25 años. Y luego las nuevas personas en la industria que están entrando y abrazando toda la nueva tecnología y construyendo la nueva visión. Esa es una idea muy interesante. Ruben, ¿qué piensas sobre esto? Sí, así que iba a decir, he estado allí en realidad. Y el bloqueo de proveedor es un problema. Y estoy bastante seguro de que muchas personas están pensando hoy, ¿deberíamos salir de Express? ¿Deberíamos probar Fastify? Pero luego hay otro caso donde, está bien, ¿qué pasa si solo haces funciones serverless?

Así que puedes, ya sabes, puedes escribir la abstracción, puedes escribir una función que tomará una imagen, la redimensionará y luego la guardará en S3 y luego la enviará de vuelta o algo así. Pero tan pronto como pienses en desplegarlo, tienes que decidir dónde va a ir. ¿Va a ser una ruta de express, happy o festify, o va a ser una función? Y no creo que eso sea algo bueno en este momento. Creo que eso limita a los desarrolladores tanto en creatividad, flexibilidad, como en la capacidad de realmente probar cosas en un entorno integrado. Lo que creo que nos falta en este momento es un nuevo enfoque, básicamente lo que yo llamo contenedores para funciones divertidas. Así que si podemos escribir nuestro middleware o nuestras rutas de una manera más abstracta, como algún tipo de estándar ligero, y luego poder adaptar esto a un despliegue de framework o un despliegue serverless regular o despliegue de framework, creo que eso sería algo realmente genial. Y eso es un poco con lo que he estado jugando durante un año y medio.

El problema es que, como proyecto de código abierto, en algún momento, te quedas sin financiación. Y ahí fue cuando decidí que era hora de entregar happy a una nueva generación de desarrolladores y un poco ir a jugar con otras cosas al lado. Pero creo que eso va a ser la próxima gran cosa, dejar de pensar en el desarrollo como un o, y comenzar a pensar en cómo podemos ser un poco más fluidos y más flexibles con cómo estamos desarrollando. Así que creo que ese va a ser el mayor desafío. Y cualquier framework, cualquier framework tradicional como happy y express, que no encuentre formas de permitir que su lógica de negocio sea fácilmente extraída de las rutas y desplegada como serverless, va a morir. Simplemente no van a tener adopción. Así que quien los esté usando hoy continuará usándolos porque se sienten cómodos y productivos en ese entorno.

Pero cualquiera que esté pensando en un nuevo framework hoy mirará el panorama y dirá, como, no sé, ¿debería empezar con happy, express o Festivite hoy desde cero? No lo sé. Básicamente me va a bloquear en una arquitectura antigua. Eso no va a ser fácil de escalar o mover. Y luego puedes terminar con un entorno probablemente menos maduro porque no viene con 10 años de optimizaciones que los otros frameworks tienen. Así que definitivamente va a haber un cambio aquí. Y podría ser generacional en términos de desarrolladores como yo, que son mayores y más rígidos y han estado haciendo las cosas de la misma manera durante 25 años. Y luego las nuevas personas en la industria que están entrando y abrazando toda la nueva tecnología y construyendo la nueva visión. Esa es una idea muy interesante. Ruben, ¿qué piensas sobre esto? Sí, así que iba a decir, he estado allí, de hecho. Y el bloqueo de proveedor es un problema. Y estoy bastante seguro de que muchas personas están pensando hoy, ¿deberíamos salir de Express? ¿Deberíamos probar Fastify? Pero luego hay otro caso donde, está bien, ¿qué pasa si solo haces funciones serverless? Y creo que lo que Aaron mencionó que es realmente, realmente, sería increíble es si tuviéramos una manera de abstraer toda la lógica de negocio y asegurarnos de que podamos desplegar ya sea serverless o tradicional sin el bloqueo de proveedor, sin tener que preocuparnos por todos estos internos que vienen de un framework que se nos proporciona. Así que supongo que, sí, he estado allí. Y también, con el proceso de larga duración, esa es otra cosa que he experimentado antes, donde tenemos un servidor de larga duración y tenemos todo en memoria.

la palabra maldita. Así que, sí, eso es lo que pienso. Alejandro, ¿qué piensas sobre esto? Sí, me gusta lo que mencionaban Aaron y Ruben sobre que quien no facilite la extracción de la lógica de negocio y poner eso en una función o morirá o perderá adopción. Y sí, creo que está estrechamente relacionado con la ergonomía del desarrollador, la experiencia del desarrollador. Sí, estoy de acuerdo con esa opinión y creo que es algo a tener en cuenta si eres un autor o mantenedor de uno de esos proyectos que están ahí afuera. ¿Cómo integrar eso?

Y así es como funciona en este momento. Y es realmente rápido porque todo está en memoria y podemos atender solicitudes realmente, realmente rápido. Pero a medida que comenzábamos la opción de movernos hacia una arquitectura serverless, entonces estábamos como, OK, esto ya no va a funcionar. No tenemos cosas en memoria. Allí ya no hay un proceso en ejecución. Así que, necesitamos evaluar el impacto en el rendimiento porque, tú sabes, estamos acostumbrados a respuestas de solicitudes realmente rápidas del servidor porque tenemos toda la configuración y todos los elementos que necesitamos para responder ya en memoria. Así que, también experimenté eso. Y eso es algo en lo que la gente tiene que pensar si quieres moverte hacia la arquitectura serverless. Pienso que el inicio en frío es la palabra maldita. Así que, sí, eso es lo que pienso.

Alejandro, ¿qué piensas sobre esto? Sí, me gusta lo que Aaron y Ruben mencionaban sobre quien no haga fácil extraer la lógica de negocio y ponerla en una función, o morirá o perderá adopción. Y sí, creo que está estrechamente relacionado con la ergonomía del desarrollador, la experiencia del desarrollador. Sí, estoy de acuerdo con esa visión y creo que es algo a tener en cuenta si eres un autor o mantenedor de uno de esos proyectos que están ahí afuera. ¿Cómo integrar eso? Sé que es una transición a largo plazo. No es algo que sucederá de la noche a la mañana. Pero es algo a lo que mirar y mejorar en la transición de tu lógica existente a funcionalidad, función, nube. Sí. Genial, estoy de acuerdo.

Tenemos una pregunta sobre AWS Amplify. Ellie, así que supongo que va para ti. ¿Qué piensas sobre el auge de frameworks de bajo código como AWS Amplify? Me gusta esa pregunta. Así que, primero que nada, creo personalmente que el bajo código tiene el mayor potencial cuando piensa en los desarrolladores como parte de la solución en lugar de una oposición a ella, ¿verdad? Como muchas de las soluciones de bajo código originales eran, como, solo clic y arrastra, y luego tienes una aplicación que está lista. Y creo que eso es mucho de bajo código. Y algo que realmente me emociona del bajo código es incluir a los desarrolladores en esto. Así que, haciéndolo para que cualquiera pueda ser un desarrollador, pero aún pensando en el desarrollador en eso. Lanzamos la interfaz de usuario de administración para Amplify durante reInvent. Y algo que realmente me gusta de eso es que sigue siendo compatible con la interfaz de línea de comandos de Amplify, y así realmente se encuentra con los desarrolladores donde están. Y todo el código es realmente generado, así que no está en una caja negra ni nada por el estilo. Puedes acceder a todo. Y así, estoy emocionado por las soluciones de bajo código que aún piensan en los desarrolladores en el proceso y simplemente hacen que sea más accesible ser un desarrollador.

Genial, estoy de acuerdo. Tenemos una pregunta sobre AWS Amplify. Ellie, así que supongo que va para ti. ¿Qué piensas sobre el auge de los frameworks de low-code como AWS Amplify? Me gusta esa pregunta. Así que, primero que nada, creo personalmente que el low-code tiene el mayor potencial cuando piensa en los desarrolladores como parte de la solución en lugar de una oposición a ella, ¿verdad? Como muchas de las soluciones originales de low-code eran, como, solo hacer clic y arrastrar, y luego tienes una aplicación que está lista. Y creo que eso es mucho del low-code. Y algo que realmente me emociona del low-code es incluir a los desarrolladores en esto. Así que, haciéndolo para que cualquiera pueda ser un desarrollador, pero aún pensando en el desarrollador en eso. Lanzamos la interfaz de usuario administrativa para Amplify durante reInvent. Y algo que realmente me gusta de eso es que todavía es compatible con la interfaz de línea de comandos de Amplify, y así realmente se encuentra con los desarrolladores donde están. Y todo el código se genera realmente, así que no está en una caja negra ni nada por el estilo. Puedes acceder a todo.

Bien. Genial. Tenemos muchas preguntas sobre serverless e incluso preguntas directamente para Slobodan. Supongo que podemos proceder con todas ellas después de esta discusión porque tendremos un tema de discusión sobre el serverless. Pero déjame preguntar a Slobodan sobre el framework y su futuro en serverless.

Slobodan, ¿qué piensas sobre esto? ¿Podríamos tener algún framework en el futuro que combine algunos servicios populares? Y sí, ¿qué piensas sobre esto? Estoy realmente de acuerdo con Aaron y todo lo que dijo. Estoy completamente de acuerdo con eso. Soy un gran fan del framework Hopi y lo usé mucho en algún momento y definitivamente fue mi framework favorito de Node.js. En este momento no tenemos nada similar en serverless. Tenemos algunos nuevos enfoques y me gustan. Por supuesto, la gente está tratando de copiar algunos buenos conceptos de frameworks tradicionales a serverless con algunos middlewares y cosas como estas, que son realmente buenas.

Pero, por otro lado, definitivamente nos faltan algunos frameworks más grandes que vendrán con el tiempo, seguro. Todavía es nuevo. La gente ha estado usando serverless en los últimos años, así que apenas comenzaron a construir aplicaciones grandes con ello. Pero estoy hablando mucho sobre el vendor lock-in y cosas como estas, y no podemos esperar que Amazon o Microsoft o cualquier gran proveedor resuelva ese problema por nosotros, porque, por supuesto, no está en su lista de características resolver el problema del vendor lock-in. Pero, por otro lado, puedes elegir la arquitectura que funcione para ti.

Bien. Genial. Tenemos muchas preguntas sobre serverless e incluso preguntas directamente para Slobodan.

Supongo que podemos proceder con todas ellas después de esta discusión porque tendremos un tema de discusión sobre el serverless. Pero déjame preguntarle a Slobodan sobre el framework y su futuro en serverless. Slobodan, ¿qué piensas sobre esto? ¿Podríamos tener algún framework en el futuro que combine algunos servicios populares?

Y sí, ¿qué piensas sobre esto? Estoy realmente de acuerdo con Aaron y todo lo que dijo. Estoy completamente de acuerdo con eso. Soy un gran fan del Hopi framework y lo usé mucho en algún momento y definitivamente fue mi framework favorito de Node.js. En este momento no tenemos nada similar en serverless. Tenemos algunos nuevos enfoques y me gustan. Por supuesto, la gente está tratando de copiar algunos buenos conceptos de frameworks tradicionales a serverless con algunos middlewares y cosas como estas, que son realmente buenas. Pero, por otro lado, definitivamente nos faltan algunos frameworks más grandes que llegarán con el tiempo, seguro. Todavía es nuevo. La gente ha estado usando serverless en los últimos años, así que apenas empezaron a construir aplicaciones grandes con ello. Pero estoy hablando mucho sobre el vendor lock-in y cosas como estas, y no podemos esperar que Amazon o Microsoft o cualquier gran proveedor resuelva ese problema por nosotros, porque, por supuesto, no está en su lista de características resolver el problema del vendor lock-in. Pero, por otro lado, puedes elegir la arquitectura que funcione para ti. Por ejemplo, sería genial si pudiéramos simplemente tomar parte de nuestro, digamos, Express handler o algo así, y poner eso en una función serverless. Pero podemos usar arquitecturas como la arquitectura hexagonal y básicamente construir eso con nuestro código. Así que tendremos una entrada de la función Lambda y otra entrada, digamos, de la ruta express.js o algo así, y luego tendremos un pequeño adaptador que adaptará nuestra lógica de negocio que debería estar aislada de todo, básicamente, para traducir esa solicitud a algo que nuestra lógica de negocio entienda. Estuvimos usando eso en Vacation Tracker, y migramos muchas cosas. Ahora estamos usando GraphQL, y comenzamos incluso con un servidor express, y luego después de eso, continuamos con muchas funciones Lambda. Pero, básicamente, nuestra lógica de negocio no sabe sobre la base de datos o sobre el trigger en sí. Sabe sobre la lógica de negocio, y luego tenemos adaptadores para todas las cosas diferentes. Es un poco más complejo, y estoy ansioso por algunos frameworks que simplifiquen eso en el futuro. Eso es bueno. Solo tenemos tiempo para una pregunta, y déjame tomar la última pregunta del chat.

Por ejemplo, sería genial si pudiéramos tomar parte de nuestro, digamos, manejador de Express o algo así, y poner eso en una función serverless. Pero podemos usar arquitecturas como la arquitectura hexagonal y básicamente construir eso con nuestro código. Así que tendremos una entrada de la función Lambda y otra entrada, digamos, de la ruta de express.js o algo así, y luego tendremos un pequeño adaptador que adaptará nuestra lógica de negocio que debería estar aislada de todo, básicamente, para traducir esa solicitud a algo que nuestra lógica de negocio entienda. Estábamos usando eso en Vacation Tracker, y migramos muchas cosas. Ahora estamos usando GraphQL, y comenzamos incluso con un servidor express, y luego después de eso, continuamos con muchas funciones Lambda. Pero básicamente, nuestra lógica de negocio no sabe sobre la base de datos o sobre el trigger en sí. Sabe sobre la lógica de negocio, y luego tenemos adaptadores para todas las diferentes cosas. Es un poco más complejo, y estoy ansioso por algunos frameworks que simplificarán eso en el futuro.

Eso es bueno. Solo tenemos tiempo para una pregunta, y déjame tomar la última pregunta del chat. Así que, tenemos una pregunta sobre DevOps, y si estás desarrollando en serverless, usando ¿Necesitamos DevOps en ellos? O otra pregunta sobre este tema es ¿cómo manejan la gran cantidad de funciones y cómo las despliegan? ¿Qué enfoque preferirían usar en monorepo o desplegar todo por separado? Y creo, ¿necesitamos un DevOps en este caso? Responderé muy rápido sobre nuestro caso. No tenemos a nadie que esté haciendo DevOps en nuestro equipo, pero nuestro equipo es realmente pequeño. A mayor escala, por supuesto que necesitarás algunas personas que se encarguen de la infraestructura, no realmente sobre la única función Lambda, pero hay muchas cosas sucediendo en la aplicación y alguien necesita entender eso y asegurarse de que todo realmente funcione, escalando adecuadamente, y todo lo demás. Sí, necesitas algo de ayuda. Sí, estamos usando monorepo, pero hay muchas otras cosas que puedes hacer y desplegar fácilmente todas las funciones con un solo comando.

Está bien. ¿Ruben? Sí, definitivamente necesitamos DevOps. Hay un caso de uso que me gusta y es donde tienes todos tus entornos configurados desde cero todos los días, como tener entornos de prueba. Definitivamente necesitas a alguien que pueda ayudarte a configurar y ejecutar todos esos entornos de prueba y apagarlos y asegurarse de que funcionen. Creo que, de nuevo, depende de la escala, hay oportunidad de tener un equipo dedicado a esto. Así que, no creo que serverless elimine completamente DevOps, creo que lo mejorarás porque las personas que se convierten en especialistas se encargarán de todas estas configuraciones y cosas. Como dijeron que teníamos antes, solo dijeron que se trataba de Terraform y asegurarse de que todo funcione. Quiero decir, alguien probablemente necesita ese trabajo para estar a cargo de eso. Ely. Sí, creo que solo añadiré lo que todos los demás dijeron, que DevOps sigue siendo importante, pero creo que ese rol definitivamente cambia y creo que probablemente ha cambiado con el tiempo también. ¿Qué hay de ti, Alejandro? Sí, exactamente lo mismo. Habiendo trabajado con entornos de Kubernetes y esos tipos de cargas de trabajo, creo que el rol de DevOps se trasladará totalmente si eres del tamaño de una gran empresa. Necesitarás DevOps para ejecutar esa infraestructura, sea lo que sea que estés ejecutando, ya sea servidores o funciones en la nube. Necesitarás personas que te ayuden a construir eso.

chat. Entonces, tenemos una pregunta sobre DevOps, y si estás desarrollando en el serverless, usando ¿Necesitamos DevOps en ellos? O otra pregunta sobre este tema es ¿cómo manejan la gran cantidad de funciones y cómo las despliegan? ¿Qué enfoque preferirías usar en monorepo o desplegar todo por separado? Y creo que, ¿necesitamos un DevOps en este caso? Responderé muy rápido sobre nuestro caso. No tenemos a nadie que esté haciendo DevOps en nuestro equipo, pero nuestro equipo es realmente pequeño.

A mayor escala, por supuesto, necesitarás algunas personas que se encarguen de la infraestructura, no realmente sobre la función Lambda individual, pero hay muchas cosas sucediendo en la aplicación y alguien necesita entender eso y asegurarse de que todo realmente funcione, escalando adecuadamente, y todo lo demás. Sí, necesitas algo de ayuda. Sí, estamos usando monorepo, pero hay muchas otras cosas que puedes hacer y desplegar fácilmente todas las funciones con un solo comando. Está bien.

¿Ruben? Sí, definitivamente necesitamos DevOps. Hay un caso de uso que me gusta y es donde tienes todos tus entornos configurados desde cero todos los días, como tener entornos de prueba. Definitivamente necesitas a alguien que pueda ayudarte a configurar y ejecutar todos esos entornos de prueba y apagarlos y asegurarse de que funcionen. Creo que, de nuevo, depende de la escala, hay oportunidad de tener un equipo dedicado a esto. Así que no creo que el serverless elimine completamente a DevOps, creo que lo mejorarás porque las personas que se convierten en especialistas se encargarán de todas estas configuraciones y cosas. Como dijeron antes, solo dijeron que se trataba de Terraform y asegurarse de que todo funcione.

Quiero decir, alguien probablemente necesita ese trabajo para estar a cargo de eso. Ely. Sí, creo que solo voy a sumar lo que todos los demás dijeron, que DevOps sigue siendo importante, pero creo que ese rol definitivamente cambia y creo que probablemente ha cambiado con el tiempo también. ¿Y tú, Alejandro? Sí, exactamente lo mismo. Habiendo trabajado con entornos de Kubernetes y esos tipos de cargas de trabajo, creo que el rol de DevOps definitivamente se transformará si eres del tamaño de una gran empresa. Necesitarás DevOps para ejecutar esa infraestructura, sea lo que sea que estés ejecutando, ya sean servidores o funciones en la nube. Necesitarás personas que te ayuden a construir eso. Sí. Aaron, supongo que se nos acabó el tiempo. Así que, muchas gracias. Está bien, Aaron, por favor. Es... DevOps nunca desaparecerá. Todo lo que estás haciendo es mover complejidad de un lugar a otro, y así que si, sabes, antes, sabes, DevOps se centraba más en, como ejecutar un contenedor o ejecutar un servidor, ejecutar, sabes, metal en bruto. Ahora, están cambiando para centrarse más en configuraciones y en interfaces de nivel más alto. Pero olvida todo lo demás.

Sí. Aaron, supongo que se nos ha acabado el tiempo. Así que, muchas gracias. Bien, Aaron, por favor. Es... DevOps nunca desaparecerá. Todo lo que estás haciendo es mover complejidad de un lugar a otro, y así, si, sabes, antes, sabes, DevOps se centraba más en, como ejecutar un contenedor o ejecutar un servidor, ejecutar, sabes, metal desnudo. Ahora, están cambiando para centrarse más en configuraciones y en interfaces de nivel más alto, sabes.

Pero olvida todo lo demás. Alguien tiene que asegurarse de que la aplicación esté funcionando bien, y necesitan asegurarse de que, sabes, que hay alguien mirando los registros, que tienes registros, que sabes lo que está sucediendo. Los desarrolladores no van a hacer eso a diario, porque están ejecutando código. Así que, sí, serverless podría eliminar la necesidad de configurar un contenedor o trabajar menos con Kubernetes, pero no va a eliminar el trabajo normal de alguien que está mirando lo que está sucediendo y asegurándose de que la app siga activa y que esté sirviendo a los usuarios y que esté funcionando bien.

Y también dando retroalimentación a los desarrolladores, diciéndoles, oye, mira, tu app es demasiado lenta. Los usuarios no están obteniendo el rendimiento por el que están pagando y deberías hacer algo al respecto. Sí. Muchas gracias y gracias por tus preguntas. Y gracias a nuestros expertos y ponentes.

Alguien tiene que asegurarse de que la aplicación esté funcionando bien, y necesitan asegurarse de que, sabes, que hay alguien mirando los registros, que tienes registros, que sabes lo que está sucediendo. Los desarrolladores no van a hacer eso a diario, porque están ejecutando código.

Así que, sí, serverless podría eliminar la necesidad de configurar un contenedor o trabajar menos con Kubernetes, pero no va a eliminar el trabajo normal de alguien mirando lo que está sucediendo y asegurándose de que la aplicación siga activa y que esté sirviendo a los usuarios y funcionando bien. Y también dando retroalimentación a los desarrolladores, diciéndoles, oye, mira, tu aplicación es demasiado lenta. Los usuarios no están obteniendo el rendimiento por el que están pagando y deberías hacer algo al respecto. Sí. Muchas gracias y gracias por tus preguntas.