Diferencias entre servidor, serverless y contenedor — la capa de servidor de aplicaciones

Este artículo trata las tres formas de ejecutar la capa de servidor de aplicaciones.

Son el modo siempre activo, que mantiene arrancado un servidor; serverless, que se ejecuta solo cuando llega una solicitud; y los contenedores.

La diferencia está en el tiempo que el programa que hace el trabajo está en marcha.

Como ese tiempo cambia, también cambian la forma de aumentar la capacidad cuando llegan más solicitudes y lo que tienes que preparar tú.

El servidor siempre activo queda arrancado y espera las solicitudes

No sabes cuándo llegará una solicitud, así que arrancas server.js antes y lo dejas esperando como proceso (process: un programa que se ha arrancado y está en marcha).

Dejar ese proceso ahí en lugar de terminarlo es lo que se llama siempre activo (always-on: mantener el programa arrancado para poder aceptar una solicitud en cualquier momento).

Server listening on port 3000
Press Ctrl+C to stop

La primera línea muestra que está escuchando solicitudes en el puerto que elegiste.

Como dice la segunda línea, el proceso no termina hasta que haces algo para detenerlo.

Lo que preparas tú no es solo el server.js del interior.

También preparas la computadora que mantienes en marcha, el sistema operativo que corre en ella y node.

Esta es la gran diferencia con serverless, que viene a continuación.

Dentro del marco está la única máquina que preparas y mantienes en marcha.

El proceso no termina mientras no llegan solicitudes: espera con el puerto abierto.

Siempre activo significa en marcha hasta que lo detienes

Un servidor siempre activo es uno que arrancas de antemano y dejas esperando a que lleguen solicitudes.

Lo que lo arranca es node server.js, el proceso no termina hasta que haces algo para detenerlo, y la computadora que mantienes en marcha, el sistema operativo y node los preparas tú.

Serverless ejecuta el procesamiento solo cuando llega una solicitud

En serverless (serverless: el modo en el que el programa que hace el trabajo se ejecuta solo cuando llega una solicitud y se detiene cuando el trabajo termina) no eres tú quien mantiene en marcha un proceso a la espera.

Lo que registras es un solo archivo, como handler.js, y a esa unidad de registro se le llama «función».

Lo único que tocas es el handler.js del interior.

Los marcos de fuera los prepara el proveedor, que también aplica las actualizaciones del sistema operativo y de node.

Quién prepara qué se trata en el artículo sobre on-premises, hosting compartido y la nube.

Mientras no llega ninguna solicitud, handler.js no está en marcha.

El entorno de ejecución se prepara para cada solicitud y se detiene cuando termina de responder.

Esta es la diferencia con el modo siempre activo, que sigue en marcha hasta que lo detienes.

Serverless se ejecuta solo cuando lo llaman

Serverless es el modo que arranca el procesamiento después de que llega una solicitud y lo detiene cuando termina de responder.

Lo único que pones tú es handler.js, y el entorno de ejecución que lo ejecuta lo prepara el proveedor en cada solicitud.

La forma de aumentar la capacidad cuando crecen las solicitudes simultáneas es distinta

El número de solicitudes que llegan a la vez cambia según la hora del día.

Ajustarse a eso es el escalado (scaling: aumentar o reducir el número de elementos que hacen el trabajo según el volumen de solicitudes).

Vamos a ver primero el caso de tres solicitudes que llegan a la vez a serverless.

Hasta el número que el proveedor permite ejecutar a la vez, ninguna solicitud queda esperando.

Tampoco haces tú nada para aumentar la capacidad.

Un servidor siempre activo necesita cubrir las mismas funciones, pero cambia quién las cubre.

Lo que cambia es si decides tú aumentar la capacidad o lo dejas en manos del sistema del proveedor.

Una vez que el número ha crecido, las solicitudes de una misma persona no siempre llegan al mismo sitio, así que se necesita que sea sin estado (stateless: que una ejecución del procesamiento no guarde valores recordados de la ejecución anterior).

Que la segunda solicitud pueda leer un valor que recordó la primera depende de dónde pusiste ese valor.

El valor que también usas en la siguiente solicitud se guarda en la capa de base de datos y se lee desde ahí.

En un servidor siempre activo pasa lo mismo: si añades procesos, el valor no queda en los otros procesos.

Cómo se aumenta la capacidad y dónde se guardan los valores

Cuando crecen las solicitudes simultáneas, en siempre activo aumentas tú el número y en serverless lo aumenta el sistema del proveedor.

Una vez que el número ha crecido, no siempre responde el mismo a las dos solicitudes de una misma persona, así que el valor que quieras volver a usar va a la capa de base de datos y no a la memoria local.

Los contenedores se ejecutan sobre un solo sistema operativo, y eliges entre los tres según si necesitas estar siempre activo

La tercera forma, el contenedor (container: un formato que empaqueta la app, su entorno de ejecución y los archivos que necesita, y la ejecuta en otra computadora con la misma configuración), está en marcha el mismo tiempo que un servidor siempre activo.

Lo que cambia es que el entorno de ejecución no se instala en la computadora, sino que se empaqueta junto con la app.

Hay un solo sistema operativo, y cada contenedor se ejecuta encima como un único proceso.

Los entornos de ejecución están por separado dentro de cada contenedor, así que lo que use el contenedor de al lado no le afecta.

Lo que se consume del equipo para ejecutar algo, como la CPU y la memoria, son los recursos (resource).

Arriba se ejecutan tres sistemas operativos, mientras que abajo se comparte uno solo, así que en el mismo equipo caben más apps.

Puedes ejecutar más con el mismo número de máquinas y cuesta menos mantenerlas en marcha.

Como no se arranca un sistema operativo nuevo, también es más corto el tiempo hasta que empieza a funcionar.

Un solo sistema operativo admite un solo node, pero con contenedores puedes tener los dos a la vez con nodes distintos.

Como el entorno de ejecución está separado por app, si subes la versión de uno el otro sigue funcionando.

El conjunto de archivos empaquetados es la imagen de contenedor (container image: la app, el entorno de ejecución y los archivos necesarios empaquetados en uno), y el software más conocido para crearla y ejecutarla es Docker.

Quien la ejecuta solo recibe esta imagen y la arranca.

Aunque cambie el lugar donde la ejecutas, lo que se arranca es la misma imagen.

No hace falta volver a instalar el entorno de ejecución en el servidor público, así que puedes publicar la misma configuración que funcionó en tu equipo.

El punto que separa la elección es si tiene que estar en marcha cuando no hay solicitudes.

El otro punto de separación es cuánto cabe en un solo equipo.

En las dos líneas de arriba, el proceso sigue en marcha incluso cuando no hay solicitudes.

Esas dos se separan según si el entorno de ejecución se instala en la computadora o se empaqueta junto con la app.

Las dos formas siempre activas siguen en marcha también durante el tiempo en que no llegan solicitudes.

En serverless solo se cuentan el tiempo que estuvo en marcha y las veces que se le llamó.

Mientras las solicitudes son escasas, esa diferencia se nota directamente.

Elige por el tiempo que está en marcha

La primera separación es si tiene que estar en marcha cuando no hay solicitudes.

Si no hace falta, serverless; si hace falta, un servidor siempre activo o un contenedor.

Los contenedores comparten un solo sistema operativo entre apps, así que caben muchos en el mismo equipo y baja el costo de mantenerlos en marcha.

También eliges un contenedor cuando quieres que la configuración de tu equipo y la del servidor publicado coincidan.