Le parcours d’informatique serverless a débuté en 2016 chez l’entreprise danoise Trustpilot, quand Martin Buberl, vice-président de l'ingénierie, est revenu de la conférence re:Invent 2016 d'AWS. Lors de l’édition 2018 de re:Invent qui se tient cette semaine du 26 au 30 novembre à Las Vegas, ce dernier a déclaré qu'il y a deux ans « il n'aurait jamais imaginé se retrouver ici ». Son équipe d'ingénieurs est passée avec succès à une architecture presque entièrement serverless en s'appuyant fortement sur les fonctions Lambda, de telle sorte que AWS prend entièrement en charge l'exécution de code.

« L’informatique serverless n'était pas complètement nouvelle pour moi, mais le concept de calcul serverless et de fonctions Lambda a vraiment pris son sens en 2016 », a encore déclaré Martin Buberl. À l’époque, l'entreprise, native dans le cloud depuis cinq ans, tournait sur une architecture de microservices événementiels et d'API REST de haut niveau. Désormais, avec l'ajout de fonctions en tant que service et de files d'attente évènementielles serverless, il a estimé que l'équipe d'ingénierie pouvait passer au niveau suivant.

La mise en œuvre

Pour commencer, il a défini ce que Trustpilot appelle des « principes d'ingénierie » pour faire évoluer l’architecture en mode « serverless first ». En résumé, si pour un domaine donné, l’informatique serverless n’était pas disponible ou peu pratique, il préconisait l’usage des conteneurs et d’éviter les serveurs virtuels classés dans la catégorie héritée. Martin Buberl reconnaît que le jour où il est revenu de Las Vegas avec de grands projets d’informatique serverless, ses ingénieurs se sont montrés plus ou moins enthousiastes. Il admet aussi qu'il a peut-être négligé le « pourquoi » du Cercle d’or de Simon Sinek, tout aussi important. Mais c'est surtout l’abandon des serveurs virtualisés qui a rendu perplexe sa population de développeurs .NET, encore très dépendants des serveurs virtualisés.

Comme l’a raconté M. Buberl, après sa réunion avec les ingénieurs de l'entreprise, certains étaient plus satisfaits, mais d’autres n'étaient pas convaincus et levaient encore les sourcils. Après réflexion, l’entreprise a choisi de passer à .NET Core et à Docker pour cette équipe. L’énoncé du principe élargi est devenu : « Nous le faisons parce que nous croyons fermement que l’informatique serverless (FaaS, BaaS, DBaaS) est l'avenir du cloud et nous aimerions être à l'avant-garde de ce mouvement. Aujourd'hui, le serverless n'est peut-être pas nécessairement le bon choix pour tout, mais les discussions d'architecture doivent commencer par là. Nous sommes en train de supprimer les serveurs virtualisés et nous voulons éviter d'en créer de nouveaux ». Quand les ingénieurs ont estimé que le projet était au point, ils l'ont mis en open source sur GitHub, où il a rejoint d’autres projets de révision de code, de priorité aux services, de construction de petites choses, d’encapsulation contextuelle et d’exposition des API.

À quoi ressemble cette architecture ?

La nouvelle architecture s'appuie sur une couche de gestion d'API et sur le simple service de notification (Simple Notification Service - SNS) pub/sub, qui fonctionne avec GitHub et Slack. « L’association de Github et de Slack permet d’utiliser les Lambdas immédiatement », a expliqué Martin Buberl. Pour simplifier, chaque fois qu’un webhook est activé par un évènement au niveau du référentiel Github, les messages sont envoyés en utilisant la passerelle API à laquelle s'abonne Lambda, puis diffuse les actions déclenchées en utilisant le mécanisme SNS pub/sub.

Par exemple, ce système peut être utilisé pour la conformité RGPD. Il arrivait parfois que des spécialistes des données confient accidentellement à GitHub des données personnelles identifiables avec leurs ensembles d’apprentissage, ce qui pouvait poser problème au moment de l'audit. La solution consiste à signaler à Slack chaque engagement potentiellement problématique pour prendre des mesures le plus rapidement possible. Aujourd’hui, Trustpilot est passée de 180 à 95 serveurs virtualisés, soit 53 % de moins qu’en 2016, de 80 à 283 conteneurs, soit 354 % de plus qu'en 2016 et à 252 fonctions Lambda régulières, soit 40 de plus.

Les bénéfices

La question que l’on pose le plus souvent à M. Buberl est de savoir si les fonctions Lambda sont moins chères. Le problème c’est que, selon lui, on ne peut pas comparer les déclencheurs Lambda au calcul cloud traditionnel. « L'effort doit porter sur les systèmes de mise à l'échelle automatique », a-t-il déclaré. « Et nous voyons que c'est difficile à quantifier. Alors si l’on fait des erreurs et que le système n'évolue pas, ça coûte cher également ». Cependant, son intuition est que son architecture serverless est désormais « 10 fois moins chère », en grande partie grâce à la réduction des frais opérationnels. Selon lui, le serverless apporte également d’autres avantages, en particulier des vitesses de développement plus rapides.

Mais le principal inconvénient concerne la perte de traçabilité sur les systèmes. « Nous investissons pour améliorer cela. Nous avons notamment beaucoup de petits systèmes », a-t-il ajouté. Trustpilot en fait tourner désormais plus de 500. Aujourd'hui, son équipe utilise Amazon X Ray et se connecte pour suivre ces services, mais l’entreprise cherche à investir dans un service mesh « pour rassembler tous ces systèmes et réaliser son mapping à partir de là ».