Cet article devait initialement se focaliser uniquement sur le repo d’Airbnb. Leur histoire contenait cependant des traits de Quality Engineering.

J’ai donc décidé d’avoir un prisme plus large sur l’analyse de l’évolution de leur repository. Leur histoire est intéressante par le lien fort de leur engineering au support et enabler du business. La dimension qu’à atteinte l’entreprise la rend utile d’apprentissages.

Le choix d’un mono ou multirepo est un sujet structurant. Pour une start-up, le choix du monorepo semble celui par défaut. Par contre, comment l’architecture de notre repository, développement et déploiement doit accompagner la croissance de l’entreprise ?

Parcourons donc l’évolution de Airbnb par la perspective du Quality Engineering.

Tout a commencé avec un monolith en monorepo, Monorail

Airbnb a démarré son aventure par des premières lignes de code. La construction de leur produit s’est axée sur une architecture monolithique supportée par un monorepo. Peu de legacy était à considérer pour une entreprise qui démarrait son activité.

Le choix du langage s’est principalement porté vers Ruby on Rails, donnant également nom à leur repo, Monorail. Leur front-end a démarré en BackBone pour basculer vers React et Redux à partir de 2015. La base de code restait complémentée par quelques services Java et des mécanismes asynchrones en Resque.

Nous pouvons noter un modèle centralisé via un monolith en monorepo, et un changement plus rapide de technologies sur le front-end. Leurs composants devaient évoluer rapidement pour supporter les cycles d’itérations de l’entreprise. La pipeline supportant le processus de développement et de release était donc structurante.

Une pipeline intégrant la qualité par design

Les chaînes d’intégrations logicielles sont composées d’étapes relativement standards. Néanmoins, leur performance tient aux choix et qualité des implémentations réalisées.

Airbnb a sécurisé son processus de développement en appliquant des pratiques exigeantes dès le départ. Un mécanisme de pre-merge similaire au pre-submit de Google assure une revue par un pair en responsabilité du projet. Une fois le changement validé, le build peut démarrer incluant l’exécution des tests inclus dans le projet.

Le repository principal se retrouve à intégrer les divers changements ayant passé ces premières étapes de validation. Dans une architecture monolithique en monorepo, l’entièreté du système de Continuous Integration (CI) est déclenchée.

Le déploiement dans les différents environnements peut suivre, accompagné de tests manuels et automatiques. C’est l’occasion d’exécuter des tests uniquement pertinents dans un environnement intégré tels que de performance ou de bout en bout.

Notons que le “All of CI is ran again” implique un build complet, sans modèle de split-repo ou de sélection de projet à déployer. Avec le temps, la base de code grandit et se complexifie, augmentant le temps de build. Nous verrons par la suite que c’est un sujet que Airbnb a dû adresser.

Une culture d’engineering intégrant les opérations

La sensibilisation au risque est fondamentale pour les équipes d’engineering, en particulier les développeurs qui peuvent facilement s’en distancier. Créer une culture d’engineering partagée est fondamentale pour la performance de l’organisation.

Airbnb a très tôt favorisé une culture transversale de livraison et de déploiement. Les équipes d’infrastructures fournissent aux développeurs les outils pour déployer jusqu’en production. Chaque déploiement est la responsabilité du développeur concerné assurant le suivi, coordination et éventuels ajustements. 

Airbnb a favorisé la prise d’initiative et la collaboration de ses équipes. Les astreintes sont par exemple assurées sur base de volontariat. La coordination des déploiements est réalisée entre les ingénieurs, sans reposer sur une équipe en silo de release management. Par défaut les livraisons sont en heures ouvrées, et peuvent être accordées en dehors.

Ces pratiques sont au service d’une expérience client de qualité, nécessitant des opérations robustes. Les mécanismes d’activation progressive, de feature flags et de rollback automatiques sont clefs pour une réactivité au rendez-vous. Ces pratiques, même si simples dans leur concept, requiert une véritable intégration bout-en-bout, plus complexe à réaliser.

Le split du monolith devient nécessaire pour l’entreprise

Ces différentes itérations et améliorations ont été au support de la croissance d’Airbnb. Cette croissance s’est traduite par un agrandissement de sa base de code, créant une problématique à adresser : le ralentissement de ses cycles d’itérations.

La base de code grandissante ralentit la pipeline de livraison dans une architecture monolithique, en monorepo, avec un “All of CI is ran again”. Finalement, c’était la capacité d’ Airbnb à améliorer son expérience utilisateur qui était impactée, et donc sa survie.

Il y avait donc une bonne raison de revoir leur système de développement. C’est un point important à noter car il clarifie le “Why”. Un pourquoi trop souvent oublié, faisant perdre de vue les objectifs métiers aux équipes d’engineering.

En 2019 Airbnb a donc revu son système logiciel au global en passant par l’architecture, le code et les processus de déploiements. Leur priorité était de pouvoir supporter la croissance d’Airbnb par une meilleure expérience utilisateur en web et mobile, tout en élargissant les gammes de services proposées.

Airbnb a donc adressé chaque problématique dans son contexte au service de l’entreprise et de ses clients. Leur transformation gardait en tête les objectifs business par la phrase “we cannot impact company growth”. 

Les contextes de front-end et de back-end ont été isolés respectivement dans Hyperloop et Treehouse. Vous noterez que les noms choisis explicitent les intentions de vitesse et de robustesse ciblés par chacun d’entre eux. C’était un premier niveau de séparation permettant d’évoluer plus tard vers un découpage serviciel en approche SOA. 

Le front doit répondre aux enjeux d’accélération

Le front-end se retrouve en cohésion avec ses enjeux d’accélération, ses frameworks et équipes focalisées à améliorer l’expérience utilisateur. Airbnb a capitalisé sur sa culture du partage et pratiques d’engineering pour cette transformation.

Le but du front-end était de supporter des “faster, smaller and better loops”.

Les clefs de réponses sont dans l’équilibre. Une architecture MVC est retenue pour isoler chacun de ces contextes. La communication au sein du front est assurée par des APIs standards en JSON. Enfin, l’organisation et le code sont alignés en Business Unit, la dernière pierre angulaire pour permettre des déploiements indépendants.

Le back doit rester fiable et s’étoffer en services

Le back-office évolue quant à lui pour supporter le colonne vertébrale de l’entreprise qui doit s’étoffer en offre et services. Le mot “Treehouse” image bien la forêt de services qu’Airbnb voulait construire. Java est le langage retenu avec de l’outillage facilitant la réplicabilité des applications à délivrer, exposés principalement en REST.

La communication entre les différents services était structurante par la distribution de son système. Les modèles d’échanges synchrones et asynchrones sont posés pour répondre aux différents cas d’usages. Thrift est retenu pour apporter la validation des schémas sur base d’un protocole standard et open-source. Cette brique leur permet de garantir une cohérence de la donnée et des échanges abstraits des choix technologiques.

Le modèle asynchrone favorise le découplage et la scalabilité individuelle des composants via une approche orientée événement. L’implémentation de la plateforme événementielle via Kafka intègre un écosystème de wrappers standards supportant Thrift.

La performance de la pipeline de développement d’Airbnb restait le focus principal. D’où l’importance de la Developer Experience, ou DevEx.

Une approche plateforme supportant la Developer Experience

L’accélération de livraison du logiciel nécessite une optimisation du processus de développement. Les cycles d’itérations doivent être raccourcis, en particulier ceux de production de code d’oú l’importance de l’expérience de développement.

Pour ce faire, le recours à une approche plateforme permet d’industrialiser les services valorisés par les acteurs du système. Dans notre cas, les développeurs nécessitent de pouvoir naviguer facilement entre création de projet, code, construction, test et déploiement.

Airbnb a investi dans plusieurs étapes clefs de son processus :

• Un générateur de service fournissant un projet standard avec les bibliothèques d’infrastructures, loging et testing en quelques secondes
• L’externalisation et l’automatisation de la configuration des projets, laissant les développeurs se focaliser sur le code et moins sur l’intégration
• Des pipelines de déploiement standards actualisées pour leurs différentes stacks technologiques

La mise en place d’un tel outillage requiert une maturité d’ingénierie et de processus en place. Les équipes doivent être capables d’expliciter des enchaînements complexes pour les automatiser et les industrialiser.

Une approche de Quality Engineering équilibrée

L’évolution du repository est intéressante en perspective des autres évolutions mises en place chez Airbnb. Le choix de repo est l’un des éléments à considérer pour construire un système logiciel performant, dans un système plus largement organisé.

L’apport de valeur combinant une gestion de risque se retrouve dans l’approche itérative et orientée métier d’Airbnb. Sur l’exemple de l’architecture, le monolith a évolué graduellement face à de réelles problématiques de scalabilité du métier. On retrouve d’ailleurs le focus business sur le principe d’architecture “We cannot impact the business growth”. 

Airbnb a réalisé très tôt un investissement clef : leur culture d’engineering. Une culture qu’ils ont premièrement axée en transverse sur les opérations et le client tout en responsabilisant les équipes. Cette base leur a permis de développer leur capacité à obtenir des cycles de développements accélérés.

Les résultats atteints en automatisation, expérience de développement et pipelines ne sont pas le fruit du hasard. Ils sont la conséquence d’investissements continus dans leur système d’engineering, de l’organisation aux opérations.

Peu de raccourcis sont possibles pour développer de réelles capabilities de Quality Engineering.

Références

From Monorail to Monorepo: Airbnb’s journey into microservices – GitHub Universe 2018 https://www.youtube.com/watch?v=47VOcGGm6aU