Serverless ou informatique sans serveur, jusqu’au bout de la logique Cloud

Le Serverless, ou informatique sans serveur, est un principe apparu récemment à l’échelle du temps informatique. C’est une sorte de quête d’absolu des DSI et peut-être plus encore des DAF. Il cherche à répondre à la question la plus primitive du Cloud : peut-on se passer des serveurs ?

À l’origine de la naissance du Cloud Computing, il s’agissait, ni plus ni moins, d’abaisser le coût d’investissement dans les infrastructures informatiques. Et par extension, de s’affranchir progressivement de toutes les contraintes imposées par ces infrastructures.

Revenons en détail sur le serverless : comment le définir ? Quels sont les avantages les plus concrets et démontrables, et surtout, quels en sont les inconvénients et les risques ? Vous allez le voir dans les réponses que nous apportons ci-après : rien de magique derrière le Serverless. Mais un mélange efficace de technologies et de modèles économiques pour répondre au plus près à l’évolution de la demande des entreprises.

Le terme « Serverless », littéralement « sans serveur », se réfère à l’exécution du code d’une application en l’absence d’infrastructure locale ou Cloud dédiée spécifiquement à une organisation ou une application donnée.

En d’autres termes, dans une architecture sans serveur, l’exécution du code, mais aussi la maintenance des serveurs, est gérée par le fournisseur de cloud computing.

Une mise au point s’impose : derrière cette appellation qui retient l’attention, on trouve malgré les apparences... des serveurs.

Car la technologie n’en est pas encore au stade ou l’informatique va devenir totalement virtuelle, impalpable, débarrassée de toute contrainte physique. Il y bien sûr des ressources et des serveurs sur lesquels vont s’exécuter les codes.

Cette approche est assez similaire à celle des microservices. La différence vient du fait que l’architecture serverless est liée naturellement à un fournisseur Cloud (CSP). Alors que les microservices s’appuient sur des conteneurs qui peuvent être déployés sur différents hébergements.

On emploie fréquemment le terme de FaaS, ou Function As A service. En effet, il s’agit bien d’exécuter une fonction à la demande, à chaque fois qu’il est nécessaire, en requêtant un Cloud provider distant :

1. Le développeur doit simplement fournir son code ;
2. le fournisseur se chargera de renvoyer le résultat à chaque fois qu’il est sollicité.

On est donc d’abord dans une logique de réduction des coûts d’infrastructure, et de très grande adaptabilité.

Le modèle de facturation est le plus souvent un modèle « pay-as-you-go » : l’entreprise paye la mémoire, le stockage et la puissance de calcul utilisés durant l’exécution, en fonction de son utilisation, et donc au temps de serveur utilisé :

• il est possible en serverless d’amenuiser les coûts d’un service très peu sollicité ;
• la facturation est de toute façon une sorte d’aboutissement du concept de Cloud Computing : le strict reflet de l’usage qui aura été fait du serveur distant ;
• si une fonction, un code, n’est pas exécuté, son coût pourra être nul.

Autre avantage, la rapidité de développement. Pour passer du projet à la production, il n’est plus nécessaire de se poser la question de l’infrastructure : la puissance de calcul sera forcément disponible, à volonté.

L’élasticité est aussi un atout certain. Si vous ne souhaitez pas passer du temps à dimensionner ou tester des ressources matérielles, transférez cette charge au CSP. Lui saura toujours vous fournir la puissance nécessaire, au moment voulu : cela fait partie du contrat.

Malgré les apparences, cette architecture impose certaines règles.

Elles viennent notamment du nombre réduit de fournisseurs. Les 3 plus importants sont :

• AWS (Amazon Web Service), et notamment AWS Lambda qui est l’acteur historique,
• Microsoft Azure Functions,
• et Google Functions.

Le mode de facturation implique de concevoir du code peu gourmand en temps de calcul :

• de toute façon, le temps d’exécution alloué à la fonction est généralement limité ;
• vous ne pourrez pas le dépasser, ou il sera surfacturé.

👉 Par exemple, AWS, qui a lancé ce concept en 2014, donne les chiffres suivants :

• la durée médiane d’exécution d’une fonction sur ses serveurs s’élève à 800 ms,
• un quart seulement dépasse les 3 secondes,
• et 12 % vont au-delà de 10 secondes.

En général, le codage est contraint par les langages (ou le langage) pris en charge par le Cloud Service Provider. La facturation repose aussi sur la mémoire nécessaire à l’exécution de votre code.

Donc, si l’architecture serverless est d’une grande souplesse et peut permettre de faire face à des montées en charge importantes, elle doit être maîtrisée en termes de coût. Elle peut même s’avérer plus coûteuse qu’une architecture On premise ou Cloud classique.

Du fait de sa nature bien particulière, le paradigme serverless se singularise sur de nombreux aspects en matière de sécurité :

• les fournisseurs de cloud gèrent le système d’exploitation, la sécurité d’exécution et les correctifs. Ce qui est une garantie, étant donné l’envergure des prestataires actuels ;
• la nature éphémère et sans état du calcul sans serveur rend la vie des attaquants plus difficile. Le fait que les fonctions serverless vont et viennent, sans mémoire, réduit le risque d’attaques à long terme ;
• la faible taille des briques de code rendrait plus facile leur analyse par les outils de sécurité des CSP.

En contrepartie, cette architecture crée aussi des failles. Chaque fonction devient un point d’attaque potentiel, rendant complexe le travail des providers et la surveillance de leurs serveurs. Il est aussi plus compliqué, pour le CSP comme pour le codeur, d’observer de multiples process et de multiples points d’entrées/sorties.

Les applications classiques ont un périmètre plus clair, l’extérieur et l’intérieur sont clairement distincts. Il est possible d’y placer des sécurités classiques telles que WAF, pare-feu et IDS.

Enfin, il faut noter que les applications cloud natives peuvent utiliser de nombreux modules et bibliothèques avec du code provenant de diverses sources tierces. Les attaquants potentiels pourraient alors s’efforcer d’inclure du code malveillant dans des projets communs.

Comme souvent lorsqu’il s’agit de technologie ou de concept émergent, il faut prendre un peu de recul pour décider de l’adopter ou de la rejeter. Elle ne prend tout son sens que dans un contexte donné.

Au-delà du simple aspect technique, son utilisation peut impacter aussi les ressources humaines de votre organisation. Elle nécessite en effet de s’appuyer sur une solide équipe de codeurs, qu’il faudra peut-être renforcer.

Alors qu’elle peut conduire à abaisser les moyens dédiés aux infrastructures et à leur gestion.

Donc, de fait, même si elle semble destinée à permettre des choix ponctuels, en boostant certains projets, elle peut transformer en profondeur votre DSI et les services qui y sont liés.