COMMENT LEGO EMPILE LES BRIQUES SERVERLESS POUR RENDRE SES SERVICES INCASSABLES

En 2017, après un plantage de son site en plein Black Friday, Lego change d’approche technique. Place aux services Serverless d’AWS tant pour le front Web qu’en back office de son site, dans une approche strictement collée au « Domain Driven Design » (conception pilotée par le domaine).

« 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 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 (en dorsal, partie invisible du logiciel)/intégration et une équipe frontend (en frontal, partie visible du logiciel). À la rentrée 2020, le système de paiement bascule à son tour.

Supporter les pics d’audience du site

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, que nous pouvions absorber de gros pics de trafic une ou deux fois par mois à cause de campagnes marketing sans difficulté. » 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 petites équipes. L’équipe à laquelle appartient Clara Villa est chargée

200 000 C’est le nombre de requêtes traitées par l’API Gateway qui sollicite des fonctions Serverless AWS Lambda.

de l’API de paiement de Lego. Celle-ci est mise en oeuvre sur le site de vente en ligne, mais aussi pour le BtoB, 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 équipe 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 1 000 commandes, 200 000 requêtes, 20000 notifications et 150invocations de fonctions Lambda chaque minute.

25 équipes au travail sur une approche DDD

Pour faire cohabiter toutes ces équipes autour d’une architecture efficace, Lego s’est appuyé sur le DDD (« Domain Driven Design »). 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 petite équipe, 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 data center et utilise les conteneurs sur Kubernetes, mais le Serverless marque des points.

L’approche « Serverless First » est amenée à se transformer rapidement en « Serverless Must ». Mais si vous vous plongez directement dans le Serverless, que vous développez des fonctions à gauche à droite, vous allez vous retrouver dans le pétrin. Il ne faut pas oublier les bases car elles sont ensuite très utiles. La première est de penser Domain First. » Sheen Brisals, Senior Engineering Manager chez The Lego Group et AWS Serverless Hero.

Le frontal du site Lego est protégé par AWS WAF et met en oeuvre les services AWS Faregate et Amazon ElastiCache. Ce frontal communique avec le coeur du site via la passerelle Amazon API Gateway, qui sollicite des fonctions AWS Lambda ainsi qu’Amazon Kinesis Data Firehose, la brique ETL de la plateforme AWS. Outre le stockage DynamoDB, l’architecture sollicite les briques d’échanges SQS, SNS, Event Bridge et des fonctions STEP.

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.