Le serverless et ses limites : l'expérience d'un éditeur SaaS

Des plafonds de ressources à la gestion des coûts, un éditeur revient sur les obstacles rencontrés dans l’adoption du serverless chez AWS.

Gérer des fonctions Lambda avec Terraform ? Cela peut être suffisamment complexe pour préférer une autre solution. C’est ce qu’a fait Adadot. L’entreprise britannique (à l’origine d’une plate-forme de productivité pour les développeurs) en fait part dans un bilan sur son adoption du serverless.

La démarche, amorcée en 2021, reposait sur trois grands principes :

– Toute API en contact direct avec les clients, nécessitant une réponse rapide et ne traitant pas d’opérations lourdes sera gérée par un serveur
– Tout autre fonction API sera exécutée avec Lambda
– Les autres composantes « compatibles serverless » fonctionneront sur ce mode

Il reste aujourd’hui un serveur d’API et quelques serveurs de base de données… pour environ 200 fonctions Lambda et 100 fonctions Step.

Sans Terraform, des silos informationnels

Le passage à Lambda a fait gagner du temps sur la configuration et le déploiement (Adadot utilise principalement JavaScript et Python), tout en allégeant la réflexion initiale sur le dimensionnement des instances.
Laisser cette partie de l’infrastructure hors du périmètre Terraform a en revanche créé des silos en matière de partage d’informations sur les ressources. À tel point qu’il a parfois fallu coder des identifiants en dur ou utiliser des caractères génériques (wildcards).

Des limites de concurrence…

Adadot s’est aussi trouvé confronté aux limites de montée en charge. En particulier sur la question de la concurrence. Aussi bien fonction par fonction qu’au niveau du compte AWS.
Sur ce dernier point, la limite dans la région de déploiement est à 1000 exécutions parallèles. « Cela peut sembler beaucoup, mais […] c’est facile à atteindre une fois qu’on passe à l’échelle », nous explique-t-on. Face à cet écueil, il a été décidé, d’une part, d’améliorer la mise en cache. De l’autre, de répartir la charge de calcul tout au long de la journée, selon le fuseau horaire des utilisateurs.

… et de ressources mémoire/disque

Autre point de vigilance : les ressources mémoire. En la matière, ce n’est pas tant la limite de 10 Gb par fonction qui a posé problème que le modèle économique associé : coût = quantité de mémoire x temps d’exécution. Or, si la charge n’est pas constante mais qu’elle dépend de paramètres externes (par exemple, le volume de données pour l’utilisateur), cela implique de paramétrer le seuil maximal… « quitte à surpayer 99 % du temps », d’après Adadot.

Des limites, il y en a aussi sur les ressources disque. À moins d’utiliser Fargate, les fonctions Lambda ont une limite de 10 Go par conteneur (et de 75 Go par compte AWS). En fonction du langage utilisé, on peut vite atteindre ce plafond. Adadot pointe Python : « Panda et scipy dans le même Lambda, vous pouvez oublier. »

Lire aussi : AWS Lambda : l’approche de Babbel pour la montée de version

15 minutes, parfois trop court pour une fonction Lambda

La durée maximale d’exécution (15 minutes) a aussi constitué un obstacle. Dans le même esprit que pour les ressources mémoire, dès lors qu’une fonction est susceptible de dépasser ce délai, il faut trouver une solution alternative… ou les fragmenter. Adadot a choisi cette dernière option – ce qui explique en partie que son architecture comprend quelque 200 fonctions – à défaut d’être satisfait de la conservation des journaux par Fargate.

Pour orchestrer les événements, Adadot utilise les fonctions Step. Celles-ci présentent aussi une limite, à 25 000 événements par fonction (hors option Express). De quoi imposer éventuellement un fractionnement.

Sur l’année écoulée, le compteur en est à 17 millions d’invocations de fonctions par mois en moyenne. Sur des serveurs EC2 aux spécifications identiques, cela aurait nécessité 25 instances medium ou 6 xlarge (couvrant les fonctions les plus gourmandes).

Sur le plan financier, Lambda revient plus cher. Mais les équipes d’Adadot consacrent moins de temps à la mise à l’échelle de l’infra. Et celle-ci est plus à même d’absorber les pics de charge. L’éditeur entend toutefois réintégrer de l’EC2 à mesure que les coûts augmenteront et que le trafic deviendra plus prédictible.

À consulter en complément :

Quatre éléments essentiels pour une stratégie multicloud réussie
Comment Lego empile les briques serverless pour rendre ses services incassables
Serverless, l’éloge n’empêche pas la nuance