Serveur, serverless et conteneur — la couche serveur d'application

Cet article porte sur les trois formes qui font tourner la couche serveur d'application.

Le mode toujours actif, qui laisse une machine démarrée ; le serverless, qui ne tourne qu'à l'arrivée d'une requête ; et le conteneur.

La différence, c'est la durée pendant laquelle le programme de traitement tourne.

Comme cette durée diffère, la façon d'ajouter de la capacité quand les requêtes augmentent et ce que tu dois préparer toi-même changent aussi.

Le serveur toujours actif reste démarré et attend les requêtes

Tu ne sais jamais quand une requête va arriver : tu lances donc server.js d'abord et tu le laisses attendre sous forme de processus (process ; un programme lancé et en cours d'exécution).

Laisser ce processus en place au lieu de le terminer, c'est le mode toujours actif (always-on ; garder le programme démarré pour pouvoir accepter une requête à tout moment).

Server listening on port 3000
Press Ctrl+C to stop

La première ligne montre qu'il écoute les requêtes sur le port choisi.

Comme l'indique la deuxième ligne, le processus ne se termine pas tant que tu ne l'arrêtes pas.

Le server.js le plus intérieur n'est pas la seule chose que tu prépares toi-même.

Tu prépares aussi la machine que tu gardes en marche, l'OS qui tourne dessus et node.

C'est là la grande différence avec le serverless, vu juste après.

À l'intérieur du cadre se trouve la machine unique que tu prépares et gardes en marche.

Le processus ne se termine pas même quand aucune requête n'arrive : il attend, le port ouvert.

Le mode toujours actif reste en marche jusqu'à ce que tu l'arrêtes

Un serveur toujours actif, c'est un serveur que tu lances à l'avance et que tu laisses attendre les requêtes.

C'est node server.js qui le démarre, le processus ne se termine pas tant que tu ne l'arrêtes pas, et c'est toi qui prépares la machine gardée en marche, l'OS et node.

Le serverless ne fait tourner le traitement qu'à l'arrivée d'une requête

Avec le serverless (serverless ; forme dans laquelle le programme de traitement ne tourne qu'à l'arrivée d'une requête et s'arrête une fois le traitement terminé), tu ne fais pas tourner toi-même de processus en écoute.

Ce que tu enregistres est un seul fichier, comme handler.js, et l'unité d'enregistrement s'appelle une « fonction ».

La seule chose que tu touches est le handler.js le plus intérieur.

Les cadres extérieurs sont préparés par le fournisseur, qui applique aussi les mises à jour de l'OS et de node.

La question de savoir qui prépare quoi est traitée dans l'article sur le sur site, l'hébergement mutualisé et le cloud.

Tant qu'aucune requête n'est arrivée, handler.js ne tourne pas.

Un environnement d'exécution est préparé à chaque requête et s'arrête une fois la réponse renvoyée.

C'est là la différence avec le mode toujours actif, qui reste en marche jusqu'à ce que tu l'arrêtes.

Le serverless ne tourne que lorsqu'il est appelé

Le serverless, c'est la forme qui lance le traitement après l'arrivée d'une requête et l'arrête une fois la réponse renvoyée.

La seule chose que tu déposes est handler.js, et le fournisseur prépare à chaque requête l'environnement d'exécution qui le fait tourner.

La façon d'ajouter de la capacité change quand les requêtes simultanées augmentent

Le nombre de requêtes qui arrivent en même temps varie selon le moment de la journée.

S'y ajuster, c'est la mise à l'échelle (scaling ; augmenter ou diminuer le nombre d'éléments qui traitent, en fonction du volume de requêtes).

Commence par le cas où trois requêtes arrivent en même temps sur du serverless.

Jusqu'au nombre d'exécutions simultanées fixé par le fournisseur, aucune requête n'attend.

Tu ne fais rien non plus pour augmenter la capacité.

Un serveur toujours actif a besoin des mêmes rôles, mais ce ne sont pas les mêmes acteurs qui les tiennent.

Ce qui change, c'est de décider toi-même d'ajouter de la capacité ou d'en laisser le soin au système du fournisseur.

Une fois le nombre augmenté, les requêtes d'une même personne n'atteignent pas toujours le même élément : il faut donc que le traitement soit sans état (stateless ; un traitement ne conserve aucune valeur mémorisée par le traitement précédent).

Que la deuxième requête puisse lire une valeur mémorisée par la première dépend de l'endroit où tu as mis cette valeur.

Une valeur que tu utilises aussi à la requête suivante s'enregistre dans la couche base de données et se relit de là.

C'est pareil sur un serveur toujours actif : dès que tu ajoutes des processus, la valeur ne subsiste pas dans les autres.

Comment la capacité s'ajoute, et où les valeurs se conservent

Quand les requêtes simultanées augmentent, en mode toujours actif tu ajoutes la capacité toi-même, et en serverless c'est le système du fournisseur qui le fait.

Une fois le nombre augmenté, ce n'est pas toujours le même élément qui répond aux deux requêtes d'une même personne : une valeur que tu veux réutiliser va donc dans la couche base de données, et non en mémoire locale.

Le conteneur tourne sur un seul OS, et tu choisis parmi les trois selon ton besoin de toujours actif

La troisième forme, le conteneur (container ; format qui regroupe l'app, son environnement d'exécution et les fichiers nécessaires en un seul ensemble, pour le faire tourner sur un autre ordinateur avec la même configuration), tourne aussi longtemps qu'un serveur toujours actif.

Ce qui diffère, c'est que l'environnement d'exécution n'est pas installé sur l'ordinateur, mais empaqueté avec l'app.

Il y a un seul OS, et chaque conteneur y tourne comme un unique processus.

Les environnements d'exécution sont séparés à l'intérieur des conteneurs : ce qu'utilise le voisin n'a donc aucun effet.

La part de matériel utilisée pour faire tourner quelque chose, comme le CPU et la mémoire, est une ressource (resource).

Le haut fait tourner trois OS, alors que le bas partage un seul OS : le même matériel peut donc porter plus d'apps.

Tu fais tourner plus de choses sur le même nombre de machines, et le coût pour les garder en marche est plus faible.

Aucun nouvel OS n'est démarré : le temps avant la mise en route est donc plus court aussi.

Un seul OS ne peut contenir qu'un seul node, mais avec des conteneurs tu peux les faire tourner côte à côte avec des node distincts.

L'environnement d'exécution est séparé pour chaque app : monter la version de l'une laisse donc l'autre en marche.

L'ensemble de fichiers regroupé est une image de conteneur (container image ; l'app, l'environnement d'exécution et les fichiers nécessaires regroupés en un seul ensemble), et Docker est le logiciel le plus connu pour en fabriquer et en faire tourner.

Celui qui la fait tourner n'a qu'à recevoir cette image et la démarrer.

Même quand le lieu d'exécution change, ce qui démarre est la même image unique.

Tu n'as pas à réinstaller l'environnement d'exécution sur le serveur public : tu peux donc publier la configuration exacte qui tournait chez toi.

Ce qui départage, au moment de choisir, c'est de savoir s'il doit tourner quand il n'y a aucune requête.

L'autre critère est la quantité que tu peux placer sur une seule machine.

Sur les deux lignes du haut, le processus reste en marche même quand il n'y a aucune requête.

Ces deux-là se séparent selon que l'environnement d'exécution est installé sur l'ordinateur ou regroupé avec l'app.

Les deux formes toujours actives tournent aussi pendant le temps où aucune requête n'arrive.

En serverless, ce qui est compté n'est que le temps d'exécution et le nombre d'appels.

Tant que les requêtes sont clairsemées, cette différence se traduit directement par un écart de coût.

Choisir selon la durée d'exécution

La première séparation est de savoir s'il doit tourner quand il n'y a aucune requête.

Si ce n'est pas nécessaire, le serverless ; si ça l'est, un serveur toujours actif ou un conteneur.

Les conteneurs partagent un seul OS entre les apps : tu peux donc en placer beaucoup sur le même matériel et contenir le coût de leur maintien en marche.

Tu choisis aussi le conteneur quand tu veux que la configuration soit identique chez toi et sur le serveur public.