Dans un projet de développement, il est essentiel de partir au plus tôt sur une composition de code bien pensé. C’est ce que souligne Dropbox en conclusion d’un billet de blog où il décrit l’architecture logicielle qui sous-tend son service de partage collaboratif de fichiers dans le cloud. Celle-ci évolue, sur la partie back-end, d’un produit server-side monolythique dénommé Metaserver et écrit en Python (comportant plus de 3 millions de lignes de code), à une plateforme d’orchestration de services managée. Baptisée Atlas, cette dernière est conçue pour gérer de petites fonctionnalités indépendantes en apportant à l’équipe de développeurs de Dropbox une expérience de type serverless à la AWS Fargate.  

Ce projet de longue haleine a été lancé l’an dernier par l’éditeur avec l’objectif de réduire les enchevêtrements de code et libérer les services et leurs équipes d’ingénierie de ces intrications. De précédentes tentatives pour améliorer Metaserver n’avaient pas abouti en raison de la taille de la base de code et de sa complexité. Le projet impliquait donc d’innover à la fois sur l’architecture - par exemple en standardisant sur gRPC et en utilisant le transcodage gPRC TTP d’Envoy - et sur les opérations en introduisant par exemple l’autoscaling et le test canary, explique les ingénieurs logiciels de Dropbox dans leur billet qui tire différents enseignements du projet à date.

La tentative d'une SOA

Au départ, l’équipe d’ingénierie a tenté une architecture orientée services (SOA) pour faire évoluer Metaserver. L’objectif était de faciliter la gestion opérationnelle de services indépendants en production avant de bâtir des services en dehors du monolithe et, à terme, diviser ce dernier en petits services exploités par différentes équipes. La tentative s’avéra ardue et longue et mit en évidence les difficultés qui se présenteraient à l’étape suivante. Le problème fut donc réévalué. « Nous avons trouvé que les fonctionnalités du produit chez Dropbox pouvaient être divisées en deux grandes catégories : les grands systèmes complexes comme la logique autour du partage d’un fichier et les petites fonctionnalités autonomes comme la page d’accueil », expose les auteurs du billet, Naphat Sanguansin et Utsav Shah. « Cela nous a conduit à une conclusion importante: les petites fonctionnalités autonomes ne nécessitent pas de services gérés indépendamment. C’est pourquoi nous avons construit Atlas ».

Pour les petites fonctionnalités, il est inutile de surcharger une équipe produit avec la planification de la capacité et la configuration des alertes, expliquent les ingénieurs de Dropbox. Ce que souhaitent principalement ces équipes, c’est de disposer d’un emplacement où écrire la logique et l’exécuter automatiquement quand un utilisateur arrive à un certain endroit, et d’avoir des alertes basiques automatiques en cas d’erreurs. « Le code qu’elles soumettent au référentiel doit être déployé de façon cohérente, rapidement et en continu. La plupart des fonctionnalités du produit appartiennent à cette catégorie, par conséquent Atlas pourrait l’optimiser ». En revanche, les grands composants doivent continuer à être leurs propres services, opérés par de plus grandes équipes qui gèrent durablement la santé de leurs systèmes. Des composants avec lesquels Atlas cohabite harmonieusement.

Une approche hybride

Atlas constitue donc une approche hybride. Elle fournit l’interface utilisateur et l’expérience d’un système serverless aux développeurs produits de Dropbox, en s’adossant à des services provisionnés automatiquement. « Le but d’Atlas, c’est d’apporter la majorité des bénéfices d’une architecture orientée services, tout en minimisant les coûts opérationnels associés à l’exécution d’un service », résument les auteurs du billet. Atlas étant managé, les développeurs qui écrivent du code définissent simplement l’interface et la mise en oeuvre des endpoints. Atlas se charge ensuite de créer un cluster de production pour servir ces terminaux. C’est l’équipe de la plateforme managée qui s’occupe du monitoring.

Résumé en 5 points, les bénéfices attendus d’Atlas sont des améliorations dans la structure du code, une livraison de code indépendante et cohérente, la réduction des tâches opérationnelles, l’unification de l’infrastructure sur des composants comme gRPC (pas besoin de réinventer la roue) et, enfin, la capacité d’isoler certaines fonctionnalités, comme la homepage. Le billet détaille ensuite la conception technique du projet : décomposition des fonctionnalités en composants, orchestration, mise en oeuvre opérationnelle avec la configuration automatique d’un pipeline de déploiement pour la mise en production de chaque composant. Par rapport à l’ampleur de la tâche que représentait un remplacement complet de Metaserver par Atlas, l’exécution de ce projet se fait par étapes plus petites. Actuellement, Atlas sert plus de 25% du trafic du précédent Metaserver. « Nous avons validé la migration restante dans des tests. Nous sommes sur la bonne voie pour abandonner Metaserver dans un futur proche », conclut l’équipe d’ingénieurs logiciels dans son billet.