Une nouvelle étude signée Datadog dévoile les usages et pratiques actuelles du Serverless en entreprise. Une chose est sûre, le Function as a Service séduit de plus en plus…

Le Serverless est une des grandes tendances du moment en matière de développement et de déploiement de logiciels. Même si le terme revêt différentes approches radicalement différentes, l’élimination du besoin de provisionner et gérer les composantes d’infrastructures (serveurs, bases de données, réseau, bus de messages, montée en charge et même les containers) communes à toutes séduit les équipes de développement qui peuvent, plus que jamais, se focaliser sur leur code et leurs fonctionnalités sans se soucier le moins du monde de la plomberie sous-jacente. Il en résulte des équipes plus productives, une notable amélioration de la fiabilité dans les déploiements et dans l’exécution, et d’une manière générale une plus grande agilité de l’entreprise à concrétiser ses idées et ses projets.

Une large adoption

Datadog vient de publier les résultats d’une étude qui limite volontairement son analyse à l’approche Serverless FaaS (Function as a Service) et plus particulièrement à son usage au travers d’AWS Lambda. Les autres clouds fournissent des solutions FaaS tout aussi avancées à l’instar d’Azure Functions ou de Google Cloud Functions, mais DataDog a choisi de les ignorer peut-être par manque de données. De toute façon, l’étude ne s’intéresse pas aux choix technologiques mais plutôt à la façon dont les entreprises apprivoisent peu à peu le FaaS.

La première constatation clé de l’étude est que la moitié des utilisateurs d’AWS ont également adopté Amazon Lambda et donc le service FaaS d’AWS. Ce qui prouve selon l’étude que « Lambda n’est désormais plus uniquement adopté par les early adopters ‘cloud native’ et les cas d’usage ‘niches’ ».

L’étude montre clairement qu’en deux ans, le concept du FaaS est passé au sein des entreprises du stade expérimental ou de curiosité à un usage bien plus large auprès d’une grande variété d’entreprises ayant déjà une partie de leur infrastructure dans AWS.

D’ailleurs, l’étude montre que contrairement à bien d’autres technologies nouvelles d’AWS, ce ne sont pas les startups et les petites entreprises agiles qui sont les plus séduites par Lambda. Les rapporteurs de l’étude constatent « une corrélation claire entre l’adoption de Lambda et l’échelle de l’environnement d’infrastructure d’une entreprise, que cet environnement soit principalement des serveurs, des conteneurs ou des ‘fonctions sans serveur’. Parmi les entreprises avec les plus grandes empreintes d’infrastructure, plus des trois quarts ont adopté Lambda. »

Pas de guerre FaaS versus CaaS

En matière de Serverless, on oppose fréquemment les approches « Functions as a Service », dans lesquelles les développeurs déposent directement du code source pour réagir à des événements sur le service serverless sans se soucier de compilation et de déploiement, aux approches « Container as a Service » où les développeurs déposent directement leurs containers sur le service sans se soucier de clusters de déploiement et autres plomberies façon Kubernetes.

Mais cette opposition n’a apparemment pas de réalité au sein des entreprises. Selon l’étude, près de 80% des organisations AWS qui exécutent des conteneurs (sur AWS EKS ou sur AWS Fargate) ont également adopté Lambda. Et cela a du sens. Après tout, les deux approches séduisent et sont adoptées pour une raison très similaire : se défaire des problématiques d’infrastructure.

En outre, l’étude rappelle qu’« il existe certains cas d’utilisation dans lesquels Lambda et l’infrastructure de conteneur sont directement connectées (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. Par exemple, une entreprise peut exécuter la majeure partie de son application dans un cluster de conteneurs, tout en déchargeant des tâches rapides et à court terme (comme le traitement des paiements) vers des fonctions sans serveur ».

Données et messages

Les applications Serverless façon FaaS ont comme presque toutes les applications classiques besoin à la fois de base de données et de gestion de messages. Et il n’est guère surprenant de découvrir que les développeurs privilégient les offres ‘as a service’ elles aussi très ‘serverless’ du cloud qui leur fournit l’infrastructure FaaS. Typiquement la base de données favorite des fans de Lambda n’est autre qu’Amazon DynamicDB, la database serverless d’AWS.

De même, les fonctions, une fois déclenchées par un événement, envoient souvent leurs données vers d’autres fonctions et utilisent pour cela un gestionnaire de messages qui évite que la fonction appelante n’attende la réponse de la fonction appelée. Ce qui raccourcit ainsi le temps d’exécution de chaque fonction, un point essentiel dans un univers où l’on paye ce que l’on consomme à l’exécution. Là encore le gestionnaire de messages le plus exploité par les développeurs Lambda n’est autre que Amazon SQS (Simple Queue Service).

Quel langage de prédilection ?

Lambda a la particularité de supporter de nombreux langages de programmation. Autrement dit, chaque développeur a le choix entre plusieurs langages différents pour développer ses fonctions qu’il confiera ensuite à l’infrastructure serverless.

L’étude montre que deux langages ont largement la prédilection des développeurs Lambda : Python et JavaScript (via Node.js) : 47% des fonctions déployées sur AWS Lambda sont en Python et 39% sont des fonctions en Node.js.
Il est vrai cependant que le support de C#, Go et Ruby par Lambda est relativement récent puisqu’il a à peine plus d’un an.

Conditions d’exécution des fonctions

Dans l’univers FaaS, l’entreprise ne paye que lorsque les fonctions s’exécutent. DataDog a calculé que la moitié des fonctions hébergées sur Lambda s’exécute en moins de 800 ms, avec 1 fonction sur 5 qui s’exécute en moins de 100 ms et environ 1 sur 3 en 400 ms.

Toutefois, l’étude rappelle que l’une des particularités du FaaS est que les fonctions les moins utilisées peuvent avoir un temps de latence très long au démarrage. Datadog a calculé qu’un quart des fonctions Lambda mettent ainsi 3 secondes à démarrer et s’exécuter et qu’environ 12% des fonctions mettent plus de 10 secondes.

La consommation mémoire est également importante puisqu’elle est facturée à l’exécution. Ainsi, 47% des fonctions se contentent de l’allocation minimale (128 Mo). Et seulement 14% des fonctions ont une allocation mémoire supérieure à 512 Mo. Pour rappel, une fonction Lambda peut allouer jusqu’à 3 Go de mémoire.

Autre réglage, le nombre d’instances concomitantes d’une fonction peut être manuellement spécifié par les développeurs pour éviter des montées en charge incontrôlées et potentiellement trop coûteuses. Lambda supporte 1000 exécutions simultanées par région. Apparemment, les entreprises font plutôt confiance aux réglages par défaut. Seulement 4,2% des fonctions ont un tel réglage manuellement défini. Ne pensez pas que les entreprises ignorent l’existence de ce réglage, puisque 88% d’entre elles ont au moins 1 fonction avec ce réglage manuellement ajusté.

L’étude Datadog est l’une des premières à offrir ainsi une vision détaillée de l’usage du serverless façon « Functions as a Service » en entreprise. Elle est instructive mais on regrettera son spectre limité à AWS. Il serait intéressant de voir comment l’adoption du FaaS se concrétise chez les autres hyperscalers.