Résultats d’une étude sur l’utilisation du "serverless" (Datadog)

L’éditeur publie les résultats de sa première étude sur « L’utilisation du serverless ». Ils sont le fruit de l’analyse des données d’utilisation de milliers de clients. Ce rapport se concentre sur AWS Lambda, une plateforme serverless, moins de cinq ans après son lancement.

Résultats d’une étude sur l’utilisation du "serverless"

La moitié des utilisateurs d’AWS ont adopté Lambda

A l’aube de 2020, Lambda n’est plus une technologie de niche. Près de la moitié des clients de Datadog qui utilisent AWS ont désormais adopté Lambda (voir dans la méthodologie ci-dessous notre définition de l’adoption de Lambda et de l’utilisation d’AWS). Ce taux d’adoption, ainsi que la répartition de l’utilisation de Lambda par taille d’environnement, montre que Lambda n’est plus limité aux premiers adoptants cloud-natifs ou aux cas d’usage de niche.

Lambda est plus répandu dans les grands environnements

Nous constatons une corrélation claire entre l’adoption de Lambda et l’étendue de l’infrastructure d’une entreprise, que cet environnement soit principalement constitué de serveurs, de conteneurs ou de fonctions serverless. Parmi les entreprises ayant les plus grandes infrastructures, plus des trois quarts ont adopté Lambda.

Les utilisateurs de conteneurs ont afflué vers Lambda

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 (par exemple, les fonctions Lambda utilisées pour déclencher les tâches du service d’Amazon Elastic Container Service), mais beaucoup d’autres organisations les utilisent séparément pour répondre à des besoins différents. Par exemple, une entreprise peut exécuter la majeure partie de son application dans un cluster de conteneurs, tout en déchargeant au serverless des tâches éclatées et de courte durée (telles que le traitement des paiements).

Amazon SQS et DynamoDB font bon ménage avec Lambda

Les utilisateurs de Lambda disposent d’un vaste choix de technologies lorsqu’il s’agit de connecter leurs fonctions aux infrastructures et aux composants d’application. Une fois qu’une fonction est déclenchée, elle envoie souvent les données qu’elle produit à une file d’attente de messages, qui achemine les données vers d’autres fonctions Lambda, des applications basées sur des serveurs ou des services cloud. Les files d’attente de messages aident les organisations à adopter le modèle "ne payez que ce que vous utilisez" du serverless. Au lieu qu’une fonction n’appelle une autre fonction et n’attende une réponse (et accumule du temps d’appel facturable), les fonctions serverless peuvent faire une requête de manière asynchrone via une file d’attente de messages. Et parce que les fonctions sont éphémères et apatrides, elles lisent ou écrivent souvent dans une base distincte de données persistantes. 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.

Node.js et Python dominent parmi les utilisateurs de Lambda

47% de toutes les instances Lambdas 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.

La fonction Lambda dure en moyenne 800 millisecondes

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.

La moitié des fonctions Lambda sont configurées avec une mémoire minimale

Comme mentionné ci-dessus, le coût d’une invocation Lambda correspond au produit de la durée et de la mémoire de la fonction. 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.

Les deux tiers des temps d’arrêt définis sont inférieurs à 1 minute

Chaque fonction Lambda a un paramètre de temps d’arrêt configurable, allant de 1 seconde à 15 minutes maximum. La plupart des fonctions utilisent des arrêts courts, les deux tiers étants 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% des fonctions ont une limite de simultanéité définie

Par défaut, les clients Lambda sont limités à 1.000 exécutions simultanées de toutes les fonctions dans une région donnée. Les utilisateurs peuvent fixer des limites de simultanéité par fonction, ce qui permet de réserver une partie de l’ensemble des exécutions simultanées à une fonction spécifique. Si la fonction dépasse sa limite de simultanéité, elle sera mise au repos. Aujourd’hui, 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.