Le spécialiste du monitoring et de l’analyse des actifs informatiques a rendu publique une étude réalisée sur sa base installée concernant l’utilisation du serverless. Principal enseignement de l’étude, Lambda est le grand gagnant auprès de ses utilisateurs.
Près de la moitié des clients de Datadog présents sur AWS utilisent Lambda. Cet outil est sorti de son utilisation de niche et est utilisé par tout type d’entreprise et dans tout type de secteur d’activité.
Le logiciel ne se cantonne plus seulement aux utilisations nativement Cloud. Plus l’infrastructure informatique est importante et plus il est utilisé, et ce que ce soit sur des serveurs, des containers ou des fonctions serverless.
En janvier 2020, près de 80 % des organisations exécutant des conteneurs dans AWS avaient adopté Lambda.
Bien que les fonctions serverless et les conteneurs soient deux environnements très différents, ils ont tendance à être adoptés pour des raisons similaires, telles que ne pas devoir se soucier de la gestion d'infrastructure pour le bon déroulement des opérations. Dans certains cas d'utilisation, les infrastructures Lambda et les conteneurs sont directement connectés.
Amazon en tête
Parmi les services qui sont appelés ou interrogés dans la même requête qu'une fonction Lambda, Amazon DynamoDB arrive en tête. Les autres choix les plus populaires sont les bases de données SQL et Amazon S3. Amazon SQS (Simple Queue Service) est le premier choix pour une file d'attente de messages dans les requêtes Lambda.
47% de toutes les instances Lambda déployées tournent actuellement en Python, et 39% en Node.js. Python 3 surpasse Python 2 (qui a atteint sa fin de sa vie en janvier 2020) par un facteur de deux pour un. La popularité des exécutions Lambda en Python et en Node.js reflète les tendances récentes en matière de développement d'applications et d’'évolution du service Lambda lui-même.
Une vue du logiciel de Datadog dans l'analyse d'une fonction serverless.
Une fonction Lambda dure en moyenne 800 millisecondes, mais la queue de la distribution de la latence est longue. Un quart des fonctions Lambda ont un temps d'exécution moyen de plus de 3 secondes, et 12 % prennent 10 secondes ou plus. L’étendue de certaines fonctions Lambda se remarque car la latence serverless a un impact non seulement sur les performances de l'application mais aussi sur les coûts du cloud.
La tarification Lambda est basée sur les "Go-secondes" de temps de calcul : la mémoire allouée à la fonction multipliée par la durée de ses invocations. Ainsi, les entreprises qui utilisent Lambda sont incitées à limiter l'allocation de mémoire de leurs fonctions (qui est un paramètre configurable et donc plus facile à contrôler que la durée de la fonction). En effet, 47 % des fonctions sont configurées pour fonctionner avec une mémoire minimale de 128 Mo. En revanche, seulement 14 % des fonctions ont une allocation de mémoire supérieure à 512 Mo, même si les utilisateurs peuvent allouer jusqu'à 3 008 Mo par fonction.
La plupart des fonctions utilisent des arrêts courts, les deux tiers étant des configurations de 60 secondes ou moins. Le temps d’arrêt par défaut lors de la création d'une fonction est de 3 secondes. Des délais courts sont souvent conseillés, à la fois parce que l'interruption des fonctions peut entraîner des coûts de cloud et parce que les architectures d'application Lambda nécessitent souvent une réponse rapide. Seulement 4,2 % de toutes les fonctions ont une limite de simultanéité configurée, même si la plupart des organisations connaissent cette option.
Au bilan, si Lambda connaît une adoption grandissante, les utilisateurs ne profitent pas de toutes les fonctions mises à leur disposition pour configurer et optimiser l’outil. Il est en quelque sorte devenu un outil pratique pour les développeurs d’applications qui ne se soucient plus de l’infrastructure sous-jacente.