Dans le précédent article, nous avons exploré le fonctionnement interne de Serverless. En substance, Serverless exploite une planification en couches et des démarrages à froid rapides, ce qui lui permet de se réduire à zéro lorsqu’aucun événement n’est traité. C’est un peu comme une lampe à détection vocale qui s’allume en présence de quelqu’un et s’éteint automatiquement lorsque la pièce est vide.
Maintenant que vous avez compris les bases, vous vous demandez peut-être quelles sont les applications pratiques de cette technologie impressionnante. Aujourd’hui, nous allons nous pencher sur les cas d’utilisation de Serverless. Cependant, pour comprendre ses applications, il est nécessaire de maîtriser son modèle de processus, un concept aussi crucial que les démarrages à froid.
Le modèle de processus Serverless
Revenons sur le processus de démarrage à froid Serverless vu la dernière fois. Rappelez-vous que le fournisseur cloud gère les phases de préparation du conteneur et de l’environnement d’exécution, nous laissant ainsi nous concentrer uniquement sur l’exécution de la fonction. Dans l’univers Serverless, l’exécution des fonctions est gérée par un « service de fonctions ». Lorsque le déclencheur de fonction signale l’arrivée d’un « événement », le service de fonctions crée des instances de fonction selon les besoins et exécute les fonctions correspondantes. Une fois qu’une fonction a terminé son exécution, l’instance associée se retire, permettant à l’application Serverless de se réduire à zéro et d’entrer en mode économie d’énergie.
Maintenant, vous vous demandez peut-être s’il est possible de maintenir une instance en vie après l’exécution de la fonction au lieu de la terminer, afin qu’elle attende la prochaine invocation de fonction. Cela éliminerait le surcoût du démarrage à froid à chaque fois, ce qui permettrait des temps de réponse plus rapides.
En effet, Serverless anticipe de tels scénarios. Par conséquent, du point de vue du processus qui exécute l’instance de fonction, deux modèles existent :
- Run-to-Completion : Dans ce modèle, l’instance de fonction, une fois prête, exécute la fonction et se termine immédiatement. Cela représente la forme la plus pure d’utilisation de Serverless.
- Processus Persistant : Ici, l’instance de fonction, après s’être préparée, ne cesse pas son activité à la fin de la fonction. Au lieu de cela, elle revient et attend patiemment le prochain appel de fonction. Notez que même dans ce modèle, le fournisseur cloud finit par détruire l’instance de fonction si aucun événement ne la déclenche pendant une période prédéterminée.
Orchestration des données
La plupart des ingénieurs connaissent le modèle MVC (Modèle-Vue-Contrôleur), un paradisme de conception largement adopté. Cependant, l’essor des frameworks MVVM côté frontend a poussé la couche Vue vers l’avant, donnant naissance aux applications SPA (Single Page Applications). À l’inverse, les couches Contrôle et Modèle du backend ont été repoussées, donnant naissance à des applications backend orientées services.
Cette évolution a conduit à un découplage plus poussé entre le frontend et le backend. Le développement frontend peut avancer indépendamment, en s’appuyant sur des interfaces de données simulées, tandis que les équipes backend peuvent se concentrer sur le développement des interfaces de données. Cependant, cette séparation introduit une couche de passerelle de données avec des opérations d’E/S réseau élevées.
Node.js, avec sa nature asynchrone et non bloquante, et l’affinité de JavaScript avec les ingénieurs frontend, a naturellement assumé le rôle de la couche de passerelle de données. Cela a conduit à l’émergence de la couche BFF (Backend For Frontend) Node.js, qui orchestre les données et les interfaces backend, les adaptant en structures de données adaptées à une consommation frontend.
La couche BFF agit comme un intermédiaire, faisant le pont entre le frontend et le backend. Les données non traitées, souvent appelées données brutes ou métadonnées, sont pratiquement illisibles pour les utilisateurs finaux. Par conséquent, nous devons combiner et traiter les données pertinentes, en leur ajoutant de la valeur et en les rendant significatives. Ce processus de combinaison et de traitement s’appelle l’orchestration des données.
Traditionnellement, la gestion des applications Node.js pour la couche BFF était très gourmande en ressources, nécessitant des machines virtuelles ou des plateformes PaaS. Cependant, comme la couche BFF effectue principalement une orchestration de données sans état, nous pouvons remplacer sans heurt l’application Node.js par Serverless en utilisant le modèle run-to-completion. C’est l’essence du terme de plus en plus populaire SFF (Serverless For Frontend).
Maintenant que nous avons compris l’évolution du BFF vers le SFF, retraçons le nouveau flux de requêtes. Lorsque le frontend initie une demande de données, le déclencheur de fonction active notre service de fonctions. Notre fonction démarre alors, invoque l’interface de métadonnées du backend, traite les métadonnées renvoyées dans le format requis par le frontend, et enfin, notre fonction Serverless peut prendre un repos bien mérité.
Orchestration des services
L’orchestration des services partage des similitudes avec l’orchestration des données, la principale différence étant qu’elle se concentre sur la combinaison et le traitement de divers services offerts par le fournisseur cloud. Bien que le concept soit antérieur à Serverless, son implémentation traditionnelle était limitée par les versions linguistiques SDK prises en charge par les services. Généralement, on recourait à des fichiers YAML ou à des interfaces en ligne de commande pour orchestrer les services. Pour utiliser ces services ou API, il fallait trouver les SDK correspondants dans le langage de programmation de son choix, les charger dans son code et utiliser des clés secrètes pour appeler les méthodes SDK afin de réaliser l’orchestration. Comme pour l’orchestration des données, les coûts d’exploitation et de déploiement backend étaient importants, et l’absence de SDK obligeait à une implémentation manuelle basée sur les interfaces ou protocoles de la plateforme.
Serverless élargit les limites de l’utilisation des SDK. Par exemple, imaginons un service web devant envoyer des codes de vérification par e-mail. Nous pouvons y parvenir avec une fonction Serverless run-to-completion qui utilise le SDK du fournisseur cloud pour envoyer des e-mails. Parallèlement, une fonction Serverless persistante peut générer des codes de vérification aléatoires sous forme de chaînes, les stocker et déclencher la fonction Serverless d’envoi d’e-mails pour délivrer les codes dans les boîtes de réception des utilisateurs. Lors de la vérification, nous pouvons invoquer à nouveau la fonction Serverless persistante pour valider les codes.
Un avantage notable de Serverless est son indépendance vis-à-vis du langage. Cela libère les équipes de développement de l’obligation de n’utiliser qu’un seul langage, leur permettant d’exploiter les points forts de Java, PHP, Python, Node.js, etc., pour construire collaborativement des applications complexes.
La nature ouverte de l’orchestration des services Serverless a attiré une attention considérable de la part des fournisseurs cloud. Elle permet de créer des scénarios d’orchestration de services divers et complexes, tout en restant indépendante du langage, ce qui élargit considérablement les cas d’utilisation de divers services cloud. Cependant, cela exige également que les développeurs se familiarisent avec l’ensemble des services offerts par leur fournisseur cloud choisi.
Conclusion
- Il existe deux types de modèles de processus pour Serverless : le type à processus résident et le type à usage unique. Le type à processus résident est conçu pour s’adapter à l’architecture MVC traditionnelle et ne semble pas naturel ; si vous commencez à utiliser Serverless dès maintenant, je recommanderais définitivement le modèle à usage unique, qui permet de maximiser les avantages de Serverless.
- En remontant dans l’histoire, j’ai retracé l’évolution du BFF issu de la séparation frontend/backend, qui peut ensuite être remplacé par le SFF. Que ce soit pour l’orchestration d’interfaces internes ou l’orchestration de données externes, Serverless peut jouer un rôle très avantageux.
- En allant plus loin que l’orchestration des données, nous pouvons tirer parti des capacités de Serverless et des fournisseurs de services cloud pour réaliser une orchestration des services, créer des scénarios de services composites plus puissants et améliorer notre efficacité de recherche et développement.
Novita AI est la plateforme cloud tout-en-un qui alimente vos ambitions en matière d’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é.
Lectures recommandées
