Comprendre le succès du modèle "Serverless"

Quiconque à déjà fait de l'infrastructure sur un provider cloud a déjà entendu parler du modèle serverless, derrière ce nom se cache en réalité beaucoup d'aspects. Petit tour d'horizon...

Le modèle serverless : Evolution logique des containers ?

Depuis maintenant plusieurs années, on parle de containers. Révolution de ces 5 dernières années, les containers (et les orchestrateurs) ont profondément changé l'approche de l'infrastructure, permettant de déployer de plus en plus simplement et rapidement des applications composées de microservices. Je ne vais pas parler de cette évolution ici.

Dans les grandes lignes, le principe du serverless est d'aller plus loin sur cette approche, en se disant qu'on ne veut plus à avoir à se soucier de l'infrastructure et du middleware sous-jacent. Grossièrement, j'ai mon code applicatif, je veux qu'il tourne, et ça s'arrête là, je n'ai pas besoin de savoir où il tourne, comment la machine est installée etc... je veux simplement qu'il tourne.

Le modèle serverless apporte cette flexibilité, avoir simplement du code à faire tourner sans se soucier de l'infrastructure sous-jacente. Mieux encore, il permet de réduire drastiquement le coût de certaines applications adaptées à ce modèle grâce au modèle de facturation à la demande, qui permet de facturer uniquement les ressources exploitées plutôt qu'une infrastructure tournant en 24/7 pour recevoir des connections.

Simplicité de mise en place

Comme décrit plus haut, le modèle serverless permet de réduire le time to market en ayant à se soucier uniquement que du code applicatif. Des entreprises comme ACloudGuru par exemple on put mettre en place leur site internet grâce à ces technologie, à moindre coût. De plus, le fait de ne pas avoir à gérer d'infrastructure permet de ne pas avoir besoin d'ingénieurs système et réseau par exemple.

Si je prend l'exemple du service Lambda d'AWS, en quelques minutes je peux mettre en place mon code en python 3 par exemple, que je peux relier directement à un ALB (possible depuis la fin de l'année dernière) ou au service API Gateway, et en hébergeant mes assets sur S3, en static webhosting, et j'ai un site complet qui peut être mis en place très rapidement, en ayant eu a aucun moment à gérer de l'infrastructure.

Faire du serverless ou ne pas en faire du tout

L'un des points mis très souvent en avant sur le serverless est le fait d'avoir de la redondance gérée nativement, permettant d'avoir des solutions hautement disponibles et scalable potentiellement infiniment. L'erreur qui est souvent faite est de faire du serverless sur certains aspect mais pas tous. Par exemple mettre une API Gateway avec Lambda (jusqu'ici tout va bien), mais avec une source de données "classique" par un exemple un serveur RDS MariaDB, qui ne pourra pas scaler autant que Lambda par exemple. C'est de cette manière qu'on créé un SPOF hautement disponible! On peut tout de même utilisé du serverless sur certains composants, tant qu'on est conscient qu'on perd le potentiel de scalabilité infini par exemple.

Reduction des coûts

Sur cet aspect, souvent mis en avant aussi, il faut faire très attention, comme à chaque fois qu'on s'aventure vers le FinOps tout n'est pas blanc ou noir!

Je suis moi-même un fervent défenseur du serverless, mais je suis conscient que ce modèle n'est pas adapté à tous les besoins.  Des applications à très fortes charges par exemple, ou étant très sollicitées peuvent parfois coûter plus cher en serverless que sur une infrastructure "classique".

De même, j'ai parlé plus haut de la scalabilité infinie, qui est un avantage non négligeable. Il peut aussi se retourner contre son propriétaire, par exemple en cas d'attaque de type DDOS, qui va essayer de surcharger le service. Dans ce cas, le service continuera de répondre, ce qui est très bien pour l'image utilisateur, par contre, sans garde fou, la facture va elle littéralement flamber. Pour avoir déjà vu une petite attaque sur un flotte EMR, ca peut parfois être violent, en terme d'ordre de grandeur, en 1 heure, la facturation était égale à une journée complète de fonctionnement sur l'ensemble des comptes AWS de l'entreprise. Fort heureusement, il est possible de mettre des limites. Par exemple Lambda permet de fixer un nombre de Concurrent Execution permettant de limiter le nombre d'execution simultanée.

A contrario, j'ai vu fonctionner des applications avec Lambda + API Gateway + S3 qui coûtaient moins de 10$ par mois, au lieu de plusieurs centaines de dollars sur une infrastructure de type ALB + backend EC2

Les acteurs du cloud investissent massivement dans le serverless

Je vais me concentrer ici sur AWS, que je maîtrise bien mieux que ces concurrents. Force est d'admettre que les acteurs cloud investissent aujourd'hui massivement dans le modèle serverless. Dernier exemple en date pour Amazon, EKS (Kubernetes managé) compatible avec le service FarGate, qui permet d'executer des containers en mode serverless, en payant simplement du crédit CPU/RAM.

Mais restons pragmatique, avec tous les avantages cités ci dessus, quels intérêt ont ces providers à réduire votre facture?

De mon point de vue, j'en vois à minima 2 :

• Cela créé une adhérence forte avec AWS, réduisant d'autant plus la possibilité d'aller voir ailleurs. Des outils comme SAM (Serverless Application Model) et SAR (Serverless Application Repository) sont d'ailleurs spécifiquement prévus pour aller dans ce sens.
• Cela permet à Amazon de mutualiser son infrastructure de manière très atomique, bien plus qu'une VM, qui est plus lourde à managée.

En conclusion

Le but de ce billet n'est pas lister l'ensemble des solutions existantes pour mettre en place du serverless, mais plus de faire un rapide tour d'horizon pour expliquer pourquoi on parle de plus en plus de serverless.

Comme décrit plus haut, ce modèle apporte des avantages indéniables :

• Scalabilité "infinie"
• Haute disponibilité
• Pas d'infrastructure à gérer
• Réduit le time to market

Mais il arrive aussi avec des nouvelles problématiques à prendre en compte, que ce soit en sécurité qu'en terme de facturation. Par exemple FarGate coute environ 3 fois plus cher à CPU/RAM égale qu'une machine EC2, mais permet de ne pas avoir à gérer cette dernière.

Et vous qu'en pensez-vous ? N'hésitez pas à réagir dans les commentaires!