Pour proposer musique, podcasts et vidéos, Spotify s’appuie sur « un réseau incroyablement complexe de milliers de systèmes logiciels interconnectés appartenant à des centaines d’équipes ». C’est ainsi que le service de streaming suédois décrit son patrimoine applicatif développé pour les 188 millions d’abonnés premium qu’il totalise au niveau mondial (chiffres du 2e trimestre 2022). Afin de communiquer autour de cette architecture logicielle sophistiquée et du catalogue associé, l’équipe informatique a mis au point un langage commun et des définitions de concepts, en d’autres termes un modèle de système. Ce dernier présente un ensemble d’entités et d’abstractions de base qui peuvent être utilisées pour synthétiser des données sur la santé de ces applications, sur leurs propriétés et leurs dépendances. Le mois dernier, le fournisseur européen a décrit ce modèle dans un billet.  

Le logiciel de Spotify est modélisé à l’aide de trois entités principales : les API (les liens entre différents composants, définissant l’interface entre ceux-ci), les composants eux-mêmes qui représentent différentes parties de logiciels (par exemple, un service de back-end, un site web, un pipeline de données, une bibliothèque) et les ressources, c’est-à-dire l’infrastructure requise pour opérer un composant qui s’exécute (par exemple, les bases de données, les machines virtuelles, les espaces de stockage désignés en anglais sous le nom de buckets). « La capacité à cartographier et à pouvoir suivre les composants logiciels dans un catalogue nous a été extrêmement précieuse », expliquent dans le billet Renato Kaman, ingénieur logiciel senior, et Johan Wallin, ingénieur logiciel chez Spotify. « Cela nous a permis de mieux comprendre l’échelle et le développement de nos logiciels. Mais à mesure que notre catalogue de composants individuels s’est étoffé, ces composants sont devenus de plus en plus difficiles à comprendre, à examiner et à mettre en relation les uns avec les autres. » C’est alors que l’équipe IT a introduit quelques abstractions supplémentaires, les Systèmes et les Domaines, pour faciliter la compréhension de l’écosystème logiciel dans son ensemble. Les Systèmes sont des entités qui coopèrent pour exécuter certaines fonctions, les Domaines sont des entités et systèmes liés à des parties de l’entreprise. « En exprimant ce modèle sous forme de métadonnées, nous avons pu créer un catalogue de logiciels qui permet de suivre les composants, leurs propriétaires, leurs dépendances et les cycles de vie de notre écosystème », exposent les auteurs du billet.

S'appuyer sur le modèle C4

Comme pas mal d’autres équipes IT, celles de Spotify se servent de tableaux blancs physiques pour schématiser leurs développements, en les remplissant au feutre de moult rectangles et flèches. Mais ces objets sont attachés à un emplacement (un bureau) et, d’une équipe à l’autre, la signification des symboles employés nécessite parfois des explications. L’objectif était donc de mettre au point un moyen simple pour visualiser l’architecture logicielle, en optimisant cette méthode pour faciliter la communication entre les utilisateurs. « Nous voulions des diagrammes qui pourraient nous permettre de comprendre notre logiciel avec un contexte minimal », indique le billet. « Or la solution était sous nos yeux : le modèle C4 qu’utilisaient nos développeurs logiciels ».

C’est donc le modèle C4 qui a été retenu pour créer les diagrammes Spotify. Ce modèle comporte lui-même une collection d’abstractions logicielles que le service de streaming a combiné avec la couche d’abstraction de son propre système de modélisation. Il a alors fallu redéfinir l’ensemble des diagrammes de base pour documenter l’architecture et la conception du système. Cela donne ainsi trois diagrammes : le « System landscape », le « System context » et le « System components ». Le premier décrit un ensemble de systèmes en relation, la façon dont ils sont connectés et les systèmes externes dont ils dépendent. Le deuxième décrit comment un système s’insère dans un contexte plus large de dépendances, de dépendants et d’utilisateurs. Le troisième décrit comment un système est bâti à partir de composants unitaires, ce qui correspond au 2e diagramme (ou niveau) du modèle C4 qui en comprend 4 : 1/Contexte, 2/Conteneur, 3/Composant, 4/Code.

Backstage pour la mise à jour automatique des diagrammes

A l’aide de son catalogue de logiciels et composants et des métadonnées associées, Spotify a pu transformer son écosystème en diagrammes sur lesquels il bénéficie en outre d'un rendu automatique et d'une navigation interactive. « Cela nous permet de communiquer et de visualiser l’ensemble de notre architecture à l’aide d’un langage et d’un modèle commun », explique le service de streaming musical. Cette automatisation des diagrammes architecturaux assure leur mise à jour permanente par rapport à la conception telle qu’elle est exprimée dans les métadonnées. Il n’est donc pas nécessaire de les actualiser au fur et à mesure de l’évolution du système, ni de s’inquiéter de savoir si la visualisation proposée est dépassée, expliquent les ingénieurs logiciels. L’automatisation des diagrammes d'architecture se fait dans Backstage, plateforme open source pour bâtir des portails développeurs. Spotify explique qu’il lui est très utile de pouvoir disposer de la modélisation de son système dans Backstage pour l’explorer et en découvrir les composantes, pour comprendre les cycles de vie, trouver les propriétaires des composants logiciels et les relations entre les composants. Et au final, pour améliorer la collaboration entre les équipes. 

En conclusion, s’il devient trop difficile de comprendre une architecture logicielle, la visualiser sous forme de diagrammes peut être très profitable. Les entreprises qui veulent s’y essayer pourront s’appuyer sur des modèles tels que C4, Spotify System Model ou créer le leur. « Il est essentiel d’avoir une notation standard pour rendre compréhensibles les diagrammes logiciels », insiste Spotify. « En nous inspirant des meilleures pratiques du modèle C4, nous avons pu utiliser notre System Model pour créer des visualisations de logiciels faciles à comprendre avec un contexte minimal. Cette combinaison a permis de créer un langage commun utilisé dans toute l’organisation pour faciliter la communication », concluent les deux ingénieurs en profitant du billet pour lancer un appel au recrutement.