Le Serverless Computing VS Containers | Comment choisir ?

Le Serverless Computing et les conteneurs sont deux architectures qui réduisent la surcharge des applications web hébergées dans le Cloud, mais elles diffèrent sur plusieurs points importants. Les conteneurs sont plus légers que les machines virtuelles, mais les déploiements sans serveur sont encore plus légers et plus facilement extensibles que les architectures basées sur des conteneurs.

Le Serverless Computing par rapport aux conteneurs

Le Serverless Computing et les conteneurs permettent aux développeurs de créer des applications avec beaucoup moins de frais généraux et plus de souplesse que les applications hébergées sur des serveurs traditionnels ou des machines virtuelles. Le style d’architecture qu’un développeur doit utiliser dépend des besoins de l’application, mais les applications sans serveur sont plus évolutives et généralement plus rentables.

Que sont les conteneurs ?

Un conteneur « contient » à la fois une application et tous les éléments dont l’application a besoin pour fonctionner correctement, y compris les bibliothèques système, les paramètres système et d’autres dépendances. Comme un mélange de crêpes « il suffit d’ajouter de l’eau », les conteneurs n’ont besoin que d’une seule chose – être hébergés et fonctionner – pour remplir leur fonction.

Tout type d’application peut être exécuté dans un conteneur. Une application conteneurisée fonctionnera de la même manière quel que soit l’endroit où elle est hébergée. Les conteneurs peuvent facilement être déplacés et déployés partout où cela est nécessaire, un peu comme les conteneurs d’expédition physiques, qui sont de taille standard et peuvent donc être expédiés partout par divers moyens de transport (bateaux, camions, trains, etc.), quel que soit leur contenu.

Architecture des conteneurs

En termes techniques, les conteneurs sont un moyen de partitionner une machine, ou un serveur, en environnements d’espace utilisateur distincts, de telle sorte que chaque environnement n’exécute qu’une seule application et n’interagit avec aucune autre section partitionnée de la machine. Chaque conteneur partage le noyau de la machine avec d’autres conteneurs (le noyau est la base du système d’exploitation et il interagit avec le matériel de l’ordinateur), mais il fonctionne comme s’il était le seul système sur la machine.

Conteneurs et machines virtuelles

Une machine virtuelle est un logiciel qui imite un système informatique complet. Elle est isolée du reste de la machine qui l’héberge et se comporte comme si elle était le seul système d’exploitation sur elle, y compris en ayant son propre noyau. Les machines virtuelles sont un autre moyen courant d’héberger plusieurs environnements sur un seul serveur, mais elles utilisent beaucoup plus de puissance de traitement que les conteneurs.

Qu’est-ce que le Serverless Computing ?

Les applications sans serveur sont divisées en fonctions et hébergées par un fournisseur tiers qui ne facture le développeur d’applications qu’en fonction de la durée d’exécution de chaque fonction. Pour en savoir plus sur l’informatique sans serveur, voir Qu’est-ce que l’informatique sans serveur ?

Quelles sont les principales différences entre l’informatique sans serveur et les conteneurs ?

Machines physiques
L’informatique « sans serveur » fonctionne en fait sur des serveurs, mais c’est au vendeur sans serveur qu’il appartient de fournir l’espace serveur nécessaire à l’application ; aucune machine spécifique n’est affectée à une fonction ou à une application donnée. D’autre part, chaque conteneur vit sur une machine à la fois et utilise le système d’exploitation de cette machine, bien qu’il puisse être facilement déplacé vers une autre machine si on le souhaite.

Évolutivité
Dans une architecture basée sur des conteneurs, le nombre de conteneurs déployés est déterminé à l’avance par le développeur. En revanche, dans une architecture sans serveur, le backend s’adapte automatiquement et de manière inhérente à la demande.

Pour reprendre la métaphore du conteneur maritime, une compagnie maritime pourrait essayer de prévoir une augmentation de la demande pour un certain produit et expédier plus de conteneurs vers la destination pour répondre à cette demande, mais elle ne pourrait pas claquer des doigts et produire plus de conteneurs remplis de marchandises si la demande devait dépasser les attentes.

L’architecture sans serveur est un moyen de faire exactement cela. En ce qui concerne la puissance de calcul, l’informatique sans serveur est comme l’approvisionnement en eau dans une maison moderne : en ouvrant le robinet, les consommateurs peuvent acquérir et utiliser autant d’eau qu’ils en ont besoin à tout moment, et ils ne paient que ce qu’ils utilisent. C’est bien plus modulable que d’essayer d’acheter de l’eau un seau ou un conteneur d’expédition à la fois.

Coût
Les conteneurs fonctionnent en permanence, et les fournisseurs de Cloud doivent donc facturer l’espace serveur même si personne n’utilise l’application à ce moment-là.

Il n’y a pas de dépenses continues dans une architecture sans serveur car le code de l’application ne fonctionne pas à moins d’être appelé. Les développeurs ne sont facturés que pour la capacité du serveur que leur application utilise effectivement.

Maintenance
Les conteneurs sont hébergés dans le Cloud, mais les fournisseurs de Cloud ne les mettent pas à jour ou ne les entretiennent pas. Les développeurs doivent gérer et mettre à jour chaque conteneur qu’ils déploient.

Du point de vue d’un développeur, une architecture sans serveur n’a pas de backend à gérer. Le fournisseur s’occupe de la gestion et des mises à jour logicielles pour les serveurs qui exécutent le code.

Moment du déploiement

La mise en place initiale des conteneurs est plus longue que celle des fonctions sans serveur, car il est nécessaire de configurer les paramètres du système, les bibliothèques, etc. Une fois configurés, les conteneurs ne prennent que quelques secondes à se déployer. Mais comme les fonctions sans serveur sont plus petites que les micro-services des conteneurs et ne sont pas associées à des dépendances du système, leur déploiement ne prend que quelques millisecondes. Les applications sans serveur peuvent être activées dès que le code est téléchargé.

Les conteneurs sans serveur et les conteneurs se déploient à grande vitesse

Il est difficile de tester des applications web sans serveur, car l’environnement dorsal est difficile à reproduire sur un environnement local. En revanche, les conteneurs fonctionnent de la même manière quel que soit l’endroit où ils sont déployés, ce qui rend relativement simple le test d’une application basée sur un conteneur avant de la déployer en production.

En quoi l’informatique sans serveur et les conteneurs sont-ils similaires ?
Tous deux sont basés sur le Cloud et réduisent considérablement les coûts d’infrastructure, l’informatique sans serveur étant plus importante que les conteneurs. Dans les deux types d’architecture, les applications sont décomposées et déployées en tant que composants plus petits. Dans une architecture basée sur des conteneurs, chaque conteneur fera fonctionner un micro-service.

Que sont les micro-services ?

Les micro-services sont des segments d’une application. Chaque micro-service exécute un service, et plusieurs micro-services intégrés se combinent pour constituer l’application. Bien que le nom semble impliquer que les micro-services sont minuscules, ils ne doivent pas l’être.

L’un des avantages de la construction d’une application comme un ensemble de micro-services est que les développeurs peuvent mettre à jour un micro-service à la fois au lieu de mettre à jour l’application entière lorsqu’ils ont besoin d’apporter des modifications. Construire une application comme un ensemble de fonctions, comme dans une architecture sans serveur, offre le même avantage mais à un niveau plus granulaire.

Comment les développeurs doivent-ils choisir entre une architecture sans serveur et des conteneurs ?

Les développeurs qui choisissent une architecture sans serveur pourront lancer et itérer de nouvelles applications rapidement, sans avoir à se soucier de savoir si l’application peut ou non évoluer. En outre, si une application ne connaît pas un trafic ou une utilisation constante, l’informatique sans serveur sera plus rentable que les conteneurs, car le code n’a pas besoin d’être exécuté en permanence.

Les conteneurs donnent aux développeurs un plus grand contrôle sur l’environnement dans lequel l’application s’exécute (bien que cela implique également une plus grande maintenance) et sur les langues et bibliothèques utilisées. De ce fait, les conteneurs sont extrêmement utiles pour la migration d’anciennes applications vers le Cloud, car il est possible de reproduire plus fidèlement l’environnement d’exécution original de l’application.

Enfin, il est possible d’utiliser une architecture hybride, avec certaines fonctions sans serveur et d’autres déployées dans des conteneurs. Par exemple, si une fonction d’application nécessite plus de mémoire que celle allouée par le fournisseur sans serveur, si une fonction est trop importante ou si certaines fonctions, mais pas d’autres, doivent fonctionner longtemps, une architecture hybride permet aux développeurs de récolter les avantages du sans serveur tout en utilisant des conteneurs pour les fonctions que le sans serveur ne peut pas prendre en charge.