En janvier 2020, près de 80 % des organisations AWS qui exécutent des containers avaient adopté Lambda ! Serverless n’est plus un mot vide…

La moitié des utilisateurs AWS ont adopté Lambda ! A l’aube de 2020, Lambda n’est plus une technologie de niche. Près de la moitié des clients Datadog qui utilisent Amazon Web Services ont désormais adopté Lambda.

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é à des usages de niche. Au contraire, les fonctions serverless sont désormais largement utilisées dans une variété d’entreprises avec une empreinte d’infrastructure dans AWS.

Serverless et containers, ensemble

Lambda s’est avéré particulièrement populaire parmi les entreprises qui exécutent des containers dans AWS. En janvier 2020, près de 80 % des organisations AWS qui exécutent des containers ont adopté Lambda. Bien que les fonctions serverless et les containers soient deux environnements très différents, elles ont tendance à être adoptées pour des raisons similaires, telles que la suppression des problèmes d’infrastructure pour la facilité des opérations.

Il existe certains cas d’utilisation dans lesquels Lambda et l’infrastructure de containers sont directement connectées. C’est le cas, par exemple, en utilisant des fonctions Lambda pour déclencher des tâches Amazon Elastic Container Service. Mais de nombreuses autres organisations peuvent les exécuter séparément pour répondre à différents besoins. Ainsi, une entreprise peut exécuter la majeure partie de son application dans un cluster de containers, tout en déchargeant des tâches rapides et à court terme (comme le traitement des paiements) vers des fonctions sans serveur.

Node.js et Python dominent

Parmi les langages et les frameworks disponibles pour les utilisateurs Lambda, deux leaders clairs s’imposent : Python et JavaScript (via Node.js). 47 % des infrastructures Lambda déployées exécutent actuellement Python et 39 % des applications Node.js. Python 3 l’emporte sur Python 2 (en fin de vie) par un facteur de deux pour un.

La popularité des runtimes Lambda Python et Node.js reflète les tendances récentes du développement d’applications ainsi que l’évolution du service Lambda lui-même.

AWS a lancé Lambda en avant-première en 2014 avec Node.js comme premier runtime pris en charge, avant d’ajouter la prise en charge Java et Python en 2015. La prise en charge de C # (via .NET Core), Go et Ruby a été ajoutée plus récemment, en 2018.

Amazon SQS et DynamoDB se marie bien avec Lambda

Les utilisateurs de Lambda disposent d’un large éventail de choix technologiques lorsqu’il s’agit de connecter leurs fonctions à l’infrastructure et aux composants d’application.

Parmi les services appelés ou interrogés dans la même requête qu’une fonction Lambda, Amazon DynamoDB arrive en tête. Le magasin de valeurs-clés et de documents est un ajustement naturel pour les fonctions Lambda, étant donné qu’il s’agit d’un magasin de données hébergé à mise à l’échelle automatique qui promet une faible latence.

Les choix suivants les plus populaires pour les magasins de données dans les cas d’utilisation Lambda sont les bases de données SQL (qu’il s’agisse d’instances Amazon RDS ou de bases de données autogérées) et Amazon S3, respectivement. Amazon SQS (Simple Queue Service) est le premier choix pour une file d’attente de messages dans les requêtes Lambda, suivi par Amazon Kinesis et Amazon SNS (Simple Notification Service). SQS est un choix logique pour les architectures serverless : il est simple à configurer et à mettre à l’échelle, relativement peu coûteux et offre une intégration étroite avec Lambda.