L'utilisation de l'informatique sans serveur a triplé au cours de l'année écoulée

Elle est adoptée par les organisations de toutes tailles, des startups natives du cloud aux grandes entreprises

Grâce à la technologie sans serveur, les équipes peuvent se concentrer sur la mise sur le marché des idées plus rapidement, plutôt que sur la gestion de l'infrastructure, tout en ne payant que ce qu'elles utilisent.

Pour rappel, l'informatique sans serveur ou "serverless computing" est un paradigme de cloud computing dans lequel le fournisseur de serveur gère dynamiquement les ressources allouées au service client. Le prix dépend des ressources effectivement consommées et non des capacités d'un serveur acheté à l'avance. Mais le terme 'sans serveur' ne signifie pas qu'il n'y a pas de serveurs impliqués. Cela signifie qu'ils sont gérés par les fournisseurs et non par les consommateurs. Sans trop penser à leur maintenance, les ressources informatiques sont utilisées comme des services. Les principaux avantages de sans serveur sont le modèle de tarification à l'utilisation, une évolutivité élevée, la disponibilité et un temps réduit pour développer et livrer les fonctionnalités du produit.

Dans ce nouveau rapport, Datadog a examiné des millions de fonctions exécutées par des milliers d'entreprises pour comprendre comment le serverless est utilisé dans le monde réel.

Qu'il s'agisse de tâches à court terme ou d'applications orientées vers l'utilisateur, le serverless alimente un large éventail de cas d'utilisation. AWS Lambda est l'offre de fonctions en tant que service (FaaS) la plus mature et la plus utilisée, mais nous constatons également une croissance impressionnante de l'adoption d'Azure Functions et de Google Cloud Functions. Aujourd'hui, l'écosystème serverless s'est développé au-delà de 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'informatique périphérique sans serveur et les organisations tirent également parti d'AWS Step Functions pour gérer la logique applicative à travers divers composants distribués.

Les fonctions lambda sont invoquées 3,5 fois plus de fois qu'il y a deux ans.

AWS Lambda permet aux développeurs d'innover plus rapidement en créant des applications hautement évolutives sans se soucier de l'infrastructure. Aujourd'hui, les équipes ne se contentent pas d'expérimenter le serverless, mais en font un élément essentiel de leurs piles logicielles. Les recherches de Datadog indiquent que les entreprises qui utilisent Lambda depuis 2019 ont considérablement intensifié leur utilisation. En moyenne, les fonctions étaient invoquées 3,5 fois plus souvent par jour au début de 2021 que deux ans auparavant. De plus, au sein de la même cohorte d'utilisateurs de Lambda, les fonctions de chaque organisation ont fonctionné pendant un total de 900 heures par jour, en moyenne.


Azure Functions et Google Cloud Functions gagnent du terrain

AWS Lambda a peut-être donné le coup d'envoi du mouvement serverless, mais il n'est pas le seul en lice. Azure Functions et Google Cloud Functions ont tous deux vu leur adoption augmenter au sein de leurs plateformes de cloud computing respectives. Au cours de l'année écoulée, la part des organisations Azure qui utilisent Azure Functions est passée de 20 à 36 %. Et sur Google Cloud, près d'un quart des organisations utilisent désormais Cloud Functions. Bien que Cloud Functions ait été la dernière des trois offres FaaS à être lancée, le concept sans serveur n'est pas nouveau dans Google Cloud – la plateforme de cloud computing a lancé Google App Engine, son premier service de calcul entièrement sans serveur, en 2008. Mais aujourd'hui, nous constatons que la dynamique se déplace vers les offres serverless les plus récentes de Google, à savoir Cloud Functions et Cloud Run.


"Quel que soit le framework, le langage ou le cloud que vous utilisez, le serverless peut vous aider à construire et à itérer en toute simplicité. Il y a deux ans, Next.js a introduit une prise en charge de première classe des fonctions sans serveur, qui permet d'alimenter le Server-Side Rendering (SSR) dynamique et les API Routes. Depuis lors, nous avons constaté une croissance incroyable de l'adoption du serverless parmi les utilisateurs de Vercel, avec des invocations passant de 262 millions par mois à 7,4 milliards par mois, soit une multiplication par 28." a déclaré Guillermo Rauch, PDG de Vercel et cocréateur de Next.js.

Les invocations Lambda sont beaucoup plus courtes aujourd'hui qu'il y a un an.

Lambda est de plus en plus utilisé pour alimenter des applications orientées client qui nécessitent une faible latence. En 2020, l'invocation Lambda médiane n'a pris que 60 millisecondes – soit environ la moitié de la valeur de l'année précédente. Une explication possible est que davantage d'organisations suivent les meilleures 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. L'étude révèle également que la queue de la distribution de la latence est longue, ce qui suggère que Lambda n'alimente pas seulement des tâches de courte durée, mais aussi des cas d'utilisation plus intensifs en termes de calcul.


Les Step Functions alimentent tout, des applications web aux pipelines de données.

AWS Step Functions permet aux développeurs de créer des flux de travail pilotés par événements qui impliquent plusieurs fonctions Lambda et services AWS. Dans ces flux de travail, Step Functions coordonne la gestion des erreurs, les tentatives, les délais d'attente et d'autres logiques d'application, ce qui permet de réduire la complexité opérationnelle lorsque les applications sans serveur évoluent. Les recherches indiquent que le flux de travail Step Functions moyen contient 4 fonctions Lambda – et nous constatons que ce nombre augmente de mois en mois.

Step Functions propose deux types de flux de travail : Standard et Express. Plus de 40 % des flux de travail s'exécutent en moins d'une minute, ce qui indique que les entreprises utilisent probablement les flux de travail Express pour prendre en charge des charges de travail de traitement d'événements à fort volume. Mais si de nombreux flux de travail s'exécutent rapidement, d'autres durent plus d'une journée. En fait, les flux de travail Step Function les plus longs durent plus d'une semaine. Les flux Step Functions peuvent inclure des travailleurs d'activité qui s'exécutent sur des instances Amazon ECS ou EC2, par exemple, ce qui signifie qu'ils sont capables de s'exécuter plus longtemps que le délai d'expiration de 15 minutes de la fonction Lambda. Cela permet aux Step Functions de prendre en charge un large éventail de cas d'utilisation, des tâches critiques en termes de latence, comme le traitement des requêtes Web, aux tâches complexes et de longue durée, comme les travaux de traitement des données volumineuses.


Zack Kanter, PDG de Stedi déclare : "Nous utilisons largement AWS Step Functions dans l'ensemble de notre architecture entièrement sans serveur. Elle nous permet de concevoir et d'exécuter des flux de travail fiables qui traitent un volume élevé de transactions sur notre plateforme de commerce B2B, tout en réduisant notre complexité opérationnelle."

Un utilisateur de CloudFront sur quatre a adopté l'informatique périphérique sans serveur.

Le Edge Computing a suscité beaucoup d'intérêt pour sa promesse de traitement plus rapide des données. Aujourd'hui, un quart des entreprises qui utilisent Amazon CloudFront tirent parti de Lambda@Edge pour offrir des expériences plus personnalisées à leur base d'utilisateurs mondiale. Par exemple, Lambda@Edge peut transformer dynamiquement des images en fonction des caractéristiques des utilisateurs (par exemple, le type d'appareil) ou servir différentes versions d'une application web pour des tests A/B.


En exploitant le réseau de sites périphériques de CloudFront, Lambda@Edge permet aux entreprises d'exécuter des fonctions plus proches de leurs utilisateurs finaux, sans la complexité de la mise en place et de la gestion des serveurs d'origine. Les données montrent que 67 % des fonctions Lambda@Edge s'exécutent en moins de 20 millisecondes, ce qui suggère que l'informatique périphérique sans serveur a un énorme potentiel pour prendre en charge les applications les plus critiques en termes de latence avec un minimum de frais généraux. Au fur et à mesure de la maturation de cette technologie, davantage d'organisations devraient s'y fier pour améliorer l'expérience de l'utilisateur final.


Les organisations dépensent trop en Provisioned Concurrency pour une majorité de fonctions.

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. Pour les applications qui requièrent des temps de réponse de l'ordre de la milliseconde, les démarrages à froid peuvent être une cause perdue d'avance. À la fin de 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.

À la lumière des données de Datadog, il semble que la configuration de la quantité optimale de Provisioned Concurrency pour les fonctions Lambda reste un défi pour les utilisateurs. Plus de la moitié des fonctions utilisent moins de 80 % de leur 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 peuvent encore rencontrer des démarrages à froid et qu'elles bénéficieraient d'encore plus de concurrence. La mise à l'échelle automatique des applications offre un moyen de contourner ces problèmes en permettant aux utilisateurs de faire évoluer automatiquement la Provisioned Concurrency en fonction de l'utilisation.


L'on constate également que Provisioned Concurrency est plus souvent utilisé avec les fonctions Java et .NET Core, dont les temps de démarrage sont généralement plus lents que ceux de Python ou Node.js, en raison de la nature inhérente de ces runtimes. Java, par exemple, doit initialiser sa machine virtuelle (JVM) et charger un large éventail de classes en mémoire avant de pouvoir exécuter le code utilisateur.

Le Serverless Framework est le principal moyen de déployer des applications Lambda avec AWS CloudFormation.

À mesure que les applications sans serveur évoluent, 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 (connues sous le nom de piles), et constitue le mécanisme de déploiement sous-jacent pour des cadres tels que AWS Cloud Development Kit (CDK), AWS Serverless Application Model (SAM) et Serverless Framework.

Parmi ces outils, le Serverless Framework open source est de loin le plus populaire. Aujourd'hui, il est utilisé par plus de 90 % des organisations qui gèrent leurs ressources sans serveur avec AWS CloudFormation. Outre Serverless Framework, 19 % des entreprises utilisent AWS CloudFormation, 18 % AWS CDK et 13 % AWS SAM. Notez que comme chaque organisation peut utiliser plusieurs outils de déploiement, la somme de ces valeurs est supérieure à 100 pour cent.


Parmi les piles CloudFormation utilisées dans les applications sans serveur, 65 % ne contiennent qu'une seule fonction Lambda. En outre, plus de la moitié de toutes les fonctions – 57 % – ne sont pas déployées avec CloudFormation. Cela suggère que de nombreuses organisations en sont encore aux premiers stades de l'automatisation et de l'optimisation de leurs flux de travail sans serveur avec l'infrastructure en tant que code. Mais tout comme les orchestrateurs tels que Kubernetes et Amazon Elastic Container Service (ECS) sont devenus essentiels pour gérer de grandes flottes de conteneurs, les outils d'infrastructure en tant que code devraient jouer un rôle plus important dans le déploiement d'applications sans serveur à l'échelle.

Selon Jeremy Daly, directeur général de Serverless Cloud, Serverless Inc. : "Les développeurs et les entreprises construisant des applications plus avancées qui tirent parti des technologies sans serveur, ils ont besoin d'outils plus puissants pour les aider à composer, tester, déployer et gérer leurs services de manière fiable. C'est ce qui a été le catalyseur des projets d'infrastructure en code open source comme le Serverless Framework et AWS CDK. Le Serverless Framework à lui seul a vu les téléchargements passer de 12 millions en 2019 à 25 millions en 2020, nous nous attendons donc à une accélération de l'adoption et de la sophistication de ces outils à mesure que les développeurs continuent à construire davantage avec le serverless."

Python est le runtime Lambda le plus populaire, notamment dans les grands environnements.

Depuis 2018, Lambda offre un support pour six runtimes : Node.js, Python, Java, Go, .NET Core et Ruby. Cependant, Python et Node.js continuent de dominer parmi les utilisateurs de Lambda, représentant près de 90 % des fonctions. Cinquante-huit pour cent de toutes les Lambda déployées utilisent Python (soit 11 points de plus qu'il y a un an), et 31 % utilisent Node.js (soit une baisse de 8 points par rapport à l'année dernière).


En examinant la répartition de l'utilisation du runtime en fonction de la taille de l'environnement, une tendance intéressante est apparue : si Node.js devance Python dans les petits environnements AWS, Python devient de plus en plus populaire à mesure que la taille de l'environnement augmente. Parmi les organisations ayant les plus grandes empreintes AWS, Python est utilisé quatre fois plus souvent que Node.js.


Au mois de mars 2021, les principaux moteurs d'exécution par version sont les suivants :

1. Python 3.x
2. Node.js 12
3. Node.js 10
4. Python 2.7
5. Java 8
6. Go 1.x
7. .NET Core 2.1
8. .NET Core 3.1

Parmi les fonctions écrites en Python, plus de 90 % utilisent Python 3, Python 3.8 étant la version la plus populaire. Python 2.7 a perdu 25 points de pourcentage par rapport à l'année dernière, les utilisateurs migrant de plus en plus vers Python 3. AWS a annoncé son intention d'abandonner la prise en charge de Node.js 10 en mai 2021. Il faut donc s'attendre à une utilisation accrue de Node.js 12 et de Node.js 14, nouvellement pris en charge. Java 8 est cinq fois plus populaire que Java 11 parmi les utilisateurs de Lambda, bien que le support de ce dernier soit disponible depuis fin 2019.

Source : Datadog

Et vous ?

Que pensez-vous de cette étude de Datadog ?
Quel est votre avis sur la technologie serverless ?