La Evolución de la Implementación de Node en Servidores y Plataformas

Hola, amigos, bienvenidos a mi charla. El título de hoy es la evolución de implementar Node en servidores y plataformas. Mi nombre es Shedrak Akintayo. Soy un ingeniero de relaciones con desarrolladores en Platform Message. También me dedico a la escritura técnica y me gusta construir comunidades, lo cual he hecho con Facebook Devs, Open Source Africa y DevRel Africa. Así que el índice para hoy es hablar sobre cómo se ha implementado Node a lo largo de los años en diversas formas. Cómo se implementa en un servidor en un garaje, cómo se ha implementado en servidores monolíticos, cómo se ha implementado en una plataforma como servicio y cómo se ha implementado en contenedores. Luego haremos un resumen rápido de cómo se ha implementado en sin servidor y en funciones en la nube o función como servicio. Así que empecemos. Lo primero que quiero destacar es que la implementación no es fácil. Créeme, cualquiera que haya pasado tiempo trabajando como ingeniero de DevOps implementando Node.js a lo largo de los años, no es tan fácil como parece. Pero gracias a la evolución de Node.js, la implementación se vuelve aún más fácil. Así que gracias a la evolución de Node.js. Lo primero de lo que hablaremos es de Node implementado en un servidor físico en un garaje. Básicamente, construir tu propio servidor. Antes de todo, Node solía implementarse en un servidor en un garaje en realidad. Los beneficios básicamente son que tienes un servidor Node dedicado solo para tu aplicación. Tienes mucho metal desnudo para tu aplicación. Puedes configurar tu entorno de Node. Hasta cierto punto, es seguro porque manejas todo lo relacionado con la seguridad, lo cual es realmente bueno porque no dependes de ningún proveedor de servicios. Cuando un proveedor está caído, no tienes que preocuparte por ello. Así es como se implementaba básicamente. Node se puede implementar en un servidor físico en un garaje.

A continuación, los inconvenientes. Se vuelve demasiado caro de configurar. Ya sabes, el personal, los gastos técnicos para configurarlo. Otro inconveniente es que se vuelve muy estresante de gestionar porque estás haciendo todo el trabajo tú mismo. Los ingenieros tienen que hacer todo el trabajo ellos mismos. Así que este es otro problema. Y es más difícil de optimizar porque la mayor parte del trabajo la realizas tú mismo.

tú y tu equipo, la mayor parte del tiempo. Así que manejar la optimización por ti mismo se vuelve muy, muy agotador. Entonces, los requisitos en ese momento, cuando se implementa en un metal desnudo, aunque todavía se implementa así ahora, no tanto como antes. Necesitas las primeras versiones de Node. Necesitas muchas GPUs, necesitas RAM, necesitas CPUs, básicamente, para implementar Node en, para ser el servidor Cisca para ustedes, para implementar Node en él. Entonces, la siguiente parada es implementar Node.js en un servidor monolítico. Básicamente, un servidor monolítico consiste en todas las partes de una aplicación implementadas en un solo servidor, desde el backend hasta la parte estática de la aplicación. Los beneficios de esta forma particular de implementar Node a lo largo de los años es que todo el camino está en un servidor centralizado, y siempre es una excelente opción implementar Node como un monolito, para que puedas tener todas tus aplicaciones en un solo servidor, lo cual es realmente genial, porque puedes ver todo lo que necesitas ver, puedes ver todas tus aplicaciones acopladas juntas. Los inconvenientes son que a medida que la aplicación crece, se vuelve difícil de actualizar, y los requisitos de memoria aumentan con el tiempo. Para los requisitos, necesitas un servidor de alojamiento y NodeJS 12 en adelante. La siguiente parada es NodeJS implementado en una PaaS. Entonces PaaS, Plataforma como Servicio, también conocido como PaaS, implica proporcionar un amplio conjunto de infraestructura de aplicaciones basada en la nube y recursos de middleware a través de la nube. Un ejemplo de PaaS que es posible que hayas encontrado es Platform SH. Platform SH es bastante diferente, porque puedes implementar una PaaS en contenedores, luego Heroku, Vercel, Netlify, etc. El beneficio es que NodeJS se puede implementar más rápido, luego también puedes agregar fácilmente servicios de datos adicionales a tu aplicación Node, luego los inconvenientes son que puede ser muy, muy costoso a gran escala, y el bloqueo de proveedores también es otro problema. Los requisitos para implementar Node en una PaaS dependen de lo que especifique el proveedor de PaaS en general. A continuación, se implementa Node en un contenedor. Ahora, este es actualmente el método más utilizado para implementar Node en general. Un contenedor es básicamente un software liviano que proporciona un entorno de ejecución para tu aplicación. Entonces platform.sh utiliza PaaS, pero puedes implementarlo en un contenedor. Básicamente es una PaaS que puedes usar para implementarlo en contenedores en Kubernetes, y también en Docker. Los beneficios, hace que tu aplicación Node sea liviana y eficiente en recursos. Es fácil administrar y controlar tu infraestructura Node. Agregar servicios de datos externos a tu aplicación Node es más fácil. Ahora los inconvenientes, puede ser muy costoso como antes, y también tienes problemas con el bloqueo de proveedores. Cuando un proveedor tiene problemas, entonces se convierte en un problema. Los requisitos para implementar Node en una PaaS dependen del proveedor de contenedores. Eso es la PaaS, el proveedor de contenedores, quien proporciona los servicios de contenedor. También puedes controlar la versión de Node tamaño de memoria y disco de tu aplicación.

Ahora, sin servidor es de lo que vamos a hablar a continuación. Sin servidor básicamente implica

implementar tu aplicación sin preocuparte por los servidores. Los servidores todavía están presentes, pero en una base de PaaS. También utiliza funciones como servicio, que es una forma serverless de ejecutar piezas modulares de código en el borde. Un ejemplo es el que básicamente hemos visto, AWS Lambda, que es uno de los proveedores más importantes de serverless, y serverless.com. Otra ventaja, una ventaja de serverless, son los costos más bajos. Puedes construir más rápido. Ir al mercado se vuelve muy, muy rápido. El código backend es simple porque en su mayoría está en fragmentos modulares. Básicamente utiliza programación modular, que son funciones, por lo que cada parte de tu backend se convierte en una función.

Otra parte son las desventajas de serverless, básicamente, el bloqueo de proveedores, que es uno de los principales problemas de serverless, y no es adecuado para tareas a largo plazo. En cuanto a la escalabilidad para una tarea muy, muy a largo plazo, serverless no funciona realmente bien porque se convierte en un problema, básicamente, y se vuelve muy costoso, a pesar de que lo venden como algo que proporciona un costo más bajo.

Así que básicamente eso es el final de mi charla. Espero que hayas podido entender cómo se ha implementado Node.js a lo largo de los años, desde el punto A hasta el punto B, desde on-premise hasta contenedores, desde monolitos hasta serverless. Mi nombre es Chedrak Akintayo. Soy Ingeniero de Relaciones con Desarrolladores en Platform Message. Gracias.