Le serverless est de plus en plus mainstream. Dans une enquête O’Reilly auprès de 1500 professionnels de l’IT en 2019, 40% des répondants travaillaient dans des organisations qui ont adopté l’architecture serverless. Une enquête DataDog en 2020 a indiqué que plus de 50% des utilisateurs AWS utilisent désormais l’offre AWS Lambda Function as a Server (FaaS).
Bien évidemment, si le serverless semble attirer de plus en plus de développeurs et d’organisations, c’est qu’il offre des avantages par rapport au modèle actuel.
Qu’est-ce que le serverless ?
D’abord, voici un petit rappel de ce qu’est le serverless. Pour cela, imaginez si nous voulons configurer un service Web qui a un point de terminaison `/ temp` où les utilisateurs peuvent demander la température d’aujourd’hui. Pour créer ce service, nous devons d’abord configurer un serveur ou un VPS sous Ubuntu, par exemple ― y compris les applications nécessaires pour faire tourner notre service. Ensuite, nous devons utiliser des frameworks ― par exemple Flask ou Node.js ― pour définir l’application qui cherche d’abord la température à une base de données météo publique, à travers une API par exemple, puis renvoie la valeur. Enfin, nous devons créer l’application serveur et la déployer sur notre instance cloud et la faire tourner.
Désormais, avec Serverless, nous pouvons simplement créer une AWS Lambda (ou une fonction GCP) qui joue le rôle de gestionnaire de la “fonction” `/temp`. On peut simplement utiliser l’éditeur en ligne de Lambda pour modifier la fonction Python qui va interagir avec l’API ou la base de données météo et renvoyer la température. Ensuite, il suffit d’utiliser API Gateway de AWS pour acheminer le point de terminaison `example.com/temp` vers notre fonction Lambda.
Le reste est entièrement pris en charge par AWS ― configuration du serveur, mise à l’échelle du système, équilibrage de charge, etc.
Ce qui est encore plus formidable avec le serverless, c’est que votre serveur n’existe pas lorsque personne n’utilise le point de terminaison. Lorsqu’une personne atteint le point de terminaison avec une requête HTTP, AWS met immédiatement à disposition un “serveur” pour vous avec votre Lambda personnalisée attachée pour gérer la requête. Cela veut dire que vous n’avez plus à payer les frais de serveur lorsque personne n’utilise votre service ! Et même lorsque vous deviez payer, le prix n’est que de quelques centimes par million de demandes.
Un autre avantage de Serverless est la maintenance. Normalement, lorsque nous avons nos propres monolithes ou micro-services, nous devons les maintenir correctement, en nous assurant qu’ils sont toujours en ligne. Bien qu’avec l’aide d’outils d’orchestration de conteneurs tels que Kubernetes, Terraform, etc., ce processus est beaucoup plus facile maintenant. Mais quand même, pourquoi voudrais-je gérer tous les services déployés si la plateforme peut s’en occuper ?
Malgré tous les avantages que nous pouvons tirer de Serverless, la transition devient un gros problème. Actuellement, la plupart des solutions existantes nécessitent généralement un type d’hébergement de serveur pour fonctionner. Nous avons également tendance à créer des applications monolithes qui gèrent beaucoup de choses en même temps. Pour passer au serverless, en revanche, il faut essayer de convertir chaque fonctionnalité de serveur en une fonction Lambda stateless ― ce qui signifie que nous ne pouvons pas utiliser de variables globales, de ressources partagées, etc. Le serverless consiste ainsi à décomposer le système en éléments fonctionnels. L’essence de la création de ces applications est d’abord de réduire l’application compliquée en un simple graphique qui modélise le flux de données.
Les avantages du serverless
L’état actuel de serverless est encore en early stage. Certes, presque toutes les grandes plateformes cloud le prennent en charge, mais la part des applications qui l’utilisent est encore faible. À cet égard, il est sans doute nécessaire d’avoir encore quelques années de travail sur l’infrastructure, l’outillage et les bibliothèques partagées pour prouver la valeur et l’efficacité du serverless.
Mais pourquoi investir dans ce nouveau paradigme alors que le cloud “classique” répond amplement à nos besoins ? Voici quelques éléments de réponse.
Avec le serverless, les développeurs seront “obligés” à décomposer leurs applications en des unités indépendantes les unes des autres où chaque unité est spécialisée dans une seule et unique fonctionnalité. En d’autres termes, on va pousser à l’extrême le concept des micro-services. Avec une telle décomposition, chaque unité deviendra comme une pièce du lego qui peut être réutilisée à volonté. Ceci permettra de gagner énormément en temps et en ressources pour les développeurs.
Le serverless va aussi permettre à différents programmeurs de travailler en collaboration sur le même projet même s’ils utilisent des langages complètement différents. Chacun pourrait simplement travailler sur son nœud et le produit final sera construit. Le serverless permet également aux organisations d’embaucher des ingénieurs partout dans le monde. Les ingénieurs peuvent simplement travailler sur leur partie d’une application à distance sans toucher au reste du système. Avec une abstraction aussi puissante, nous pouvons vraiment devenir des nomades numériques et travailler n’importe où.
Les inconvénients du serverless
Bien que le serverless peut être libératoire de plusieurs contraintes, comme discuté un peu plus haut, il peut aussi imposer d’importantes contraintes sur les développeurs. Ainsi, les plateformes serverless, ou du moins avec la façon dont elles sont implémentées pour le moment, se ressemblent peu ou pas au niveau opérationnel à défaut de standardisation de la façon dont les fonctions doivent être écrites, déployées et gérées. Ceci signifie que la migration des fonctions d’une plateforme spécifique à un fournisseur vers une autre prend beaucoup de temps.
La partie la plus difficile de la migration vers le serverless n’est pas celle des fonctions de calcul – qui ne sont généralement que des extraits de code – mais la façon dont les applications sont enchevêtrées avec des systèmes connectés tels que le stockage d’objets, la gestion des identités et les files d’attente. Les fonctions peuvent bouger, mais le reste d’une application n’est pas aussi portable. Certains croient que ceci est dû principalement au fait que ce paradigme est tout récent et qu’avec le temps, la standardisation va s’imposer.
Le serverless peut aussi causer une perte de performance. Ainsi, les fonctions qui n’ont pas été exécutées sur une plateforme particulière auparavant, ou qui n’ont pas été exécutées pendant un certain temps, prennent un certain temps à s’initialiser. Cela est probablement dû au fait que leur code a été déplacé vers un support de stockage moins accessible. Parmi les approches qui permettent de surmonter cet inconvénient est le fait de s’assurer que les programmes essentiels aux performances sont programmés pour s’exécuter à des intervalles fréquents, afin de les garder «frais». Cette approche contredit légèrement, bien sûr, l’affirmation selon laquelle les plateformes serverless sont plus rentables car vous ne payez que pour le temps d’exécution de vos programmes. Les fournisseurs de cloud ont introduit de nouvelles façons de réduire les démarrages à froid, mais beaucoup nécessitent un modèle «scale to one» qui mine la valeur initiale de FaaS.
Cela dit, il est clair que le serverless n’est pas fait ― du moins pour le moment ― pour répondre à tous les besoins. Certaines applications gagneraient à basculer vers ce mode opératoire alors que pour la grande majorité des applications, il est encore trop tôt pour le faire.