---
title: Serverless Computing
---

# Serverless Computing

De nos jours, la majorité des entreprises fonctionnent avec une part de cloud computing. Leur objectif est de ne plus se préoccuper du maintien d'une infrastrucure physique quelconque et de pouvoir se concentrer sur l'essentiel du travail de création et d'optimisation. Mais cette externalisation est généralement très coûteuse.

Nous nous penchons ici sur une solution utilisée de plus en plus aujourd'hui : Le Serverless computing (ou informatique sans serveur en Français).

> "We predict that Serverless Computing will grow to dominate the future of Cloud Computing."
> [Cloud Programming Simplified: A Berkeley View on Serverless Computing](https://arxiv.org/abs/1902.03383)
> [name=Berkeley CS Department][time=Feb 2019][color=orange]

## Qu'est-ce c'est ?

Le Serverless computing est un modèle d'exécution de l'informatique dans lequel un fournisseur cloud alloue des ressources machine à la demande, en prenant soin des serveurs pour le compte de ses clients. Le Serverless ne conserve pas de ressources dans une mémoire volatile, le calcul est plutôt effectué en courtes rafales et les résultats sont conservés dans un espace de stockage.

Le terme "sans serveur" est mal choisi dans le sens où les serveurs sont toujours utilisés par les fournisseurs de services en nuage pour exécuter le code des développeurs. Cependant, les développeurs d'applications Serverless ne sont pas concernés par la planification de la capacité, la configuration, la gestion, la maintenance, l'exploitation ou la mise à l'échelle des conteneurs, des VM ou des serveurs physiques.

> "Serverless computation is going to fundamentally not only change the economics of what is back-end computing, but it's going to be the core of the future of distributed computing."
> [name=Satya Nadella, CEO Microsoft][time=May 2017][color=orange]

Il est important de distinguer ce système des modèles informatiques ou de mise en réseau qui ne nécessitent pas de serveur réel pour fonctionner, comme le peer-to-peer. Le Serverless computing utilise bien un serveur, mais celui-ci est simplement décentralisé.

## Architecture

Le Serverless computing peut se résumer en deux parties essentielles :
- Backend as a Service (BaaS | Backend en tant que service en Francais)
- Function as a Service (FaaS | Fonction en tant que service en Francais)

Voici un schéma simplifié d'un exemple d'API Serverless utilisant à la fois un FaaS et un BaaS.


Détaillons le rôle de chaque partie.

### Backend as a Service

Le Backend as a Service Serverless, c'est le résultat de la banalisation de composants d'application entiers.

L'authentification en est un bon exemple. De nombreuses applications codent leur propre fonctionnalité d'authentification. Ces dernières comportent souvent des fonctions telles que l'inscription, la connexion, la gestion des mots de passe et l'intégration avec d'autres fournisseurs d'authentification.
On retrouve souvent cette logique dans la plupart des applications, et des services comme [Auth0](https://auth0.com/fr) ont été créés pour nous permettre d'intégrer une fonctionnalité d'authentification prête à l'emploi dans une application sans avoir à la développer soi-même.

Dans le même ordre d'idées, on trouve les bases de données BaaS, comme le service de base de données hiérarchique de [Firebase](https://firebase.google.com/) (Google) : des équipes chargées des applications mobiles ont constaté qu'il était judicieux de faire communiquer le client directement avec une base de données côté serveur.
Les autres grosses entreprises de la Silicon Valley n'ont pas manqué de s'attaquer à leur tour au marché avec [Amazon Aurora](https://aws.amazon.com/fr/rds/aurora/) qui propose une version sans serveur de ses bases de données, basées sur MySQL et PostgreSQL, offrant des configurations à la demande et à mise à l'échelle automatique, ou encore [Azure Data Lake](https://azure.microsoft.com/en-us/solutions/data-lake/) qui est un service de stockage et d'analyse de données hautement évolutif appartenant a Microsoft.
Une base de données BaaS supprime une grande partie des frais généraux d'administration de la base de données et fournit généralement des mécanismes pour effectuer une autorisation appropriée pour différents types d'utilisateurs, selon les modèles attendus d'une application sans serveur.

Un tel dispositif peut faire peur (probablement pour des raisons que nous aborderons dans la section sur les inconvénients), mais le nombre d'entreprises prospères qui ont été en mesure de produire des produits convaincants en n'utilisant pratiquement aucun code côté serveur est assez hallucinant. Joe Emison en a donné quelques exemples lors de [sa conférence Serverless](https://youtu.be/WuXAi6b0Q7Q).

### Function as a Service

> "Exécutez votre code d'application sans serveur, mettez-le à l'échelle automatiquement et ne payez que lorsque vous l'utilisez."
> [name=IBM][color=orange]

Ce qui est appréciable avec le FaaS, c'est que la mise à l'échelle est complètement automatique, élastique et gérée par le fournisseur. Il en découle de nombreux avantages mais le plus significatif pour l'infrastrucure de base est de ne payer que pour le calcul dont elle a besoin : le gain économique qui en découle peut être considérable pour certaines entreprises.

C'est un modèle d'exécution dit "event-driven" qui exécute de petits modules de code. Il déclenche les fonctions lorsque l'exécution de certains événements se produit dans les modules de l'application. Expliquons cela à travers un exemple.

Supposons qu'on exécute une application serveur qui ne traite qu'une seule demande par minute, qu'il faille environ 50 ms pour traiter chaque demande, et que l'utilisation moyenne du CPU sur une heure soit de 0,1 %. Si cette application est déployée sur son propre hôte dédié, c'est tout à fait inefficace : un millier d'autres applications similaires pourraient partager cette seule machine pendant ce temps.

Le FaaS neutralise cette inefficacité et la traduit par une réduction des coûts. Avec l'exemple d'application ci-dessus, vous ne payez que 100 ms de calcul par minute, soit 0,15 % du temps total.

Prenons une autre hypothèse tout aussi intéressante : un trafic qui présente des pics de connexions. A l'origine, le service ne reçoit que 10 requêtes par secondes, mais toutes les 5 minutes il enregistre un pic de 30 seconces avec 100 requêtes par seconde. Si l'on reste sur un serveur hébergé par l'hôte, on se retrouve alors avec un flux ralenti par 10 sur les périodes de forte demande.


Il sera nécessaire, pour absorber ce ralentissement, de multiplier par 10 la puissance de calcul en achetant de l'équipement supplémentaire qui restera inutile 90% du temps. On comprend bien la perte que cela représente.

Le FaaS offre une alternative : plus besoin d'acheter des serveurs plus puissants, il suffit d'opter pour un forfait supplémentaire pour la puissance nécessaire lors des heures de pointe.

Le premier acteur important dans ce domaine fut Google, qui lançait en 2008 sa plateforme [Google App Engine](https://cloud.google.com/appengine) qui proposait une facturation au compteur pour les applications qui utilisaient un Framework Python personnalisé, mais qui ne pouvaient pas exécuter de code arbitraire.

Aujourd'hui, c'est [AWS Lambda](https://aws.amazon.com/fr/lambda/), introduit en 2014 par Amazon, qui a popularisé le modèle du FaaS. Il est soutenu par un grand nombre d'outils Serverless supplémentaires comme AWS SAM ou encore Amazon CloudWatch.

IBM, de son cote, propose depuis 2016 le [IBM Cloud Functions](https://cloud.ibm.com/functions/), public. Cette année (2021), IBM a ajouté une deuxième offre Serverless : [IBM Cloud Code Engine](https://www.ibm.com/cloud/code-engine).

## Avantages

### Coût

La technologie Serverless est souvent plus rentable que la location ou l'achat d'une quantité fixe de serveurs, impliquant généralement des périodes importantes de sous-utilisation ou de temps d'inactivité.

Cette organisation s'apparente un peu à de l'informatique "pay-as-you-go" ou "code-barre", car vous êtes facturé uniquement en fonction du temps et de la mémoire alloués pour exécuter votre code, sans frais associés au temps d'inactivité.

Les avantes économiques sont immédiats : plus de coût liés à l'installation de serveurs (licences, installation d'un système d'exploitation, maintenance, ...)

### Elasticité

Une architecture Serverless signifie que les développeurs et les opérateurs n'ont pas besoin de passer du temps à mettre en place et à régler des politiques ou des systèmes d'autoscaling : le fournisseur de cloud est responsable de la mise à l'échelle de la capacité en fonction de la demande.

> "From zero to planet-scale."
> [name=Google][time=Sept 2017][color=orange]

Étant donné que les systèmes natifs du cloud évoluent par nature à la fois vers le bas et vers le haut, ces systèmes sont dits élastiques plutôt qu'évolutifs.

### Ecologie

Au cours des deux dernières décennies, on a assisté à une augmentation massive du nombre et de la taille des data centers dans le monde. Outre les ressources physiques nécessaires à la construction de ces centres, les besoins énergétiques associés sont si importants qu'Apple, Google et d'autres sociétés du même genre envisagent d'héberger certains de leurs data centers à proximité de sources d'énergie renouvelable afin de réduire l'impact de la consommation de combustibles fossiles de ces sites.

En moyenne, un seul data center consomme autant d'électricité que 30 000 habitants européens. Google par exemple possède 21 parcs (bien plus grands que la moyenne) a lui seul dans le monde.

Les serveurs inactifs, mais sous tension, consomment une quantité anormale de cette énergie.

> "Typical servers in business and enterprise data centers deliver between 5 and 15 percent of their maximum computing output on average over the course of the year."
> [name=Forbes][color=orange]

C'est extraordinairement inefficace et cela engendre un impact environnemental énorme.

D'un côté, il est probable que le cloud ait déjà contribué à réduire cet impact puisque les entreprises peuvent "acheter" plus de serveurs à la demande, uniquement lorsqu'elles en ont absolument besoin, plutôt que de provisionner tous les serveurs éventuellement nécessaires longtemps à l'avance. Toutefois, on pourrait également affirmer que la facilité de provisionnement des serveurs a peut-être aggravé la situation si un grand nombre de ces serveurs sont laissés en place sans gestion adéquate de la capacité.

Si nous utilisons un serveur auto-hébergé, nous prenons toujours manuellement des décisions relatives à la capacité de nos applications qui dureront souvent des mois voire des années. En général, nous sommes prudents, et à juste titre, en ce qui concerne la gestion de la capacité, donc nous sur-provisionnons, ce qui conduit aux inefficacités dont nous venons de parler. Grâce au Serverless, nous ne prenons plus nous-mêmes de telles décisions en matière de capacité - nous laissons le fournisseur fournir juste assez de capacité de calcul pour nos besoins en temps réel. Le fournisseur peut ensuite prendre ses propres décisions en matière de capacité pour l'ensemble de ses clients.

Cette différence devrait conduire à une utilisation beaucoup plus efficace et stratégique des ressources dans les data centers, et donc à une réduction importante de l'impact environnemental par rapport aux approches traditionnelles.

### Productivité

Avec le FaaS, les unités de code exposées au monde extérieur sont de simples fonctions événementielles. Cela signifie qu'en général, le programmeur n'a pas à se soucier du multithreading ou du traitement direct des requêtes HTTP dans son code, ce qui simplifie la tâche du développement de logiciels backend.

De plus, le Serverless permet aux développeurs de déployer une nouvelle version de leur travail en quelques millisecondes, sans se préoccuper d'un service technique mainteneur, puisque c'est la tâche du fournisseur directement de fournir de manière instantanée un service adapté et prêt à l'emploi.

Le business n'a ainsi plus à se préoccuper des système et peut se consacrer à la qualité de son service.

## Inconvénients

### Sécurité

On considère parfois, à tort, que les architectures Serverless sont plus sûres que les architectures traditionnelles. Bien que cela soit vrai dans une certaine mesure car les vulnérabilités du système d'exploitation sont prises en charge par le fournisseur du service, la surface d'attaque totale est considérablement plus grande car l'application comporte beaucoup plus de composants que les architectures traditionnelles, et chaque composant est un point d'entrée dans l'application Serverless.

De plus, les solutions de sécurité dont disposaient les clients pour protéger leurs charges de travail cloud deviennent inutiles car ils ne peuvent pas contrôler et installer quoi que ce soit au niveau des points d'extrémité et du réseau, comme par exemple un système de détection/prévention des intrusions ([IDS](https://en.wikipedia.org/wiki/Intrusion_detection_system)/[IPS](https://www.forcepoint.com/cyber-edu/intrusion-prevention-system-ips)).

Il faut aussi bien faire comprendre aux développeurs qu'il est nécessaire d'avoir une approche sécurisée de la programmation, même si le fournisseur s'occupe par définition d'une partie importante de la sécurité. Protego résume très bien les qualités indispensables chez les développeurs de services Serverless :

> "La solution pour sécuriser les applications Serverless est un partenariat étroit entre les développeurs, DevOps et AppSec, également connu sous le nom de DevSecOps. Il faut trouver un équilibre entre le fait que la sécurité n'appartient pas aux développeurs, mais qu'ils ne sont pas non plus exonérés de toute responsabilité. Prenez des mesures pour que la sécurité soit le problème de tous. Créez des équipes inter-fonctionnelles et travaillez à une intégration étroite entre les spécialistes de la sécurité et les équipes de développement. Collaborez pour que votre organisation puisse résoudre les risques de sécurité à la vitesse du Serverless."
> [name=Protego (traduit)][color=orange]

### Vie privée

De nombreux environnements de fonctions sans serveur sont basés sur des environnements de cloud public propriétaires. Ici, certaines implications en matière de vie privée doivent être prises en compte, comme les ressources partagées et l'accès ouvert à des employés externes. Cependant, le Serverless computing peut également être réalisé sur un environnement de cloud privé ou même sur site, en utilisant par exemple la plateforme Kubernetes. Cela permet aux entreprises d'avoir un contrôle total sur les mécanismes de protection de la vie privée, tout comme pour l'hébergement dans des configurations de serveurs traditionnelles.

### Performances

Les services Serverless rarement utilisés peuvent souffrir d'une latence de réponse plus importante que ceux qui s'exécutent en permanence sur un serveur, une machine virtuelle ou un conteneur dédié. En effet, contrairement à l'autoscaling, le fournisseur de cloud computing désactive complètement les services lorsqu'ils ne sont pas utilisés. Cela signifie que si le moteur d'exécution (par exemple, le moteur d'exécution Java) nécessite un temps important pour démarrer, cela créera une latence supplémentaire.

Cependant, une solution possible (mais un peu "brutale") serait d'envoyer régulièrement des requêtes, maintenant le service dans un état actif.

### Ressources

Le Serverless computing n'est pas adapté à certaines charges de travail, comme le calcul haute performance, en raison des limites de ressources imposées par les fournisseurs de cloud, et aussi parce qu'il serait probablement moins coûteux de fournir en masse le nombre de serveurs censés être nécessaires à un moment donné.

### Débogage

Le diagnostic des problèmes de performance ou d'utilisation excessive des ressources avec le code Serverless peut être plus difficile qu'avec le code serveur traditionnel, car bien que des fonctions entières puissent être chronométrées, il n'est généralement pas possible de creuser plus en détail en attachant des profileurs, des débogueurs ou des outils APM. En outre, l'environnement dans lequel le code s'exécute n'est généralement pas open source, de sorte que ses caractéristiques de performance ne peuvent pas être précisément reproduites dans un environnement local.

Le débogage avec FaaS est un domaine intéressant. Des progrès ont été réalisés dans ce domaine, principalement en ce qui concerne l'exécution locale des fonctions FaaS. Microsoft, par exemple, fournit un excellent support de débogage pour les fonctions exécutées localement, mais déclenchées par des événements distants. Amazon offre quelque chose de similaire, mais pas encore déclenché par des événements de production.

Le débogage des fonctions s'exécutant réellement dans un environnement cloud de production est une autre histoire. AWS Lambda, en tout cas, n'a pas encore de support pour cela, mais un tel système simplifierait significativement les choses.

### Testing

Dans la même catégorie que le débogage, les tests en Serverless représentent un domaine tout aussi intéressant.

Tout d'abord, le test unitaire des applications Serverless est assez simple puisque tout le code qui est écrit est "simplement" du code. De plus, la plupart du temps, il n'y a pas tout un tas de bibliothèques personnalisées utilisées ou d'interfaces que vous implémentées, ce qui simplifie la tâche.

Les tests d'intégration des applications Serverless en revanche sont difficiles. Pour un système BaaS, vous vous appuyez délibérément sur des systèmes fournis par des tiers plutôt que sur votre propre base de données. Vos tests d'intégration doivent-ils donc également utiliser les systèmes externes ? Si oui, dans quelle mesure ces systèmes se prêtent-ils à des scénarios de test ? Votre fournisseur peut-il vous proposer une stratégie de facturation différente pour les tests de charge ?

Les mêmes types de problèmes existent dans le domaine du FaaS, bien qu'il y ait eu des améliorations dans ce domaine. Aujourd'hui, il est possible d'exécuter localement des fonctions FaaS pour AWS Lambda et Microsoft Azure. Cependant, aucun environnement local ne peut simuler entièrement l'environnement du cloud.

> "S'appuyer uniquement sur des environnements FaaS locaux n'est pas une stratégie que je recommande. En fait, j'irais même plus loin en suggérant que votre environnement canonique pour l'exécution de tests d'intégration automatisés, au moins dans le cadre d'un pipeline de déploiement, devrait être le cloud, et que vous devriez utiliser les environnements de test locaux principalement pour le développement et le débogage interactifs. Ces environnements de test locaux continuent de s'améliorer - SAM CLI, par exemple, fournit un retour rapide pour le développement d'une application API HTTP soutenue par Lambda."
> [color=orange][name=Mike Robert, spécialiste Cloud Architecture (traduit)]

Si la prise en compte des tests d'intégration est importante, c'est en partie parce que les unités d'intégration avec le FaaS (c'est-à-dire chaque fonction) sont beaucoup plus petites qu'avec d'autres architectures, et qu'il faut donc compter beaucoup plus sur les tests d'intégration qu'avec d'autres styles d'architecture.

C'est un grand pas que de passer des tests en local sur un ordinateur à des tests sur le cloud sur un serveur externe, mais la technologie doit continuer d'évoluer. Par ailleurs, Amazon propose maintenant de de faire tourner littéralement tout votre IDE sur le cloud. Cela permet de réduire toujours plus la distance entre le développement des applications et les serveurs.

### Verrouillage des fournisseurs

Il est très probable que les fonctionnalités Serverless d'un fournisseur que vous utilisez soient mises en œuvre différemment par un autre fournisseur. Si vous souhaitez changer de fournisseur, vous devrez certainement mettre à jour la quasi-totalité de votre travail, notamment les outils d’opérations comme les déploiements et suivis avec l'interface, parfois le code pour satisfaire des interfaces différentes, et même (rarement) changer le design et l'architecture entier lorsqu'il y a des différences significatives dans le comportement de l'implémentation des fournisseurs. Et même si vous parvenez à migrer facilement une partie de votre écosystème, un autre composant architectural peut avoir un impact plus important.

Par exemple, imaginons que vous utilisiez AWS Lambda pour répondre à des événements sur un bus de messages AWS Kinesis. Les différences entre AWS Lambda, Google Cloud Functions et Microsoft Azure Functions peuvent être relativement faibles, mais vous ne pourrez tout de même pas connecter les implémentations des deux derniers fournisseurs directement à votre flux AWS Kinesis. Cela signifie qu'il ne sera pas possible de changer, ou de porter, votre code d'une solution à une autre sans changer également d'autres éléments dans votre infrastructure.

Pour y remédier, certains clients préfèrent adopter une approche dite "multi-cloud" : développer et exploiter des applications sans tenir compte des moyens personnalisés offerts par le fournisseur du cloud. Cependant, cette approche est toujours bien plus couteuse qu'une simple approche mono-cloud dans laquelle on peut utiliser tous les moyens d'optimisation offerts par le fournisseur. C'est pour cela qu'il est très souvent recommandé de bien choisir son fournisseur avec lequel vous êtes sûr de travailler un maximum de temps et donc d'exploiter les solutions proposées au maximum.

## Le serverless computing est-il une bonne option ?

Il est difficile de donner une réponse claire et précise à ce genre de question.

L'approche Serverless n'est pas adaptée à tous les problèmes. Attention donc à ceux qui sont certains qu'elle va remplacer toutes les architectures que nous connaissons. Il faut donc bien réfléchir avant de se lancer tête baissée dans un système Serverless.

Certes, les avantages proposés par ces systèmes sont intéressants : une évolutivité auto-gérée et une productivité augmentée sont deux choses qu'une entreprise recherche à tout prix. Cependant, il faut bien prendre conscience du revers de la médaille, comme la sécurité et le débogage/testing, qui ne sont plus si simple à mettre en place.

Ces richesses ne doivent cependant pas être écartées trop rapidement, car l'architecture Serverless présente des aspects positifs significatifs, notamment une réduction des coûts d'exploitation et de développement, une gestion opérationnelle plus facile et un impact environnemental réduit. L'avantage le plus confortable à mes yeux est notamment la possibilité de déployer n'importe quelle mise à jour en un instant, sans se soucier des nombreux problèmes techniques qui sont trop souvent rencontrés avec les serveurs physiques.

Encore aujourd'hui, le Serverless est en pleine expansion et promet des jours radieux aux entreprise auxquelles il propose une véritable révolution technique, d'autant qu'il est fort probable que les problèmes énoncés plus hauts seront au moins pour partie résolus.

*[FaaS]: Function as a Service
*[BaaS]: Backend as a Service