Architecture de microservices

Une architecture de microservices divise une app en une série de services déployables indépendamment qui communiquent via des API. Ainsi, chaque service individuel peut être déployé et mis à l'échelle de manière indépendante. Cette approche permet la livraison rapide et fréquente d'apps complexes de grande taille. Contrairement à une app monolithique, grâce à une architecture de microservices, les équipes peuvent implémenter de nouvelles fonctionnalités et apporter des changements plus rapidement, sans avoir à réécrire une grande partie du code existant.

Prenons l'exemple d'un hypothétique projet de logiciel de commerce électronique. Le schéma suivant représente un site de commerce électronique doté d'une app web et d'une app mobile qui interagissent avec plusieurs microservices, chacun fournissant des fonctionnalités spécifiques pour un domaine.

Les apps web modernes s'exécutent dans des navigateurs et sont souvent mises à disposition à partir d'un réseau de distribution de contenu (CDN). Un CDN offre l'avantage de distribuer des apps web à des serveurs du monde entier, afin qu'elles puissent être téléchargées rapidement par les navigateurs web. Les CDN sont également utilisés pour mettre à disposition des contenus multimédias tels que des images, du son et des vidéos. Par exemple, dans ce système, les images et les vidéos des produits à vendre sont diffusées à partir du CDN.

Les apps interagissent avec les microservices via des API REST publiées par chacun des microservices. Une passerelle d'API permet aux apps de s'appuyer sur les API fournies par les microservices et aux microservices d'être échangés contre d'autres microservices avec la même API.

Chaque microservice est composé d'un service et d'une base de données. Les services gèrent l'API REST, implémentent la logique métier et stockent les données dans une base de données. Pour les microservices, nous isolons leurs ressources telles que les bases de données et les files d'attente les unes des autres, conformément au contrat 12 Factor App.

Pour de nombreuses organisations, la première étape est de commencer par une architecture monolithique. Ensuite, il faudra diviser une base de code en plusieurs services, implémenter les bons modèles afin de limiter la casse et de récupérer après des problèmes de réseau, gérer la cohérence des données, surveiller la charge du service, et bien plus encore. Mais ce n'est que l'aspect technique. Vous devrez également réorganiser vos équipes et probablement adopter une culture DevOps.

Vient ensuite le plus difficile : décomposer le monolithe en microservices. Le refactoring (ou remaniement) d'un schéma de base de données monolithique peut s'avérer délicat. Il est important d'identifier clairement les ensembles de données dont chaque service a besoin et les chevauchements éventuels. L'adoption de la livraison continue aide à réduire les risques d'échec de livraison, et à vous assurer que votre équipe se concentre sur le développement et l'exécution de l'app, plutôt que d'être bloquée sur son déploiement.

Une architecture monolithique est un modèle traditionnel de programme de développement, conçu comme une unité unifiée autonome et indépendante d'autres apps. Une architecture de microservices est tout l'opposé d'un monolithe, puisqu'il s'agit d'une méthode architecturale qui repose sur une série de services déployables indépendamment. Les monolithes peuvent être préférables au début de la vie d'un projet en raison de la facilité de gestion du code, de la charge cognitive et du déploiement. Une fois qu'une app monolithique devient volumineuse et complexe, il n'est pas évident de la faire évoluer, le déploiement continu est difficile et les mises à jour peuvent s'avérer fastidieuses.

Alors qu'une app monolithique est conçue comme une unité unique et indivisible, les microservices divisent cette unité en un ensemble d'unités indépendantes qui contribuent à l'ensemble global. Une app est conçue comme une série de services déployables indépendamment qui sont décentralisés et développés de manière autonome.

Les microservices entrent dans la catégorie des systèmes distribués. Par définition, un système distribué est un ensemble de programmes informatiques qui utilisent des ressources informatiques sur plusieurs nœuds de calcul distincts pour atteindre un objectif commun et partagé. Les systèmes distribués contribuent à améliorer la fiabilité et les performances d'un système, et ils en facilitent la mise à l'échelle.

Les nœuds d'un système distribué offrent une redondance puisqu'en cas de défaillance d'un nœud, d'autres nœuds sont prêts à la pallier. Chaque nœud peut évoluer horizontalement et verticalement, ce qui améliore les performances. Si un système est soumis à une charge importante, des nœuds supplémentaires peuvent être ajoutés pour l'aider à absorber la charge.

Docker est une plateforme de conteneurisation commerciale et un environnement d'exécution qui permet aux développeurs de créer, de déployer et d'exécuter des conteneurs. Alors que Docker fournit un moyen efficace de créer des packages et de distribuer des apps conteneurisées, l'exécution et la gestion des conteneurs à grande échelle s'avèrent difficiles avec Docker seul.

Kubernetes est une plateforme open source populaire qui orchestre les systèmes d'exécution de conteneur sur un cluster de ressources en réseau. Elle peut être utilisée avec ou sans Docker. Docker est un système d'exécution de conteneurs, tandis que Kubernetes est une plateforme permettant d'exécuter et de gérer des conteneurs à partir de nombreux systèmes d'exécution de conteneurs.

La gestion des configurations logicielles est un processus qui gère, organise, suit et surveille les changements apportés aux métadonnées de configuration des systèmes logiciels. Elle est couramment utilisée parallèlement au contrôle de version et à l'infrastructure de CI/CD.

La gestion des configurations aide les équipes d'ingénierie à développer des systèmes robustes et stables grâce à des outils qui gèrent et surveillent automatiquement les mises à jour des données de configuration. Elle aide à mieux gérer la multiplication des logiciels dans une architecture de microservices en créant une « source de référence » avec un emplacement central pour les configurations.