Qu’est-ce que le Serverless ?
Le Serverless, comme son nom l’indique, fait référence au calcul sans serveur. Vous vous demandez peut-être comment il est possible d’effectuer des calculs sans serveurs ? En réalité, le Serverless ne signifie pas qu’il n’y a littéralement aucun serveur. Il utilise plutôt la technologie pour abstraire la notion de serveur de la logique métier, permettant aux développeurs de se concentrer uniquement sur leurs applications sans se soucier de l’infrastructure sous-jacente.
Comment fonctionne le Serverless ?
Depuis l’avènement du Serverless, de nombreux développeurs le perçoivent comme une technologie novatrice, ce qu’il est indéniablement, vu sa commodité. Cependant, il n’est pas nécessaire de le compliquer ou de s’en effrayer. La logique sous-jacente de l’exécution des applications reste inchangée. Le Serverless emploie simplement des moyens techniques pour nous cacher les complexités impliquées, comme toute autre technologie cloud.
Avant le Serverless, déployer une application web était un processus fastidieux. Pour faire fonctionner notre application, nous devions d’abord construire un environnement d’exécution côté serveur. Cela impliquait d’acheter des machines virtuelles, d’initialiser leurs environnements, d’installer les dépendances nécessaires – en veillant à la cohérence avec notre environnement de développement local autant que possible. Ensuite, pour rendre notre application accessible aux utilisateurs, nous devions acheter un nom de domaine, l’enregistrer avec l’adresse IP de la machine virtuelle, configurer et démarrer Nginx, et enfin, télécharger et lancer le code de l’application.
Contrairement au flux de travail traditionnel, le déploiement Serverless ne nécessite que trois étapes simples, ce qui en fait une abstraction extrême des opérations côté serveur. Essentiellement, toute la chaîne des requêtes de données HTTP des utilisateurs reste qualitativement inchangée ; le Serverless simplifie simplement le modèle global.
Pour expliquer plus en détail, auparavant nous devions construire un environnement d’exécution côté serveur, tandis que les applications FaaS abstraient cette étape en services de fonctions. Nous avions besoin d’équilibrage de charge et de proxy inverse, mais les applications FaaS abstraient cela en déclencheurs de fonctions HTTP. Le téléchargement du code et le démarrage de l’application étaient nécessaires, mais les applications FaaS abstraient cela en code de fonction.
Lorsqu’un utilisateur accède pour la première fois à un déclencheur de fonction HTTP, le déclencheur retient la requête HTTP de l’utilisateur et génère une notification d’événement HTTP Request pour le service de fonctions.
Le service de fonctions vérifie alors la disponibilité d’instances de fonctions inactives. S’il n’y en a pas, il récupère votre code depuis le dépôt de code de fonctions, initialise et lance une instance de fonction, exécute la fonction, passe l’objet HTTP Request en paramètre et exécute la fonction.
De plus, la réponse HTTP de l’exécution de la fonction est renvoyée au déclencheur de fonction, qui transmet ensuite le résultat au client utilisateur en attente.
La différence la plus significative entre le Serverless et les plateformes PaaS d’hébergement d’applications réside dans l’utilisation des ressources, ce qui constitue l’innovation la plus notable du Serverless. Les instances d’applications Serverless peuvent être réduites à zéro, alors que les plateformes PaaS nécessitent au moins un serveur ou un conteneur en fonctionnement en permanence.
Avant la première invocation, l’occupation réelle du serveur pour une fonction est de zéro. Ce n’est que lorsqu’un utilisateur effectue une requête de données HTTP que le service de fonctions est déclenché par l’événement HTTP, démarrant une instance de fonction. Cela signifie que sans requêtes utilisateur, le service de fonctions n’a aucune instance en cours d’exécution et ne consomme aucune ressource serveur. À l’inverse, créer une instance d’application sur une plateforme PaaS prend généralement des dizaines de secondes, et pour garantir la disponibilité du service, au moins un serveur doit exécuter en continu votre instance d’application.
Pour faire une analogie, le Serverless est semblable à une lumière à commande vocale qui s’allume rapidement en présence de quelqu’un et s’éteint quand il n’y a personne. Comparée aux lumières à commande manuelle traditionnelles, la lumière à commande vocale est plus économe en énergie. Cependant, cette capacité d’économie d’énergie dépend de la capacité de la lumière à commande vocale à s’allumer rapidement lorsque nécessaire.
De même, la clé des avantages du Serverless réside dans son temps de démarrage rapide. Comment y parvient-il ?
Pourquoi le Serverless peut-il démarrer si rapidement ?
Le démarrage à froid (cold start) est à l’origine un concept lié aux PC, faisant référence au processus de rechargement de la table BIOS après une mise hors tension - essentiellement un démarrage à partir des pilotes matériels - entraînant des temps de démarrage lents.
Dans les environnements cloud actuels, la mise hors tension de serveurs physiques est presque inconnue. Dans le contexte du Serverless, le démarrage à froid désigne l’ensemble du processus, de l’invocation de la fonction à la disponibilité de l’instance de fonction. Notre objectif ici est de minimiser le temps de démarrage, car des temps de démarrage plus courts entraînent directement une meilleure utilisation des ressources. Les fournisseurs de cloud actuels, en exploitant des optimisations spécifiques aux langages, ont atteint des temps de démarrage à froid moyens compris entre 100 et 700 millisecondes. Grâce à la compilation Just-In-Time du moteur JavaScript de Google, Node.js bénéficie des démarrages à froid les plus rapides.
Il convient de noter qu’un service Serverless peut démarrer à partir de zéro, exécuter une fonction et terminer le processus en 100 millisecondes - une raison clé pour laquelle le Serverless peut se réduire à zéro en toute confiance. Lors de l’ouverture d’une page web, un temps de réponse inférieur à une seconde est généralement considéré comme excellent. Dans ce contexte, un temps de démarrage de 100 millisecondes a un impact négligeable sur les temps de chargement des pages.
De plus, il est raisonnable de supposer que les fournisseurs de cloud continueront d’optimiser leur infrastructure pour des temps de démarrage encore plus rapides, conduisant finalement à une meilleure utilisation des ressources. Par exemple, le téléchargement du code de fonction est une étape longue lors des démarrages à froid. Par conséquent, lors des mises à jour de code, les fournisseurs de cloud initient souvent de manière proactive une planification des ressources pour télécharger et construire des images de conteneurs pour vos instances de fonction. Lorsque la première requête arrive, ils peuvent utiliser ces images mises en cache, contournant ainsi l’étape de téléchargement du code d’un démarrage à froid et lançant le conteneur directement à partir de l’image. Cette technique est connue sous le nom de démarrage à chaud (warm start). Par conséquent, pour les applications sensibles à la latence, nous pouvons utiliser des démarrages à chaud ou des stratégies de préchauffage d’instances pour accélérer ou contourner les temps de démarrage à froid.
Comment le Serverless est-il structuré en couches ?
Lorsque votre instance Serverless s’exécute, elle comprend au moins trois couches : conteneur, environnement d’exécution et code de fonction.
Considérez le conteneur comme le système d’exploitation (OS). L’exécution du code nécessite une interaction avec le matériel, et le conteneur simule le noyau et les informations matérielles, permettant à votre code et à votre environnement d’exécution de fonctionner à l’intérieur. Les informations du conteneur incluent la taille de la mémoire, la version de l’OS, les détails du CPU, les variables d’environnement, etc. Actuellement, les implémentations FaaS peuvent utiliser des conteneurs Docker, des machines virtuelles (VM) ou même des environnements sandbox.
L’environnement d’exécution représente le contexte dans lequel votre fonction s’exécute. Les informations de l’environnement d’exécution incluent le langage de programmation et la version utilisés, comme Node.js v10 ou Python 3.6 ; les objets appelables, comme le SDK aliyun ; et les informations système comme les variables d’environnement.
Quels sont les avantages de cette approche en couches ? La couche conteneur offre une applicabilité plus large, permettant aux fournisseurs de cloud de préchauffer de nombreuses instances de conteneurs, fragmentant ainsi efficacement les ressources des serveurs physiques. Les instances d’environnement d’exécution, avec leur applicabilité plus faible, peuvent être préchauffées en plus petit nombre. Une fois le conteneur et l’environnement d’exécution fixés, le téléchargement et l’exécution du code deviennent simples. Cette architecture en couches permet une optimisation efficace des ressources, rendant possible une exécution rapide et économique de votre code.
Résumé
- La chaîne d’invocation d’une application purement Serverless comprend trois composants principaux : les déclencheurs de fonctions, les services de fonctions et le code de fonction. Ceux-ci remplacent respectivement les opérations traditionnelles côté serveur d’équilibrage de charge et proxy inverse, les serveurs et environnements d’exécution d’applications, et le déploiement du code d’application.
- La différence la plus significative entre le Serverless et les plateformes PaaS traditionnelles d’hébergement d’applications réside dans la capacité des applications Serverless à se réduire à zéro et à démarrer rapidement lors de déclenchements d’événements. Les fonctions Node.js, par exemple, peuvent atteindre un démarrage et une exécution en 100 millisecondes.
- Le Serverless, par conception, sacrifie le contrôle utilisateur et la portée de l’application pour simplifier le modèle de code. Sa structure en couches améliore encore l’utilisation des ressources, ce qui est un contributeur principal à ses temps de démarrage à froid remarquablement courts.
Novita AI lancera un service Serverless pour nos utilisateurs. Rejoignez la liste d’attente dès maintenant et démarrez votre activité avec le calcul sans serveur.
Novita AI est la plateforme cloud tout-en-un qui donne vie à vos ambitions en IA. API intégrées, serverless, instances GPU — les outils rentables dont vous avez besoin. Éliminez l’infrastructure, commencez gratuitement et faites de votre vision IA une réalité.
Lecture recommandée
