Migrer SoundCloud vers une architecture à base de micro services a été crucial pour permettre à nos équipes de créer de nouvelles fonctionnalités plus rapidement. Phil Calçado nous livre une série de trois articles où il partage leur expérience en abandonnant leur système monolithique.
SoundCloud, une plate-forme de distribution de contenus audio chez qui Phil Calçado est Directeur technique, a longtemps été une unique application Ruby on Rails, mais passer leur temps à patcher le système au lieu de résoudre le problème de scalabilité les a amené à prendre la décision de complètement changer leur mode de conception. La première étape était l'architecture, et plus précisément la décision de migrer vers une architecture basée sur des micro-services. A cause de mauvaises expériences passées dûes à des problèmes de big-bang refactoring, ils ont adopté une approche consistant à ne plus rien ajouter au système existant mais, à la place, de créer les nouvelles fonctionnalités sous la forme de micro-services.
Un problème qui a été rapidement soulevé était que, dans la mesure où beaucoup de logique métier était conservée dans l'ancien système, la plupart des services devaient communiquer avec celui-ci. La solution à ce problème a été d'utiliser l'API publique conjointement avec une nouvelle API interne, ce qui a aussi aidé à maintenir les micro-services découplés de l'ancien système.
Après que des changements aient été effectués au niveau de l'architecture, le défi suivant était d'extraire des fonctionnalités de la vieille application. Le concept de bounded context issu du Domain-Driven Design (DDD) a été choisi pour définir un ensemble de fonctionnalités bien maîtrisées. Éviter les big-bang refactorings a nécessité, pour chaque ensemble de fonctionnalités extraites, le nouveau micro-service devait être compatible avec l'ancien système aussi longtemps qu'il était nécessaire pour déplacer la logique métier. Durant cette transition, le nouveau service accédait à l'ancienne base de données, impliquant que seule la lecture pouvait être implémentée jusqu'à ce que le service soit totalement fonctionnel. En appliquant ces principes, les équipes ont été capables d’extraire la plupart des fonctionnalités existantes du vieux système et de les porter en micro-services.
Selon leur préférences, ils ont choisi de conserver la plate-forme JVM ainsi que les différents langages disponibles. En cherchant des frameworks qui correspondaient à leur besoin en matière de RPC, de résilience et de gestion des accès concurrents, ils ont choisi Finagle, un système RPC agnostique au protocole, après avoir passé un peu de temps à gérer des problèmes mineurs.
En s'appuyant sur l'expérience apportée par leur travail, Phil Calçado résume le projet en déclarant que la nouvelle architecture basée sur des micro-services s'est déjà montrée cruciale dans le développement de fonctionnalités prêtes pour la production et disposant d'un cycle de développement très court.
L'objectif de Phil Calçado est maintenant de terminer sa série d'articles en décrivant la manière dont ils ont utilisé Finagle et Scala pour migrer d'une simple API RESTful vers des back-ends optimisés.