Comment Dropbox a repensé son architecture orientée services

Disloquer un monolithe implique-t-il forcément d'en faire des services indépendants ?

Il y a quelques années, Dropbox s'était confronté à cette problématique. L'entreprise américaine avait opté pour une approche "hybride", à base de groupements logiques de routes et de standardisation sur gRPC, tout en apportant à ses devs l'essentiel des bénéfices d'une architecture orientée services. Elle avait donné un nom à cette démarche : Atlas.

Le socle établi dans ce cadre fournit aujourd'hui, entre autres, des fonctionnalités d'autoscaling et de rollback. Dropbox les évoque au sujet de travaux intervenus plus récemment. En l'occurrence, la refonte de son infrastructure asynchrone.

Des systèmes non alignés

Cette infrastructure comprenait de multiples systèmes, chacun adapté à des produits et/ou des processus spécifiques. Ils étaient développés, exploités et maintenus séparément. D'où des disparités dans la cadence de livraison et la fiabilité. Entre autres :

• Courbe d'apprentissage pour les devs, tenus d'assurer diverses responsabilités ops, de la planification de capacité au support
  
  
• SLO variables et absence de multi-homing
  
  
• Efforts supplémentaires de maintenance, renforcés par l'utilisation de plusieurs solutions de gestion des files d'attente (Amazon SQS, Kafka, Redis)
  
  
• Incapacité de montée en charge de certains composants comme le planificateur d'événements différés, d'où la nécessité de protocoles d'examen de chaque nouveau cas d'usage
  
  
• Infra Lambda non alignée sur les bonnes pratiques internes en matière d'architecture orientée services (d'où l'absence d'autoscaling, mais aussi une sous-utilisation des clusters de compute)
  
  
• Difficulté à élargir le pipeline de capture des données modifiées pour intégrer la distribution des événements Cypress

Trois objectifs, deux KPI

Quelque 400 use cases étant déjà couverts, il n'était pas envisageable de repartir de zéro. Pour aller vers une approche plus cohérente, il fut donc décidé d'une reconstruction itérative. Avec trois objectifs principaux :

• Vélocité des déploiements (fluidification de l'adoption par les ingés produits et réduction de leur charge opérationnelle, mise à l'échelle automatique, etc.)
  
  
• Robustesse et extensibilité (unification des patterns entre systèmes, intégration de use cases avec un minimum de modifications)
  
  
• Coût et efficacité opérationnelle (élimination des systèmes redondants, passage de l'infra Lambda sur la stack SOA...)

Principaux KPI : temps de livraison (devs) et temps de garde (ops).

Dropbox ne traite qu'en surface de l'architecture qui en a résulté. Il évoque un modèle divisé en 5 couches logiques :

• Front-end (qui valide les schémas des événements, en standardise les formats et en garantit la durabilité)
• Planificateur (coordination et distribution des événements)
• Contrôle de flux (distribution des tâches, gestion d'état)
• Livraison (routage vers les fonctions Lambda avec gestion de concurrence)
• Exécution (par Lambda ou processus distants)

Dropbox

Illustration principale générée par IA