Le serverless poursuit sa montée en puissance. Pour la 2ème année, Datadog mesure la progression de ces services cloud qui gèrent dynamiquement l’allocation de serveurs et de ressources pour exécuter des fonctions, le client n’étant facturé que pour ce qu’il a consommé. Dans cette catégorie Function-as-a-service (FaaS), AWS Lambda est le premier arrivé et le plus mature, mais l’adoption rapide du modèle profite aussi à Azure Functions et Google Cloud Functions. Les fonctions serverless sont principalement destinées à exécuter des tâches courtes, des portions de code. Elles ont différents cas d’usage et l’écosystème déborde maintenant le FaaS pour inclure de nombreux services aidant à développer plus vite, de façon plus souple, note l’étude de Datadog mise à jour en mai 2021. Celle-ci compile les données d’utilisation de milliers d’entreprises de sa base de clients en considérant qu’une entreprise a adopté un service FaaS si elle a exécuté au moins 5 fonctions distinctes au cours d’un mois donné.

Premier constat, les fonctions Lambda d’AWS sont invoquées 3,5 fois plus souvent par jour qu’il y a deux ans. Les équipes ne font pas qu’expérimenter le serverless, elles sont en train d’en faire un élément important de leur pile logicielle. Du côté des offres concurrentes, la part d’Azure Functions a progressé de 20 à 36% et celle du service Cloud Functions sur la GCP a atteint 25%. Si Google est le dernier des trois fournisseurs clouds à avoir livré son FaaS, son premier service du genre remonte en fait à App Engine en 2008, rappelle Datadog. Ses utilisateurs se tournent maintenant vers ses offres serverless Cloud Functions et Cloud Run. A noter qu’une organisation sur 5 utilise du serverless dans chacun des trois principaux clouds publics.

60 ms, temps d'invocation médian d'une fonction Lambda

Autre évolution par rapport à l’an dernier sur AWS, les invocations Lambda sont beaucoup plus courtes. Le service est de plus en plus exploité pour les applications de type « customer-facing » (c’est-à-dire directement utilisées par les clients) qui requièrent une faible latence. En 2020, le temps d’invocation médian d’une fonction Lambda a été de 60 ms, soit moitié moins qu’en 2019. Pour Datadog, une des explications pourrait être que, suivant les bonnes pratiques indiquées par le service, les développeurs conçoivent des fonctions très spécifiques à leurs charges de travail, ce qui permet de réduire la durée des appels. Mais d’autres données montrant des temps d’invocation plus longs indiquent que Lambda est également utilisé pour des cas d’usage requérant des calculs plus intensifs.

Chez AWS, un service tel que Step Functions, orchestrateur de fonctions serverless, permet aux développeurs de bâtir des workflows basés sur les événements en mettant en oeuvre différentes fonctions lambda et services AWS. Il organise la gestion d’erreurs, relance les fonctions, etc. pour réduire la complexité du serverless à grande échelle. L’analyse de Datadog indique qu’un workflow Step Functions comporte en moyenne 4 fonctions Lambda, un chiffre en progression régulière. Autre constat, 40% des workflows s’exécutent en moins d’une minute. Ils sont probablement utilisés pour faire du traitement d’événements à haut volume. De nombreux autres s’exécutent sur une journée, les plus longs sur une semaine. Datadog rappelle que Step Functions peut supporter une large gamme de cas d’usage, depuis les requêtes web jusqu’aux gros traitements sur les données.

Le serverless adapté au edge computing

Autre constat remonté de l'analyse des données, un utilisateur sur 4 du CDN CloudFront d’AWS a adopté le serverless, via Lambda@Edge, pour fournir davantage d’expériences personnalisées aux utilisateurs en bout de réseau. Il permet, par exemple, de transformer dynamiquement des images en fonction des caractéristiques du terminal utilisé ou de servir différentes versions d’une application web pour des tests A/B. Il apparaît que 67% des fonctions Lambda@Edge sont exécutées en moins de 20 ms. Cela suggère l’énorme potentiel du serverless pour le edge computing dans le support des applications les plus exigeantes sur la latence, pointe Datadog.

Fin 2019, AWS a lancé « provisioned concurrency » pour réduire les temps d’exécution des fonctions Lambda après une période d’inactivité (démarrage à froid) en gardant les environnements d’exécution prêts à répondre aux requêtes. Il apparaît que plus de la moitié des fonctions utilisent moins de 80% de leur fonction provisioned concurrency configurée tandis que plus de 40% utilisent la totalité de leur allocation, ce qui indique qu’elles peuvent encore rencontrer des problèmes de démarrage à froid et auraient besoin d’utiliser davantage de ressources prêtes à répondre aux invocations. Ces capacités sont surtout exploitées avec les fonctions Java et .Net Core qui démarrent plus lentement, qu’avec Python ou Node.js.

Parmi les autres constats tirés des chiffres analysés par Datadog, le projet open source Serverless Framework est le plus fréquemment employé par les utilisateurs de AWS CloudFormation pour gérer les ressources serverless (plus de 90% déploient Lambda ainsi). Python est le plus populaire des langages d’exécution de Lambda dans les grands environnements (58% des fonctions ainsi exécutées, soit 11% de plus qu’il y a un an), devant Node.js (21%, +8%). Ce dernier le devance dans les petits environnements AWS.