Serverless : définition, exemples

Le Serverless (sans serveur) regroupe un ensemble de services dans le Cloud où l'exécution d'une application ou d'un programme est réalisée sans que le développeur manipule et administre l'infrastructure sous-jacente. Ces services sont très présents dans les techniques du Cloud, car elles permettent d'optimiser les ressources tout en évitant les contraintes opérationnelles de gestion d'infrastructure.

Dans cet article, nous allons détailler les principes fondamentaux du serverless, comment les architectures fonctionnent, les propriétés des services associées et quelques exemples de services utilisés.

Pourquoi utiliser du Serverless ?

Initialement, lorsque l'on doit déployer une application Web, il y a plusieurs sujets qui interviennent.

• Il faut provisionner des serveurs adaptés pour l'application : en particulier, choisir les bonnes ressources (processeurs virtuels, mémoire, bande passante) va dépendre des besoins de l'application mais aussi des utilisateurs qui vont interagir avec l'application.
• Il faut assurer la disponibilité de l'application : garantir une disponibilité constante demande une infrastructure scalable (voire élastique) avec des équilibrages de charges entre plusieurs serveurs.
• Il faut maintenir les serveurs : en particulier vérifier les pannes, les ressources consommées, traquer les erreurs mais également mettre à jour vers de nouvelles versions.

Cela peut devenir très difficile à gérer notamment pour des équipes de tailles réduites, encore plus pour des équipes Data dont les opérations Cloud ne sont pas le coeur de métier. Au final, tous ces sujets finissent par éloigner le développeur de sa mission d'origine : développer l'application. C'est là que le serverless rentre en jeu.

Avantages du Serverless

Le principal avantage du serverless, c’est justement le fait de ne plus avoir besoin de gérer de serveurs. Une grande partie administrative est gérée par le Cloud, ce qui permet à une équipe de se concentrer sur l’application.

L’autre avantage est son faible coût : puisque l’on ne paie que l’exécution d’une fonction, on ne consomme pas 100% des ressources chaque jour, mais une proportion plus faible par rapport à un serveur constamment en ligne.

Architecture Serverless

Une architecture Serverless (ou simplement Serverless) est une solution efficace pour partager les responsabilités entre le développeur et le fournisseur Cloud (Google Cloud, AWS, Azure, etc). En effet, tous les points que nous venons de détailler concernent l'exécution de l'application et non le développement de celle-ci. C'est justement tout l'intérêt du serverless : c'est le fournisseur Cloud qui va être responsable de l'exécution de l'application.

En d'autres termes, en tant que développeur/ML Engineer, nous n'aurons pas besoin de configurer les serveurs et tout ce qui englobe leur gestion avec du serverless. Nous nous concentrons uniquement sur la conception du code. Ainsi, le fournisseur Cloud va lui-même gérer l'équilibrage de charge, le provisionnement de ressources et la mise à jour des serveurs.

Tout ceci peut paraître magique. Pour faciliter l'interaction avec une architecture serverless, les fournisseurs Cloud ont créé des « Function as a Service » (FaaS), où chaque fonction est un code ou un conteneur exécuté indépendamment des autres fonctions.

Cette structure permet de facturer les fonctions serverless à la consommation : on ne paie l'infrastructure sous-jacente que lorsque les fonctions sont utilisées. Ainsi, si une fonction est exécutée que pendant une certaine plage horaire chaque jour, alors la facturation ne concerne que cette plage horaire. En dehors de la plage, il n'y a aucune facturation puisqu'aucune exécution de la fonction n'est réalisée. Cela permet, en plus d'optimiser l'efficacité opérationnelle, de réduire la facturation lorsque les charges ne sont pas constantes en comparaison avec un serveur qui devrait rester en état disponible 24h/24.

Mais pour bien comprendre comment fonctionne techniquement une fonction serverless, il y a plusieurs points qui doivent être abordés.

Microservices

Dans une architecture serverless, les microservices sont omniprésents. Contrairement à une application monolithique dont l'intégralité des composantes seraient exécutée sur un seul et même serveur, chaque application ou composante en microservices sont exécutés indépendamment des autres, en tant que services mais avec des fonctionnalités précises. Plusieurs applications vont donc interagir entre-elles, et ce couplage faible, bien qu'une bonne pratique dans le Cloud, ajoute des difficultés.

Il convient donc de cartographier et documenter l'ensemble de ces services, puisque lorsque dans un projet, il y a plusieurs dizaines de fonctions serverless, cela peut devenir compliqué à maintenir.

Fonctions stateless

Un autre point très important concerne les fonctions sans états. En effet, lorsqu'un code est exécuté sur une fonction serverless, chaque appel à cette fonction est indépendante des précédentes. Il faut donc que le traitement réalisé par une fonction puisse être reproduit à chaque instant. De plus, cette exécution est limitée dans le temps : en règle générale, les fonctions serverless ne peuvent être exécutées que sur plusieurs minutes au maximum.

Ainsi, chaque exécution ne peut stocker des informations persistantes qui seront conservées pour les prochaines exécutions : c'est le principe du stateless.

❓ Mais alors comment stocker des variables ou partager des informations entre les exécutions ?

Dans ce cas, il est préférable d'utiliser une base de données (base SQL, base clé/valeur, ...) pour stocker ces variables et informations qui seront réutilisées.

Cold Start

Le dernier point qui peut avoir son importance, c'est le démarrage à froid (ou cold start). En effet, malgré l'appellation serverless, il y a bien un serveur physique qui héberge le code source ou le conteneur et qui l'exécute en mémoire. Seulement, il existe une latence entre le moment où une requête est envoyée vers la fonction, et le moment où la requête est exécutée par la fonction serverless. Cette latence vient du fait que la fonction n'est pas automatiquement chargée en mémoire dans un serveur physique, pour éviter de consommer de la mémoire physique lorsqu'aucune requête n'est envoyée.

Lorsqu'une fonction est souvent requêtée (plusieurs par secondes/minutes), alors la fonction reste chargée en mémoire. En revanche, si aucune requête n'est pas envoyée pendant un laps de temps, alors la fonction associée n'est plus chargée en mémoire pour en libérer de l'espace sur le serveur physique. Si une autre requête survient par la suite, alors ce temps de chargement de la fonction dans le serveur physique représente ce démarrage à froid.

Ce temps de latence peut dépendre de plusieurs paramètres : taille de la fonction à charger en mémoire, langage et méthode d'exécution de la fonction ou fournisseur Cloud.

Quand utiliser du serverless ?

Le serverless est surtout adapté pour les codes ou les applications simples.

En effet, il faut prendre en compte les temps de chargement avec le serverless : plus le code est lourd, plus cela nécessite du temps et implique des coûts supplémentaires. Le serverless est particulièrement adapté pour les situations suivantes.

• Impossibilité d’administrer des serveurs (manque de temps, de profils).
• Codes exécutés en réponse à un événement déclencheur (fichier, base de données).
• Applications ayant un nombre faible nombre de requêtes sur une période de temps (< 1 requête par seconde).
• Traitement de données (IoT, multimédia).
• Pipelines d’intégration et de déploiement continu (CI/CD).

On utilise le serverless dans les situations où les traitements n'excèdent pas plusieurs minutes et lorsque l’on souhaite déployer rapidement.