Electronique Mag - Le journal de l'électronique.
- accueil .
- abonnement .
- newsletter .
Flux RSS . - soumissions .
- publicité .
- contacts
Flux RSS .
Datadog, fournisseur d’une plate-forme de monitoring et d’analyse pour les développeurs, équipes d’exploitation informatique et utilisateurs métiers de l’ère du cloud, 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 de Datadog couvrant un large spectre d’entreprises de toute taille et représentatives de très nombreux secteurs d’activité (détails de la méthodologie ci-dessous) . Ce rapport se concentre sur AWS Lambda, plateforme serverless la plus mature et la plus largement adoptée par les utilisateurs de Datadog et au-delà. Moins de cinq ans après son lancement, AWS Lambda est déjà utilisé par près de la moitié des entreprises disposant d’une infrastructure AWS.
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.
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.
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).
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.
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 luimême.
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.
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.
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.
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.
Population : Pour ce rapport, Datadog a compilé les données d’utilisation de milliers de ses clients, des entreprises de toute taille et de représentatives de très nombreux secteurs d’activité partageant néanmoins certains traits communs. Tout d’abord, elles ont tendance à prendre au sérieux l’infrastructure logicielle et les performances des applications. Elles sont également plus enclines à adopter les plates-formes et les services cloud que la population en général. Tous les résultats présentés dans ce communiqué sont biaisés par le fait que les données proviennent de la base clients de Datadog, un échantillon large mais pas parfaitement représentatif de l’ensemble du marché mondial.
Échelle des environnements : Pour estimer l’échelle relative de l’environnement d’infrastructure d’une entreprise, Datadog a examiné l’utilisation par les entreprises de fonctions serverless, de conteneurs, de serveurs physiques, d’instances dans le cloud et d’autres services d’infrastructure. Bien que la frontière entre les catégories (telles que "moyenne" et "grande") soit nécessairement artificielle, la tendance entre les catégories est claire.
L’adoption Lambda : Dans ce rapport, Datadog considère qu’une entreprise a adopté Lambda si elle a exécuté au moins cinq fonctions Lambda distinctes au cours d’un mois donné. La fonction Datadog Forwarder, qui envoie à Datadog des données telles que les journaux S3 et CloudWatch, est exclue du compte des fonctions Lambda.
Utilisation de l’AWS : Nous considérons qu’une entreprise utilise le système AWS, si elle a géré au moins cinq fonctions Lambda distinctes ou cinq instances EC2 distinctes au cours d’un mois donné. De cette façon, nous pouvons saisir une base d’utilisateurs AWS comprenant des entreprises qui utilisent exclusivement des instances EC2, des fonctions serverless ou un mélange des deux.
