Comment Lego empile les briques Serverless pour rendre ses services incassables

En novembre 2017, alors que le site Lego.com reposait encore sur une ancienne technologie monolithique, la plateforme legacy de notre site Web s’est crashée et notre site Web est devenu inaccessible » raconte Clara Villa, Software Engineer chez The Lego Group. « Nous avons alors décidé que jamais plus nous devions nous retrouver dans une telle situation. »

Au printemps 2018, une première expérimentation du Serverless est lancée et puis les équipes commencent à développer de plus en plus de logiciels en Serverless. En juillet 2019 la version Serverless du site de e-commerce de la célèbre marque est mise en production. Celui-ci s’appuie alors sur 20 microservices développés par une vingtaine d’ingénieurs répartis entre une équipe backend / intégration et une équipe frontend. A la rentrée 2020, le système de paiement bascule à son tour.

Supporter les pics d’audience sur Lego.com

La décision de basculer sur des fonctions Serverless portées par AWS a porté ses fruits car durant l’été 2021, alors que Lego fait un gros lancement de produits, le site va connaître une audience record, un pic de trafic encaissé sans broncher par l’architecture Serverless mise en place par les équipes de développement de Lego à Londres.

« Nous avons réalisé alors que les gros volumes de trafic n’étaient plus pour nous une problématique. Nous pouvons absorber de gros pics de trafic une fois ou deux fois par mois à cause de campagnes marketing sans difficulté. »ajoute Clara Villa.

Actuellement, l’architecture du site Lego.com s’appuie très largement sur les services d’Amazon Web Sites Services. L’architecture EDA (Event Driven Architecture) du site sollicite notamment l’API Gateway pour solliciter des fonctions Serverless AWS Lambda.

L’équipe Serverless de Lego a grossi pour compter aujourd’hui 25 squads.

La Squad à laquelle appartient Clara Villa est chargée de l’API de paiement de Lego. Celle-ci est mise en œuvre sur le site de vente en ligne, mais aussi pour le B2B, les expéditions, le marché éducation et le service support Lego. Il est interconnecté avec les réseaux de paiement par carte bancaire, Paypal.

Cette Squad gère plus de 20 microservices, soit plus de 80 fonctions Lambda développées, 10 fonctions STEP, plus de 40 règles EventBridge. Le volume de données stockées dans DynamoDB dépasse les 100 Go. En termes de trafic, l’API est amenée à traiter plus de 1000 commandes, 200 000 requêtes, 20 000 notifications et 150 invocations de fonctions Lambda chaque minute.

25 Squads au travail sur une approche DDD

Pour faire cohabiter tous ces squads autour d’une architecture efficace, Lego s’est appuyé sur le DDD : Domain Driven Design.

Un bon découpage en domaines/sous-domaines est le secret de l’efficacité d’une architecture DDD. Ici les domaines relatifs à la fidélité client chez Lego.

Sheen Brisals, Senior Engineering Manager chez The LEGO Group résume l’approche : « Pour une architecture Domain Driven, il faut diviser la problématique par domaine, puis sous-domaines, pour arriver à la notion de Bounded Context. Lorsque vous avez bien défini les frontières de chaque domaine, il devient plus facile d’en assigner la responsabilité à une Squad, une Two Pizza Team. Elle sait précisément ce qu’elle doit développer, elle dispose des protocoles pour communiquer, elles peuvent alors développer leurs microservices ou applications dans le cadre de ces frontières définies préalablement. Il s’agit de l’approche que nous avons adoptée chez Lego.com. »

Lego n’a bien évidemment pas basculé l’ensemble de ses applications en Serverless à ce jour. Chaque équipe choisit la technologie qui est la meilleure pour elle. Lego dispose toujours d’un datacenter et utilise les conteneurs sur Kubernetes, mais le Serverless marque des points.