Dans de récents articles de blog, nous avons expliqué pourquoi nous estimons qu’il est essentiel d’adopter une architecture applicative à quatre niveaux dans laquelle les applications sont développées et déployées sous forme d’ensembles de microservices. Il apparaît de plus en plus clairement que si vous continuez à utiliser des processus de développement et des architectures applicatives qui convenaient parfaitement il y a dix ans, vous ne pouvez tout simplement pas avancer assez vite pour susciter et conserver l’intérêt des utilisateurs mobiles, qui ont le choix parmi un nombre toujours croissant d’applications.
Le passage à une architecture de microservices offre aux entreprises des perspectives commerciales prometteuses. Pour les architectes système et les développeurs, cette transition promet un niveau de contrôle et de rapidité sans précédent dans la création de nouvelles expériences web innovantes pour les clients. Mais à un rythme aussi effréné, la marge d’erreur peut sembler très limitée. Dans la pratique, vous ne pouvez pas interrompre le développement et le déploiement de vos applications le temps de repenser les processus correspondants. Vous savez que votre réussite future dépend de votre transition vers une architecture de microservices, mais comment procéder concrètement ?
Heureusement pour nous, plusieurs pionniers des microservices partagent désormais généreusement leur expertise dans l’esprit de l’open source, non seulement sous forme de code publié, mais aussi lors de conférences et dans des articles de blog. Netflix en est un parfait exemple. D’abord directeur de l’ingénierie web, puis architecte cloud, Adrian Cockcroft a supervisé la transition de l’entreprise, qui est passée d’un modèle de développement traditionnel, dans lequel 100 ingénieurs produisaient une application monolithique de location de DVD, à une architecture de microservices reposant sur de nombreuses petites équipes chargées du développement de bout en bout de centaines de microservices qui fonctionnent ensemble pour diffuser chaque jour des contenus numériques à des millions de clients Netflix. Aujourd’hui Technology Fellow chez Battery Ventures, Cockcroft est un éminent promoteur des microservices et des architectures cloud natives, et siège au comité consultatif technique de NGINX.
Dans une série de deux articles de blog, nous présenterons les principaux enseignements de deux conférences données par Cockcroft l’année dernière : l’une en octobre, lors de la première conférence annuelle NGINX, et l’autre quelques mois auparavant, lors d’un meetup sur les microservices dans la Silicon Valley. (Les enregistrements vidéo complets valent également le détour.)
- Cet article définit l’architecture de microservices et présente quelques bonnes pratiques pour en concevoir une.
- Adopter les microservices chez Netflix : enseignements pour la conception des équipes et des processus explique pourquoi et comment adopter une nouvelle approche du développement logiciel et réorganiser vos équipes en conséquence.
Qu’est-ce qu’une architecture de microservices ?
Cockcroft définit une architecture de microservices comme une « architecture orientée services composée d’éléments faiblement couplés ayant des contextes délimités ».
Faiblement couplés signifie que vous pouvez mettre à jour les services indépendamment les uns des autres : la mise à jour d’un service ne nécessite pas de modifier les autres. Si vous disposez d’un ensemble de petits services spécialisés, mais que vous devez tout de même les mettre à jour simultanément, ce ne sont pas des microservices, car ils ne sont pas faiblement couplés. Lors de la transition vers une architecture de microservices, un type de couplage souvent négligé est celui lié à la base de données : tous les services communiquent avec la même base de données et la mise à jour d’un service implique de modifier le schéma. Vous devez scinder la base de données et la dénormaliser.
Le concept de contextes délimités est issu du livre Domain Driven Design d’Eric Evans. Un microservice dont le contexte est correctement délimité est autonome aux fins du développement logiciel. Vous pouvez comprendre et mettre à jour le code du microservice sans rien connaître du fonctionnement interne de ses pairs, car le microservice et ses pairs interagissent exclusivement par l’intermédiaire d’API et ne partagent donc ni structures de données, ni schémas de base de données, ni autres représentations internes des objets.
Si vous avez développé des applications pour Internet, vous connaissez déjà ces concepts dans la pratique, même si vous n’en connaissez pas forcément le nom. La plupart des applications mobiles communiquent avec de nombreux services backend afin de permettre à leurs utilisateurs, depuis l’application, d’effectuer des actions telles que partager du contenu sur Facebook, obtenir un itinéraire avec Google Maps ou trouver des restaurants sur Foursquare. Si votre application mobile était étroitement couplée à ces services, vous devriez consulter toutes leurs équipes de développement avant de publier une mise à jour, afin de vous assurer que vos modifications ne risquent pas de perturber leur fonctionnement.
Lorsque vous travaillez avec une architecture de microservices, vous considérez les autres équipes de développement internes comme ces services backend sur Internet : des services externes avec lesquels votre microservice interagit par l’intermédiaire d’API. Le « contrat » communément admis entre les microservices veut que leurs API soient stables et compatibles avec les versions futures. Tout comme il serait inacceptable que l’API Google Maps change sans préavis et d’une manière qui perturbe ses utilisateurs, votre API peut évoluer, mais elle doit rester compatible avec les versions précédentes.
Bonnes pratiques pour concevoir une architecture de microservices
Cockcroft décrit son rôle d’architecte cloud chez Netflix non pas comme consistant à contrôler l’architecture, mais à découvrir et à formaliser celle qui a émergé au fil de sa conception par les ingénieurs de Netflix. L’équipe de développement de Netflix a établi plusieurs bonnes pratiques pour concevoir et mettre en œuvre une architecture de microservices.
Créer un magasin de données distinct pour chaque microservice
N’utilisez pas le même système de stockage de données backend pour plusieurs microservices. L’équipe responsable de chaque microservice doit pouvoir choisir la base de données la mieux adaptée au service. En outre, avec un système de stockage unique, les microservices développés par différentes équipes risquent trop facilement de partager des structures de base de données, éventuellement dans le but de réduire la duplication du travail. Ainsi, si une équipe met à jour une structure de base de données, les autres services qui l’utilisent doivent également être modifiés.
La séparation des données peut compliquer leur gestion, car les différents systèmes de stockage peuvent plus facilement se désynchroniser ou devenir incohérents, et les clés étrangères peuvent changer de manière inattendue. Vous devez ajouter un outil qui assure la gestion des données de référence (MDM) en s’exécutant en arrière-plan afin de détecter et de corriger les incohérences. Par exemple, il peut examiner chaque base de données qui stocke des identifiants d’abonnés afin de vérifier que les mêmes identifiants figurent dans chacune d’elles (qu’aucun identifiant ne manque ou ne soit présent en trop dans l’une des bases de données). Vous pouvez développer votre propre outil ou en acheter un. De nombreux systèmes commerciaux de gestion de bases de données relationnelles (SGBDR) effectuent ce type de vérifications, mais ils imposent généralement trop de contraintes de couplage et ne sont donc pas adaptés au passage à l’échelle.
Maintenir le code à un niveau de maturité similaire
Conservez tout le code d’un microservice à un niveau de maturité et de stabilité similaire. Autrement dit, si vous devez ajouter ou réécrire une partie du code d’un microservice déployé qui fonctionne bien, la meilleure approche consiste généralement à créer un nouveau microservice pour le code nouveau ou modifié, tout en laissant le microservice existant en place. [Note de l’éditeur – Ce principe est parfois appelé « infrastructure immuable ».] Vous pouvez ainsi déployer et tester le nouveau code de manière itérative jusqu’à ce qu’il soit exempt de bogues et parfaitement optimisé, sans risquer de provoquer une défaillance ou une dégradation des performances du microservice existant. Une fois que le nouveau microservice est aussi stable que l’original, vous pouvez les fusionner s’ils remplissent réellement ensemble une seule et même fonction, ou si leur regroupement permet d’autres gains d’efficacité. Toutefois, d’après l’expérience de Cockcroft, il est bien plus fréquent de constater qu’un microservice doit être scindé parce qu’il est devenu trop volumineux.
Effectuez une compilation distincte pour chaque microservice
Effectuez une compilation distincte pour chaque microservice afin qu’il puisse récupérer dans le dépôt les fichiers de composants aux niveaux de révision qui lui conviennent. Il arrive ainsi que plusieurs microservices récupèrent un ensemble similaire de fichiers, mais à des niveaux de révision différents. Cela peut compliquer le nettoyage de votre base de code lorsque vous retirez d’anciennes versions de fichiers, car vous devez vérifier plus attentivement qu’une révision n’est plus utilisée. Il s’agit toutefois d’un compromis acceptable au regard de la facilité avec laquelle vous pouvez ajouter de nouveaux fichiers à mesure que vous développez de nouveaux microservices. Cette asymétrie est intentionnelle : l’ajout d’un microservice, d’un fichier ou d’une fonction doit être simple, et non risqué.
Déployer dans des conteneurs
Le déploiement de microservices dans des conteneurs est important, car il permet d’utiliser un seul outil pour tout déployer. Tant que le microservice se trouve dans un conteneur, l’outil sait comment le déployer. Peu importe le type de conteneur. Cela dit, Docker semble être très rapidement devenu la norme de facto en matière de conteneurs.
Traitez les serveurs comme des entités sans état
Considérez les serveurs, en particulier ceux qui exécutent du code destiné aux clients, comme des membres interchangeables d’un groupe. Ils remplissent tous les mêmes fonctions ; vous n’avez donc pas à vous préoccuper de chacun d’eux individuellement. Il vous suffit de veiller à ce qu’ils soient assez nombreux pour fournir la capacité de traitement nécessaire, et vous pouvez utiliser la mise à l’échelle automatique pour ajuster leur nombre à la hausse ou à la baisse. Si l’un d’eux cesse de fonctionner, il est automatiquement remplacé par un autre. Évitez les systèmes « flocons de neige », dans lesquels vous dépendez de serveurs individuels pour assurer des fonctions spécialisées.
L’analogie de Cockcroft consiste à considérer les serveurs comme du bétail, et non comme des animaux de compagnie. Si vous avez en production une machine qui remplit une fonction spécialisée, que vous connaissez par son nom et dont la panne attriste tout le monde, c’est un animal de compagnie. Vous devriez plutôt considérer vos serveurs comme un troupeau de vaches. Ce qui compte, c’est la quantité de lait que vous obtenez. Si, un jour, vous constatez que vous obtenez moins de lait que d’habitude, vous repérez les vaches qui ne produisent pas suffisamment et vous les remplacez.
L’architecture de diffusion de Netflix repose sur NGINX
Netflix utilise NGINX Open Source depuis longtemps et est devenu le premier client de NGINX, Inc. après sa constitution en société en 2011. En effet, Netflix a choisi NGINX comme composant central de son infrastructure de diffusion, Open Connect, l’un des plus grands réseaux de diffusion de contenu (CDN) au monde. Capables de traiter des milliers, voire parfois des millions de requêtes par seconde, NGINX et NGINX Plus sont des solutions optimales pour la diffusion HTTP haute performance et permettent à des entreprises comme Netflix d’offrir chaque jour des expériences numériques de haute qualité à des millions de clients.
Enregistrements vidéo
Livraison rapide
nginx.conf 2014, octobre 2014
Migration vers les microservices, 1re partie
Meetup Silicon Valley Microservices, août 2014
Migration vers les microservices, 2e partie
Meetup Silicon Valley Microservices, août 2014
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.