Les avantages de l'informatique sans serveur et ses limites

Tous les avantages du « serverless » dont vous entendrez parler — évolutivité élastique, coûts de veille réduits, déploiement plus rapide — découlent d’un même choix fondamental : vous sacrifiez le contrôle de l’infrastructure au profit de la rapidité de développement. 

Pour prendre la bonne décision concernant l'informatique sans serveur, il faut commencer par comprendre en quoi elle consiste réellement. À partir de là, vous pourrez comparer les avantages qui se confirment face à des charges de travail réelles et les compromis qui apparaissent après la migration, une fois que vous vous êtes engagé dans cette voie.

En bref : ce qu'il faut savoir sur l'informatique sans serveur

• L'informatique « sans serveur » signifie que le fournisseur de services cloud gère la mise à disposition, la mise à l'échelle et la maintenance des serveurs. Le client gère le code et ne paie que pour le temps d'exécution.
• On distingue trois grandes catégories : « Function-as-a-Service » (FaaS), « Backend-as-a-Service » (BaaS) et les plateformes serverless gérées basées sur des conteneurs.
• Les principaux avantages sont la facturation à l'utilisation, la mise à l'échelle automatique et des cycles de déploiement plus rapides, puisque les développeurs déploient des fonctions au lieu de provisionner des environnements.
• Les principaux inconvénients sont la latence au démarrage à froid, un débogage plus difficile et la dépendance vis-à-vis d’un fournisseur, car la logique de votre application devient étroitement liée à l’environnement d’exécution d’un seul fournisseur.
• L'informatique sans serveur est particulièrement adaptée aux charges de travail variables et pilotées par les événements. Elle est en revanche moins adaptée aux charges de travail constantes et à haut débit, car ressources de calcul dédiées est souvent moins cher.
  

Qu'est-ce que l'informatique sans serveur, exactement ?

L'informatique sans serveur est un modèle d'exécution dans le cloud dans lequel un fournisseur alloue des ressources de calcul à la demande, exécute votre code, puis libère ces ressources une fois la tâche terminée.

Vous écrivez des fonctions ou de la logique backend. C'est le fournisseur qui décide où ce code s'exécute, de combien d'instances il a besoin et quand les arrêter.

Ce nom est impropre au sens littéral du terme. Serveurs physiques et virtuels toutes les demandes continuent d’être traitées. Ce qui a réellement disparu, c’est la visibilité que vous aviez sur ces demandes, ainsi que la responsabilité de leur gestion.

Cela diffère de l'Infrastructure-as-a-Service (IaaS), où l'on provisionne et gère directement des machines virtuelles, et de la Platform-as-a-Service (PaaS), où l'on gère une application sur une infrastructure partiellement abstraite mais qui continue de fonctionner en permanence. Le « serverless » va encore plus loin : rien ne s'exécute à moins qu'une requête ou un événement ne le déclenche.

Les trois types d'informatique sans serveur

1. Fonction en tant que service (FaaS) : C'est le modèle auquel la plupart des gens font référence lorsqu'ils parlent de “ serverless ”. Des plateformes telles qu'AWS Lambda, Google Cloud Functions, Cloudflare Workers et Azure Functions exécutent des fonctions individuelles en réponse à des déclencheurs (une requête HTTP, un téléchargement de fichier, un message de file d'attente, etc.) et facturent en fonction du temps d'exécution et de la mémoire allouée.
   
2. Backend-as-a-Service (BaaS) : Cette version prend en charge les composants backend gérés que vous devriez autrement développer vous-même : authentification, bases de données, stockage de fichiers, notifications push. Vous appelez une API au lieu de devoir mettre en place et gérer ce service. Firebase et AWS Amplify proposent des services dans cette catégorie.
   
3. Conteneurs sans serveur : Des plateformes telles qu'Azure Container Apps, AWS Fargate et Google Cloud Run vous permettent de déployer des applications conteneurisées sans avoir à gérer le cluster sous-jacent. Elles allient la flexibilité de packaging des conteneurs au modèle d'exploitation « sans intervention » du serverless.
   

La plupart des architectures « serverless » de production combinent ces trois éléments : elles utilisent le FaaS pour la logique pilotée par les événements, le BaaS pour les services backend courants et les conteneurs pour tout ce qui nécessite un temps d'exécution plus long ou un environnement personnalisé.

Les 5 principaux avantages de l'informatique sans serveur

En termes simples, les avantages résident dans une réduction des coûts et une maintenance moindre, mais cela vaut la peine d'approfondir un peu la question. 

1. Vous ne payez plus pour les capacités inutilisées. Dans un modèle de serveur traditionnel, vous prévoyez une capacité suffisante pour faire face aux pics de charge et vous payez cette capacité 24 heures sur 24, même à 2 heures du matin, alors que le trafic ne représente qu'une fraction de celui observé en période de pointe. Les plateformes « serverless » facturent en fonction de l'exécution réelle, souvent à la milliseconde près.
   
2. La mise à l'échelle cesse d'être un simple exercice de planification des capacités. Une plateforme sans serveur lance autant d’instances d’une fonction que le demande simultanée l’exige, puis les arrête à nouveau. Vous n’avez pas besoin de prévoir le trafic ni de vous y préparer à l’avance. Vous ne recevez pas d’appel en dehors des heures de bureau parce qu’un lancement est devenu viral et que votre parc de serveurs fixe n’a pas pu suivre le rythme.
   
3. Les cycles de déploiement se raccourcissent. Comme il n’y a pas de serveur à provisionner, à mettre à jour ou à configurer avant de déployer le code, les équipes peuvent publier des fonctions individuelles de manière indépendante, au lieu de redéployer une application monolithique. C’est en grande partie pour cette raison que l’adoption du « serverless » suit de très près celle des microservices. Le marché reflète cette dynamique : la taille du marché mondial du « serverless computing » s’élevait à estimé s'élevait à $24,51 milliards en 2024 et devrait atteindre $52,13 milliards d'ici 2030.
   
4. Les frais généraux liés à l'exploitation diminuent pour l'équipe chargée de l'infrastructure. Plus besoin d'appliquer de correctifs au système d'exploitation, de surveiller la capacité ni de maintenir à jour un parc de serveurs. Cela ne signifie pas pour autant que le travail opérationnel disparaît. Au contraire, il s'oriente désormais vers la surveillance des performances des fonctions, la gestion des autorisations et le contrôle des coûts au niveau des fonctions plutôt qu'au niveau des serveurs.
   
5. Les charges de travail caractérisées par un trafic imprévisible ou en pics deviennent moins coûteuses et plus résilientes. Prenons par exemple un traitement par lots qui s'exécute dix minutes par jour, une API qui connaît un pic de trafic lors du lancement d'un produit, ou encore un pipeline IoT qui ne se déclenche que lorsqu'un capteur est activé. Ce sont là des cas d'école où le modèle économique du « serverless » s'avère plus avantageux qu'un serveur dédié qui reste inactif le reste du temps.
   

5 défis que le « serverless » ne permet pas de relever

Une approche « serverless » n'est pas toujours la solution idéale. 

1. Les démarrages à froid sont bien réels, et ils ne disparaîtront pas complètement. Lorsqu'une fonction n'a pas été exécutée récemment, la plateforme doit initialiser un nouvel environnement d'exécution avant que votre code ne s'exécute, ce qui entraîne une latence supplémentaire. Pour les applications sensibles à la latence, cela pose un problème.
   
2. Le débogage devient plus difficile, et non plus facile. Une application monolithique présente une défaillance à un endroit que vous pouvez inspecter directement. Une application « serverless » est un système distribué composé de fonctions déclenchées indépendamment les unes des autres, ce qui signifie qu’une défaillance peut provenir d’une fonction, d’un déclencheur, d’une file d’attente ou de l’interaction entre ces trois éléments. Les environnements de test locaux reproduisent rarement à l’identique le comportement des déclencheurs en production.
   
3. Les charges de travail de longue durée ou en régime permanent deviennent plus coûteuses, et non moins. La tarification « serverless » est optimisée pour les pics d'activité et les périodes d'inactivité. Une charge de travail fonctionnant en continu à haut débit coûtera souvent plus cher dans un modèle « serverless » facturé à l'exécution que sur une instance réservée et dédiée. Adaptez la charge de travail au modèle de tarification, et non l'inverse.
   
4. Dépendance vis-à-vis d’un fournisseur. Les fonctions sont développées en fonction de l'environnement d'exécution, du modèle de déclenchement et de l'ensemble des services gérés propres à chaque fournisseur. La migration d'une architecture « serverless » entre AWS, Google Cloud et Azure implique généralement de réécrire une grande partie de l'application.
   
5. La responsabilité en matière de sécurité ne disparaît pas, elle se déplace. Le fournisseur assure la sécurité de l'infrastructure sous-jacente. Vous restez toutefois responsable des autorisations au niveau des fonctions, de la gestion des secrets et du code lui-même. L'attribution de rôles de gestion des identités et des accès (IAM) trop larges à des fonctions individuelles constitue l'une des erreurs de configuration les plus courantes dans les environnements serverless que les équipes de sécurité constatent lors de leurs audits.
   

La migration vers une infrastructure « serverless »

L'informatique sans serveur est un modèle spécifique, adapté à des types de charges de travail particuliers : pilotées par les événements, par intermittence, faiblement couplées et tolérantes à une variation de quelques centaines de millisecondes lors du démarrage à froid.

De plus, chaque fois qu’une entreprise adopte le « serverless » à grande échelle, cela entraîne la création d’un parc de serveurs physiques, de baies sur site ou de matériel cloud réservé dont la charge de travail n’a plus besoin.

La migration des charges de travail depuis une infrastructure dédiée vers un modèle « serverless » est l’un des facteurs les plus courants à l’origine d’un renouvellement du matériel ou d’une mise hors service complète d’un centre de données ; or, ce matériel ne se décharge pas de lui-même de manière responsable simplement parce que la charge de travail a été transférée vers le cloud.

Si la migration vers une architecture « serverless » prévue dans votre feuille de route implique de vous débarrasser de baies, de disques durs ou même de l'ensemble de l'espace occupé par votre centre de données, Services de démantèlement de centres de données et de cession d'actifs informatiques proposés par exIT Technologies gérer la partie de la migration qui n'apparaît pas sur le schéma d'architecture.