Le Serverless est un modèle dans lequel le fournisseur de services cloud (AWS, Azure, Google Cloud ou IBM) est responsable de l’exécution d’un morceau de code en allouant de manière dynamique les ressources, souvent défini par “Functions-as-a-service”.
Chez AWS, ce service est connu sous le nom de Lambda. C’est un code qui tourne dans une micro VM (Firecracker) qui à son tour se termine après quelques minutes d’inactivité. Chaque fonction lambda est caractérisée par son temps d'exécution (calculé en ms) et sa mémoire consommée (Go).
Les architectures serverless nous offrent de nombreux avantages. D’une part, on n’a plus à gérer ou provisionner l'infrastructure nécessaire pour faire tourner nos applications. D’autre part, on ne gère pas la mise à l'échelle horizontale des applications car elle est gérée automatiquement par le fournisseur et de manière transparente. Ainsi, le serverless permet de nous concentrer plus sur le développement de nos applications métier sans nous soucier de l’infrastructure.
Dans le monde Serverless, la facturation se base sur le nombre d’invocations, le temps d'exécution des lambdas et la mémoire consommée. Dans certains cas, une architecture serverless permet de réduire la facture à des pourcentages très importants par rapport à une architecture Cloud sans serverless.
L’analyse des coûts est devenue une partie intégrante de l’architecture logicielle et c’est l’un des 5 piliers du “Well-Architected Framework” développé par AWS . Aujourd'hui, un solution architect doit bien comprendre les coûts visibles et cachés d’une architecture Cloud car l'orientation FinOps des architectes ne peut pas être mise au second plan. L'aspect financier est mis sur un pied d'égalité avec les caractéristiques techniques des services.
#Vue d’ensemble des coûts d’une architecture Serverless
La facturation des lambdas peut s'avérer un peu complexe à prédire ou à calculer très précisément. Les deux caractéristiques qui définissent le coût des fonctions lambdas sont :
La taille mémoire (en Go) : C’est la configuration de la taille maximum mémoire allouée pour l'exécution d’une fonction lambda depuis la console AWS. Même si votre lambda peut consommer moins en réalité, la facturation se base tout de même sur la valeur de cette configuration.
Le temps d'exécution (en ms) : C’est le temps nécessaire pour l'exécution d’une lambda, et qui est arrondi au multiple de 100 ms le plus proche. Par exemple, si votre lambda fait un appel API et attend de recevoir la réponse, ce temps sera inclus dans le temps d'exécution.
Pour calculer le coût d’une lambda, les deux valeurs sont multipliées pour produire l’unité Go-sec. AWS se sert de cette valeur en Go-sec pour facturer le coût d’une lambda. En résumé la tarification lambda chez AWS se présente comme suit:
- Compute : 0.00001667$ par invocation
- Requêtes : 0.2$ par 1 million de requêtes.
Prenons l’exemple simple suivant d’une architecture serverless d’un site de gestion de votes.
Supposons que cette application sert 2 millions d'utilisateurs par mois et que la région de référence utilisée est US-east-1. Nous allons analyser les coûts de chaque brique logicielle sans tenir compte de l’offre d’essai AWS.
- API Gateway: Le prix est de 3.50$ par million de requêtes + les charges de transfert de données. En supposant qu’on a 1,5 Go de cache en mémoire et 2 millions de requêtes par mois, le coût total est de 34,36$
- AWS Lambda: Les lambdas sont exécutés 2 millions de fois chacune à une mémoire de 256 MB avec des temps d'exécution de 400 ms et 500 ms respectivement. Sachant que AWS offre gratuitement le premier million de requêtes + 400000 GO-secondes tous les mois, le coût total des lambdas revient à 0.20$ + 0.20$ = 0.40$
- DynamoDB: Le coût total facturé par DynamoDB est de 2,81$
- Amazon S3: Le Bucket nous sert pour stocker notre site statique de résultat. Avec 1 Go de stockage sur S3, cela coûte 0,02$
- Cloudwatch Logs: Le coût total de l’ingestion de 200MB de données est de 1,59$.
En résumé, voici la tarification totale de cette application.
En analysant les coûts, on remarque que les lambdas ne coûtent presque rien par rapport au coûts de l’API Gateway. Ainsi, Les coûts invisibles de l’architecture sont:
- API Gateway: avec un coût de 3,5$ par million de requêtes
- Transfert de données sur le réseau: Cela coûte 0.05$ - 0.09$ par Go sortant et 0.1$ - 0.2$ pour les données qui transitent entre les VPCs/régions AWS. Ceci peut engendrer beaucoup de frais supplémentaires et rendre l’architecture coûteuse car ce sont des coûts cachés et difficiles à prévoir ou même à estimer.
#AWS Lambda vs EC2: Comparaison des prix
Depuis l’apparition du serverless, on commence à se poser la question du choix entre le serverless et un développement classique sur un EC2. D’un point de vue facturation, faisons une petite comparaison entre deux cas d’usages simples.
Faible taux de calcul
Pour des cas d’usages avec un faible taux de calcul par exemple: transformations après upload, lecture/écriture d’un base de données… Supposons que notre application gère 20000 exécutions/mois avec une mémoire allouée de 512 MB et un temps d'exécution d’une seconde. Par conséquent, notre application consomme 20000*512/1024=10000 Go-sec, ce qui revient à 10000*0,00001667=0,1667$. Si on ajoute les frais de requêtes 0,2*20000/1000000=0,004$ , le coût total devient 0,1667$ + 0,004$ = 0,1707$ .
D’autre part, si on calcule les frais d’une petite EC2 de taille t2.nano (région eu-west-1), le coût total mensuel est de 0,0063*24*30= 4,536$.
Haut taux de calcul
Pour des cas d’usages nécessitant beaucoup de calcul (traitement vidéo ou données temps réel par exemple), supposons que notre application gère 30 millions de requêtes avec une mémoire allouée de 2496 MB et un temps d'exécution de 500 millisecondes par lambda. Par conséquent, notre application consomme 30000000*0,5*2048/1024=30000000 GB-sec, ce qui revient à 30000000*0,00001667=500,1$. Si on ajoute les frais de requêtes 0,2*30000000= 6$, le coût total devient 609,5$ + 6$ = 615,5$.
D’autre part, le coût total d’un EC2 de taille m4.xlarge est de 0,222*24*30= 159,84$.
Les lambdas sont moins intéressantes financièrement lorsque l’on a des jobs qui nécessitent beaucoup de capacité compute. Comme indiqué dans les exemples précédents, serverless est plus adapté à des fonctions qui s'exécutent rapidement. Pour cela, il faudra bien étudier le cas d’usage et évaluer en termes de coûts et d’adaptabilité si le serverless est bien rentable.
#Quelques bonnes pratiques pour optimiser les coûts
Attention au Cold Start
Le cold start est considéré comme la raison principale de la non adoption du serverless par certaines entreprises, surtout s’il y a de fortes exigences de latence. Ceci peut ajouter éventuellement un temps d'exécution supplémentaire (quelques centaines de ms) à celui de la lambda, ce qui peut engendrer des coûts additionnels si le coldstart dépasse les 10s. Il est important de préciser que le coldstart est variable selon le langage de développement choisi.
Prendre en considération les coûts de transfert et stockage.
Il est important de prendre en considération ces coûts (cachés) sachant que c’est difficile à prévoir. Dans certains cas d’usage où il y a plusieurs GO de données sortant, la tarification peut être très élevée.
Optimiser son code et choisir la bonne configuration de mémoire.
Il faut veiller à optimiser le temps d'exécution de son code afin d’optimiser sa facturation. De plus, il faut bien configurer la valeur de mémoire à utiliser car le nombre de CPU utilisé par la lambda est fonction de la mémoire choisie. AWS propose un outil (Calculateur du coût de la lambda) pour calculer/prévoir le coût de la lambda en fonction du nombre d'exécutions, la mémoire et le temps d'exécution.
Remplacer l’API Gateway.
Si vous constatez que votre architecture consomme beaucoup au niveau de l’API Gateway, vous pouvez invoquer vos lambdas avec un ALB “Application Load Balancer”. C’est l’une des annonces de l’AWS Re-Invent 2018 et qui vise principalement à réduire les coûts de l’API Gateway. Une autre solution est de développer votre propre “API wrapper” sur une EC2. Ainsi, vous pouvez invoquer les lambdas en utilisant les SDK AWS.
Mettre en cache les réponses des API Gateway.
Si vos utilisateurs demandent un contenu peu fréquent, il serait avantageux d’activer le cache sur l’API Gateway afin d'éviter des invocations inutiles et ainsi vous pouvez optimiser votre facture.
Monitorer les coûts.
Il est très recommandé d’utiliser un outil de monitoring de coûts pour suivre la facturation d’une architecture. De plus, il est très important d’utiliser des tags ressources et des tags de répartition de coûts afin d’effectuer un suivi détaillé de votre facturation sur AWS. Pour ce faire, vous pouvez utiliser l’outil disponible sur la console AWS Cost Explorer ou l’outil Teevity pour des ressources Cloud en général, ou bien utiliser l’un des outils suivants plus spécifique à Serverless :
#Conclusion
En résumé, les architectures serverless présentent un fort potentiel en termes de réduction de coûts et un gain en temps de développement. Par conséquent, il est important d’analyser les coûts au préalable afin d’éviter quelques surprises, et surtout évaluer la plus-value que peut apporter le serverless à votre application. Toutefois, il est plus important d'évaluer si le serverless est bien adapté aux cas d’usage de votre application.
Aujourd’hui, les architectures serverless évoluent très rapidement et le taux d’adoption par les entreprises est en pleine croissance (75% des entreprises utilisent ou prévoient d’utiliser serverless dans les prochains 18 mois). Sachant qu’il y a de plus en plus de problématiques autour de la “FinOps”, le serverless n’est sûrement pas la solution idéale par défaut.
