Industrie Mag - Le journal de l'industrie.
- accueil .
- newsletter .
Flux RSS . - soumissions .
- publicité .
- contacts
Flux RSS .
Datadog, fournisseur d’une plateforme de monitoring et de sécurité des applications cloud, publie les résultats de la 2ème édition de son étude sur « l’utilisation du serverless ». Elle consiste à examiner des millions de fonctions exécutées par des milliers d’entreprises pour comprendre comment le serverless est utilisé dans le monde réel selon un large éventail de cas d’usage, qu’il s’agisse de tâches à court terme ou d’applications orientées utilisateur. Aujourd’hui, AWS Lambda est l’offre de FaaS (Function as a Service) la plus mature et la plus utilisée, mais l’adoption d’Azure Functions et de Google Cloud Functions connaît également une croissance impressionnante.
Le serverless a gagné en popularité, des startups cloud natives aux grandes entreprises. Aujourd’hui, l’écosystème serverless s’est développé au-delà du FaaS pour inclure des dizaines de services qui aident les développeurs à créer des applications plus rapides et plus dynamiques. Un quart des utilisateurs d’Amazon CloudFront ont adopté l’edge computing et les entreprises tirent également parti d’AWS Step Functions pour gérer la logique applicative à travers divers composants distribués. Quelles sont les huit observations et tendances clés du paysage serverless actuel ?
Parmi les observations du paysage serverless, huit tendances émergent :
Aujourd’hui, les équipes ne se contentent pas d’expérimenter le serverless, mais en font un élément essentiel de leurs piles logicielles. Selon l’étude, les entreprises qui utilisent Lambda depuis 2019 ont considérablement intensifié leur utilisation. Les fonctions étaient en moyenne sollicitées 3,5 fois plus souvent par jour au début de 2021 comparé à deux ans auparavant. De plus, au sein d’un même groupe d’utilisateurs de Lambda, les fonctions de chaque entreprise ont fonctionné en moyenne durant 900 heures par jour.
L’année dernière, la part des entreprises sur Azure utilisant Azure Functions est passée de 20 à 36 % ; et sur Google Cloud, près d’un quart des entreprises utilisent désormais Cloud Functions. Bien que Cloud Functions ait été la dernière des 3 offres FaaS à être lancée, le serverless n’est pas nouveau sur Google Cloud, la plateforme ayant introduit en 2008 Google App Engine, son premier service entièrement serverless. Aujourd’hui, la dynamique se déplace vers les offres serverless les plus récentes de Google, à savoir Cloud Functions et Cloud Run.
Lambda est de plus en plus utilisé pour servir des applications orientées client qui nécessitent une faible latence. En 2020, le temps moyen d’une invocation Lambda n’a pas dépassé 60 millisecondes, soit environ la moitié de la valeur de l’année précédente. Une explication possible est que davantage d’entreprises suivent les bonnes pratiques Lambda et conçoivent des fonctions très spécifiques à leurs charges de travail, ce qui contribue à réduire la durée des invocations.
AWS Step Functions permet aux développeurs de créer des workflows liés aux événements qui impliquent plusieurs fonctions Lambda et services AWS. Dans ces workflows, Step Functions coordonne la gestion des erreurs, les tentatives, les temps d’arrêt et autres logiques applicatives, ce qui permet de réduire la complexité opérationnelle à mesure que les applications serverless évoluent. Selon l’étude, un workflow Step Functions contient en moyenne 4 fonctions Lambda, une moyenne qui augmente de mois en mois.
Un quart des entreprises qui utilisent Amazon CloudFront tirent parti de Lambda@Edge pour fournir davantage d’expériences personnalisées aux utilisateurs du monde entier. Par exemple, Lambda@Edge peut transformer dynamiquement des images basées sur les caractéristiques d’un utilisateur (ex : type d’appareil) ou servir différentes versions d’une application web pour des tests A/B. Les données de l’étude montrent que 67% des fonctions Lambda@Edge sont exécutées en moins de 20 millisecondes, ce qui laisse supposer que l’edge computing a un énorme potentiel pour prendre en charge, avec un minimum de ressources, les applications les plus critiques en termes de latence. De notre point de vue, plus cette technologie évolue, plus elle semble adoptée par différentes organisations cherchant à améliorer leur expérience utilisateur.
Lorsqu’une fonction Lambda est invoquée après une période d’inactivité, elle subit un bref retard d’exécution, connu sous le nom de démarrage à froid (cold start). Pour les applications qui requièrent des temps de réponse de l’ordre de la milliseconde, les démarrages à froid peuvent être rédhibitoires. Fin 2019, AWS a introduit Provisioned Concurrency pour aider les utilisateurs de Lambda à lutter contre les démarrages à froid en maintenant les environnements d’exécution initialisés et prêts à répondre aux demandes.
Plus de la moitié des fonctions Lambda utilisent moins de 80 % de leur fonction Provisioned Concurrency configurée. Dans le même temps, plus de 40 % des fonctions utilisent la totalité de leur allocation, ce qui signifie qu’elles sont encore susceptibles de rencontrer des démarrages à froid. pourraient encore rencontrer des démarrages à froid et qu’elles bénéficieraient encore davantage de la fonction Provisioned Concurrency.
Lorsque les applications serverless passent à l’échelle, le déploiement manuel des fonctions Lambda et d’autres ressources peut rapidement devenir fastidieux. AWS CloudFormation permet aux développeurs de provisionner l’infrastructure AWS et les ressources tierces dans des collections (appelées piles logicielles), et constitue le mécanisme de déploiement sous-jacent pour des frameworks, tels qu’ AWS Cloud Development Kit (CDK), AWS Serverless Application Model (SAM) et Serverless Framework.
Framework est de loin le plus populaire en étant utilisé par plus de 90% des entreprises qui gèrent leurs ressources serverless avec AWS CloudFormation.
Depuis 2018, Lambda prend en charge 6 langages d’exécution : Node.js, Python, Java, Go, .NET Core, and Ruby. Cependant, Python et Node.js continuent à dominer comptant pour l’exécution de près de 90% des fonctions Lambda. 58% des fonctions Lambda déployées sont exécutées avec Python, soit 11% de plus qu’il y a un an, et 21% avec Node.js, soit 8% de plus qu’il y a un an.
Tandis que Node.js devance Python dans les petits environnements AWS, Python devient de plus en plus populaire lorsque la taille de l’environnement augmente avec une utilisation 4 fois supérieure à celle de Node.js.
Méthodologie :
Pour réaliser cette étude, Datadog a compilé les données d’utilisation de milliers d’entreprises de sa base de clients. Si ses clients couvrent tout l’éventail des tailles d’entreprises et des secteurs d’activité, ils partagent certaines caractéristiques communes. Tout d’abord, ils sont attentifs à leur infrastructure logicielle et aux performances de leurs applications, et sont plus enclins à adopter des plateformes et services cloud que le reste de la population. Tous les résultats présentés dans cet article sont biaisés par le fait que les données proviennent de la base de clients de Datadog, un échantillon important mais imparfaitement représentatif de l’ensemble du marché mondial.
Cette étude considère qu’une entreprise a adopté AWS Lambda, Azure Functions ou Google Cloud Functions si elle a exécuté au moins 5 fonctions distinctes au cours d’un mois donné. La fonction Datadog Forwarder, qui envoie à Datadog des données, telles que les logs S3 et CloudWatch, a été exclue du décompte des fonctions.
L’étude considère qu’une société utilise un fournisseur de cloud (AWS, Google Cloud, ou Microsoft Azure) si elle exécute au moins 5 fonctions serverless distinctes ou 5 machines virtuelles (VMs) dans un mois donné. Il est alors possible de capter une base d’utilisateurs de fournisseurs de cloud, qui comprend des entreprises exécutant exclusivement des VMs, exclusivement des fonctions serverless, ou un mélange des deux.
