Du monolithe à une architecture orientée service - Compte rendu du talk de Thomas Lamirault à la Duck Conf 2019
En 10 ans, l’architecture de BlaBlaCar a énormément évolué et est passée d’un monolithe suivant KISS à une architecture orientée micro-service beaucoup plus complexe de manière à pouvoir absorber la charge créée par l’activité de ses 70 millions d’utilisateurs actifs à l’international, activité toujours en croissance aujourd’hui. Ce chantier ne s’est pas fait en un jour et Thomas Lamirault, Engineering Manager chez BlaBlaCar, nous a détaillé l’ampleur du travail accompli au cours d’un retour d’expérience qui sentait bon le terrain.
L’infrastructure initiale de BlaBlaCar reposait à l’époque sur une simple stack PHP et MariaDB : étant données les contraintes, ce choix était parfaitement justifié puisque permettant un démarrage rapide du projet et les technologies choisies jouissaient d’une communauté importante, ce qui avait pour conséquence indirecte de faciliter le recrutement de talents.
Dès les premières années en production, la croissance à deux chiffres de la société a nécessité de revoir l’architecture en place : étant donné le nombre grandissant d’utilisateurs (et donc de données), la mise en place d’un sharding multi-datacenter est devenue nécessaire et un RabbitMQ a été ajouté de manière à pouvoir réaliser un certain nombre de traitements de manière asynchrone… Cette complexification de l’architecture allait vite devenir incompatible avec la stack plutôt simple des débuts. Parmi les conséquences notables : une dette technique grandissante (autour d’1M de lignes de PHP) et une vélocité en baisse des développeurs.
Retrouvez la présentation complète sur slideshare.
La première étape pour sortir de cette situation a été de changer l’orientation de l’architecture de manière à la rendre API Centric. L’idée est de séparer les grosses fonctionnalités et de permettre leurs interactions à l’aide d’une API. Cela permet de considérer le monolithe comme une API à part entière, en cachant la complexité des multiples intégrations à l’aide d’une façade. Un tel changement permet la séparation du monolithe en modules de plus petite taille de manière itérative et pragmatique, tout en limitant l’impact sur les interactions au sein de l’application.
Parallèlement à cela, l’utilisation de Kafka et du Schema Registry a permis la mise en place d’une stratégie d’Event Sourcing de manière à découpler au maximum les relations entre les services. De ce fait, il a été possible d’introduire de nouvelles bases de données (Cassandra, etc.) plus adaptées aux fonctionnalités alors séparées. De plus, cette séparation en services indépendants a permis de sécuriser les mises en production (jusqu’à 6 par jours) et d’augmenter la vélocité des développeurs, avec, à la clé une réduction du Time to Market des nouvelles fonctionnalités. Enfin, la mise en place d’une architecture orientée micro-service permet de moderniser la stack au fur et à mesure (passage de PHP à Spring Boot, etc.) tout en adoptant progressivement des pratiques DevOps qui responsabilisent les développeurs quant au suivi de leurs applications depuis le développement jusqu’à la production (You Build It, You Run It). Néanmoins, cette transition nécessite un investissement fort sur le monitoring et plus généralement sur l’observabilité des composants de l’architecture.
Pour conclure, la leçon que nous retiendrons de BlaBlaCar est qu’il est possible de faire une transition d’un monolithe vers une architecture micro-service, mais c’est un travail difficile et fastidieux qui demande d’appliquer une approche pragmatique (mesurer, tester, etc.). D’autre part, en parallèle de l’architecture, les comportements doivent également évoluer, aussi bien d’un point de vue technique qu’organisationnel.