Construyendo y Operando un Monolito Componible Moderno

Hola a todos, estoy muy emocionado de estar aquí en JS Nation hoy y llevarlos en un viaje, el viaje del monolito componible moderno. Permítanme comenzar presentándome, soy Luca, cofundador y CEO de Platformatic, y junto con mi amigo Matteo Collina y nuestro increíble equipo, tenemos la misión de cambiar completamente el mundo de la construcción de aplicaciones Node.js en la época moderna.

Pueden conectarse conmigo, por favor háganlo en cualquier red social y pueden encontrarme como Luca Maraschi, estoy emocionado de conectarme con ustedes. Pero comencemos con nuestro viaje. Mi abuela Piera siempre me decía que la vida es como una rueda giratoria y en ese momento, créanme, no lo entendía. Pero hoy quiero mostrarles y demostrarles que ella tenía razón. Comencemos.

Como toda historia que hemos escuchado en los últimos años, especialmente en Node, es que una vez hubo un monolito y ahora microservicios. Bueno, hoy, comencemos desde donde dejamos la historia. Hoy tenemos microservicios, pero ¿hacia dónde nos lleva el futuro? En esta charla, intentaré despertar su curiosidad sobre un nuevo concepto, pero especialmente mostrarles un adelanto de algunos de los materiales que ya hemos construido en Platformatic sobre este tema y conectarnos directamente para hacer cualquier pregunta.

Pero comencemos desde donde terminó y se dejó sobre los microservicios. Entonces, los microservicios, unen los límites lógicos con los límites físicos. Y ¿qué significa eso? Básicamente, no solo son una transformación tecnológica, sino también una transformación cultural y una transformación de personas, como decimos en cualquier organización. Siempre que pensamos en Microsoft, pensamos en todos estos hexágonos, ¿verdad? Siendo compuestos entre sí y luego siendo estandarizados en APIs. Porque estamos en la era de las APIs modernas y de la economía de las APIs, como dicen mis amigos de Kong. Y estoy de acuerdo con ellos.

Estamos en medio de la economía de las APIs. Y por un lado, hemos sido extremadamente capaces y motivados por cambiar el mundo de las APIs. Sin embargo, nos hemos estancado un poco en cómo construimos la lógica que respalda todas estas APIs. El núcleo del negocio de todos. Y así, los microservicios por un lado ofrecieron un impulso de rendimiento increíble, ¿verdad? Porque podemos escalar de forma independiente, pensamos en partículas micro de la lógica empresarial de una manera mucho más aislada, ¿verdad? Se volvieron más tolerantes a fallos porque no tenemos estas transacciones enormes que están unificadas en un solo conjunto de lógica empresarial, sino que se distribuyen en varios nodos. Y si un nodo se cae, podemos restaurarlo porque nos dijeron que deben ser sin estado. Así que comenzamos a crear estos límites de abstracción. Creamos esta fachada que nos permite intercambiar las diferentes implementaciones del servicio sin interrumpir a los clientes, ¿verdad? Y esto suena extremadamente emocionante y positivo. Sin embargo, en toda buena historia hay un sin embargo, ya saben, ¿verdad? Esto realmente afectó el rendimiento porque ahora tienes muchos servicios que imaginemos en Kubernetes o en cualquier otro sistema, básicamente se distribuyen en varios nodos y estos nodos necesitan comunicarse. Y cómo se comunican se llama red, ¿verdad? Por otro lado, la corrección se volvió mucho más difícil. Es un sistema distribuido. Es muy difícil gestionar un estado consistente en todos estos servicios diferentes. Y especialmente cuando digo estado, me refiero a estado lógico y estado físico. ¿Está todo igualmente distribuido? ¿Todo se está desarrollando de la misma manera? Y guarden este concepto para más adelante.

Se vuelven extremadamente difíciles de gestionar porque acabamos de decirlo, ¿verdad? Son como un sistema distribuido. Todos se desarrollan, implementan y gestionan de forma independiente, ¿verdad? Esto causa un gran bloqueo en las APIs, ¿verdad? Porque como dijimos antes, las APIs son la agregación de todos estos microservicios. Al final del día, esto impacta directamente a los desarrolladores. Ralentiza el ciclo de desarrollo y añade frustraciones porque hay más barreras que superar antes de que podamos llevar nuestros microservicios a producción.

Pero diría aún más, acoplamos nuestra lógica de aplicación, nuestras aplicaciones, a la estructura de red con una taxonomía de red, y esto se vuelve extremadamente difícil de desenredar. También complica mucho la versión porque los binarios de la aplicación se lanzan de forma independiente. Cada microservicio tiene su propio ciclo de vida. ¿Alguna vez te has preguntado qué versión debería tener este servicio? Esa es una muy buena pregunta. Pero hubo un momento de revelación. Hubo un momento en el que dijimos, hmm, vimos la luz. Y ese fue el momento del monolito componible.

Entonces, ¿cuál es la solución a todos estos problemas? Bueno, probablemente sea mirar hacia atrás y ver dónde comenzamos, ¿verdad? Todos comenzamos criticando y diciendo que el monolito representaba a Java y .NET, ¿verdad? Y al final, si todos recuerdan, esas tecnologías se implementaban como un paquete que se transfería mediante SFTP a un servidor de aplicaciones. Y funcionaba, ¿verdad? Pero lo que realmente no encajaba era el modelo de desarrollo, cómo se creaba este paquete. Este no es un concepto nuevo, ¿verdad? Y no soy el primero. No estamos locos al hablar de este monolito componible. Pero Google escribió un documento técnico diciendo que el futuro del desarrollo moderno en la nube está con un monolito componible. Este es el documento técnico. Recomiendo encarecidamente que lo descarguen y lo lean. Es un documento fenomenal. Personalmente, creo que ofrece una visión fenomenal de las formas modernas de interpretar el desarrollo de software.

Permítanme elegir tres puntos importantes de toda esta historia. Bueno, el primero es básicamente escribir aplicaciones monolíticas que estén modularizadas en componentes. Así que aprendemos el concepto de componentes, ¿verdad? Desde el frontend, si piensas en React, y esto fue fenomenal porque cada componente tiene su propia lógica, su propio alcance. Pero todos se agruparon en un solo despliegue. Y eso fue el sitio web, ¿verdad?

El otro punto es aprovechar un runtime que básicamente pueda asignar dinámica y automáticamente componentes lógicos a recursos físicos, lo que significa básicamente tomar este monolito, este monolito componible basado en componentes, y asignar recursos a cada componente para que estos componentes puedan ejecutarse como si fueran independientes. Pero implementar aplicaciones de forma atómica, sin despliegues independientes. Un solo despliegue monolítico, un gran paquete. Porque esto realmente conducirá a una forma mucho más fácil de versionar y consumir esta versión. Creo que esto abre muchas, muchas puertas, ¿verdad? Y si piensas en Node, en el ecosistema Node, ya existen frameworks.

Y no menciono Fastify solo porque me encante Fastify, sino porque creo que representa de manera elegante la solución, probablemente la única solución, para esta nueva forma de desarrollar aplicaciones. No se puede hacer con Express. Se puede hacer, pero es feo. Y muchos otros frameworks lo intentaron, pero Fastify logró unir todos estos conceptos de manera elegante. En Platformatic, amamos claramente Fastify, y dijimos que necesitábamos construir un tiempo de ejecución que hiciera exactamente lo que Google sugería, tomar todos estos componentes independientes y ejecutarlos como si fueran una sola pieza. Pero digamos que lo intentamos varias veces, solo para usar una declaración provocativa. Y así construimos el tiempo de ejecución de Platformatic y ya está disponible como código abierto desde hace seis meses. Así que por favor, úsalo.

Y lo que estamos tratando de resolver con el tiempo de ejecución de Platformatic es la complejidad de ejecutar aplicaciones modulares y monolíticas, donde cada módulo representa una única característica desplegada bajo un solo paquete, desarrollada de forma independiente por muchas personas, como pueden ser 10 equipos que desarrollan esta cosa, pero al final va a un solo contenedor. Y el tiempo de ejecución de Platformatic te ofrece la interfaz HTTP y el punto de entrada a todo esto, además de la gestión de ejecutar todos estos componentes como hilos independientes. Así que cuando damos la bienvenida a los monolitos modulares y vemos cómo podemos hacerlo en Node, mencioné hace un minuto a Fastify. Fastify fue diseñado en torno a este concepto. Complementos, rutas, puedes agrupar tu complemento que contiene rutas y luego puedes tomar una sola aplicación Fastify que utiliza todos estos complementos independientes. Y la determinación en nuestro trato, por ejemplo, es capaz de cargar de manera determinista todos estos complementos, lo que te permite crear este monolito componible muy bien organizado y estructurado.

Y como mencioné, Fastify es nuestro marco HTTP, tienes todos estos complementos que pueden ser paquetes npm o simplemente archivos individuales en un solo proyecto, realmente no importa. Pero esta es una especie de vista macroscópica de cómo puedes lograrlo. Así que la solución ya está ahí. En verdad, hay que decir que en Platformatic llevamos este enfoque al siguiente paso lógico, te recomiendo encarecidamente que vayas y compruebes Platformatic, muy fácil de hacer, npm i platformatic y tendrás todo listo para usar en tu

Bueno, muchos podrían decir que usen TypeScript, pero esa no es realmente la respuesta en mi propia opinión. Así que si miras el RFC 9110, básicamente relacionado con HTTP, hay una pieza muy interesante que dice que la diferencia entre la división semántica entre los protocolos HTTP 1 y 2 se hace para hacer que el enlace sea débilmente acoplado y solo un detalle de implementación. Y eso es realmente interesante porque aquí voy a referenciar a mi querido amigo y cofundador Matteo. Él tuvo esta brillante charla y va a responder a la pregunta de cómo logramos ese rendimiento increíble entre todos estos módulos. Y habló en NodeConf EU el año pasado sobre HTTP sin red y responde a ese tipo de rompecabezas del RFC que acabo de publicar en la diapositiva anterior. Recomiendo encarecidamente ver este video. Y lo que va a revelar básicamente es el secreto detrás de nuestro tiempo de ejecución de Platformatic. ¿Cómo hacemos que todos estos módulos se comuniquen entre sí? Bueno, estos módulos en realidad están débilmente acoplados entre sí y se comunican a través de HTTP pero sin utilizar ninguna red.