Plus flexible, moins cher : le serverless est la prochaine étape du cloud
Depuis trois ans, les offres "sans serveur" des grands noms du cloud connaissent un réel engouement. L'occasion de revenir sur la philosophie de ce nouveau concept.
Comment résumer le principe de serverless ?
Comme son nom l'indique, la notion de serverless (ou sans serveur) consiste à exécuter le code d'une application sans avoir à configurer les serveurs physiques ou machines virtuelles nécessaires, ni à les superviser, les mettre à jour ou les "patcher". Le développeur s'affranchit ainsi des contraintes de l'infrastructure IT et se concentre sur son travail. A la charge du fournisseur de cloud d'assurer toute l'intendance, le dimensionnement des ressources machines en fonction du trafic, et l'équilibrage de charges (ou load balancing).
L'exécution du code est lancée via ce qu'on appelle des "fonctions" en réponse à des événements. Par exemple, lorsqu'une page web est sollicitée (via une requête HTTP), une fonction déclenchera l'exécution du code et des services associés comme l'authentification utilisateur, l'envoi d'un message ou l'interrogation d'une base de données. D'où l'appellation de "Function as a Service" (FaaS) souvent attribuée à ce type d'offre.
Pourquoi faut-il s'intéresser à ce concept ?
Le serverless répond, de fait, à un certain nombre de problématiques du moment. En faisant abstraction des contingences de l'infrastructure, il pousse la virtualisation un cran plus loin, après les stades de la machine virtuelle et du container applicatif. Le serverless s'inscrit, par ailleurs, dans la tendance des micro-services. On peut même parler de nano services puisqu'il descend plus bas dans la granularité, une fonction n'étant qu'un bout de code, une toute petite partie de l'application.
L'adoption du serverless participe également à l'amélioration de la qualité du code. "Créer des fonctions et les orchestrer entre elles nécessite une très bonne tenue de la gestion du code source", assure Nicolas Clément, architecte SI chez Magellan Consulting. Pour évoquer le serverless, on parle même de "code as a function". Le développeur se concentrant sur son code, le délai de mise en production de l'application est raccourci.
Pour autant, le serverless ne veut pas dire la fin des équipes opérationnelles (ou ops) au sein des départements DevOps. "Les métiers de la production informatique verront leur rôle évoluer. Il s'agira notamment pour eux de gérer le monitoring de l'application", rassure Gauthier Wallet, consultant DevOps au sein de la société de services D2SI (groupe Devoteam).
Quels sont les avantages du serverless ?
Outre une meilleure sécurisation du code, le serverless offre d'autres avantages et notamment une meilleure tolérance aux pannes et une mise à l'échelle automatique (autoscaling). L'utilisateur n'a pas à gérer un cluster de serveurs, son fournisseur lui garantit une haute disponibilité quels que soient les pics de trafic.
Le serverless présente aussi un intérêt économique. Exit l'allocation de machines virtuelles, la facturation se cale sur le temps d'exécution du code et les ressources réellement consommées. Avec la milliseconde comme unité de paiement, le serverless tient réellement les promesses du "pay as you go". En l'absence de trafic, l'utilisateur ne paie pas. Là encore, l'optimisation de la performance du code prend tout son sens. Réduire le temps d'exécution d'une application serverless de 20 à 10 millisecondes fait mécaniquement baisser la facture en fin de mois.
Quelles sont les applications éligibles au serverless ?
On l'a vu, le serverless est nativement conçu pour les applications bâties sur des micro-services. A contrario, il est moins adapté aux applications monolithiques, à moins de les refondre et de les découper en tâches indépendantes dans l'esprit des méthodes agiles.
Le serverless est lié aussi au mode événementiel. Il est par conséquent typiquement adapté au traitement par lots (batch), mais aussi à la gestion séquentielle de l'internet des objets (qui peut accepter des temps de latence dans les remontées d'informations). Autre cas d'école : l'analyse des parcours des internautes enregistrés par un traqueur placé sur un site web. Plus généralement, les applications basées sur une chaîne de traitements de données avant de déclencher une action (récupérer un fichier, envoyer un mail...) se prêtent à l'exercice.
Pour Steve Houël, solution architect au sein du cabinet de conseils Ippon, l'éligibilité d'une application au serverless est conditionnée par le temps de chargement du code puis de son exécution. "Au regard du mode de facturation, un 'cold start' qui s'éternise peut être rédhibitoire", pointe-t-il. D'autant que les providers de cloud limitent généralement le temps d'exécution d'une fonction à 5 minutes.
Quelles sont les limites du modèle ?
Les contraintes de temps d'exécution du serverless peuvent se révéler handicapantes pour l'exécution d'une tâche lourde et complexe (traitement vidéo, calcul scientifique...). Plus généralement, les applications qui ont un trafic constant sortent du cadre.
Le serverless accroit, par ailleurs, la dépendance au provider cloud. Les fournisseurs affichant des approches et niveaux de maturité différents, la migration d'une plateforme à l'autre ne se fait pas sans difficultés, au-delà du coût que cette bascule représente. Les fournisseurs ne supportent pas les mêmes langages de programmation.
Enfin, se pose la question de la sécurité. En multipliant les services serverless, un utilisateur augmente l'empreinte de son application sur le web et donc sa surface de risques. Derrière le serverless, il y a aussi des containers, ce qui renvoie aux interrogations lancinantes sur la fiabilité de Docker.
Quels sont les principaux acteurs de ce marché ?
Amazon Web Services (AWS) a ouvert le marché avec Amazon Lambda fin 2014. Depuis, son offre s'est considérablement enrichie. Le label serverless a depuis été apposé par le groupe sur un grand nombre de ses services. Dans le sillage d'AWS, Microsoft commercialise une offre serverless (Azure Functions) depuis fin 2016. Quant à Google, il propose pour l'heure une solution en bêta (Google Cloud Functions). Derrière ces grands noms du cloud public, d'autres acteurs ont suivi, comme IBM ou encore OVH en France.
Pour Gauthier Wallet, les technologies rattachées au serverless existaient cependant bien avant l'avènement d'Amazon Lambda. "Les providers font du serverless depuis plus longtemps notamment dans le domaine des CDN (pour Content delivery network ndlr). Le marché s'est simplement accordé autour d'un terme marketing pour désigner ce type de technologie", insiste l'expert.
Et Luc Germain, directeur cloud, ops & digital workplace chez Devoteam, d'ajouter : "les grands acteurs du cloud américains se livrent dès lors à une guerre tarifaire sur ce terrain. Et ça ne devrait pas s'arrêter là, notamment du fait de l'arrivée de nouveaux entrants sur le segment, comme Alibaba Cloud."
Mais le champ du serverless ne se limite pas au FaaS. Il recouvre aussi des services managés clés en main, de type "Backend as a service" (ou BaaS), conçus par des éditeurs tiers. Auth0 propose ainsi une offre serverless d'identification des utilisateurs, et Twilio une offre équivalente pour gérer l'envoi de SMS.
Une alternative open source ?
En marge des offres payantes, on trouve des frameworks serverless open source comme OpenWhisk, OpenLambda, ou OpenFass (sur OpenShift). Ces solutions animées par des communautés de contributeurs plus ou moins actives permettent de faire du serverless sur n'importe quelle plateforme, y compris sur des clouds privés. "Ces solutions présentent des services équivalents aux solutions commerciales, mais on perd, dans un cloud privé, une des promesses du serverless qui est la mise à l'échelle automatique des ressources machines", tempère Steve Houël. A noter qu'Oracle a présenté, en octobre, une plateforme serverless open source. Baptisée Fn, elle s'appuie sur Docker et supporte Java. Elle peut tourner sur différents cloudd afin d'éviter la dépendance à un fournisseur particulier.