Adoption des microservices chez Netflix : Cours pour la conception architecturale

Dans certains articles de blog récents, nous avons expliqué pourquoi nous pensons qu'il est essentiel d'adopter une architecture d'application à quatre niveaux dans laquelle les applications sont développées et déployées sous forme d'ensembles de microservices . Il devient de plus en plus évident que si vous continuez à utiliser des processus de développement et des architectures d’application qui fonctionnaient parfaitement il y a dix ans, vous ne pourrez tout simplement pas évoluer assez vite pour capter et retenir l’intérêt des utilisateurs mobiles qui peuvent choisir parmi un nombre toujours croissant d’applications.

Le passage à une architecture de microservices crée des opportunités intéressantes sur le marché pour les entreprises. Pour les architectes et les développeurs de systèmes, il promet un niveau de contrôle et de rapidité sans précédent lorsqu'ils proposent de nouvelles expériences Web innovantes aux clients. Mais à un rythme aussi effréné, on peut avoir l’impression qu’il n’y a pas beaucoup de place pour l’erreur. Dans le monde réel, vous ne pouvez pas arrêter de développer et de déployer vos applications à mesure que vous réorganisez les processus pour le faire. Vous savez que votre réussite future dépend de la transition vers une architecture de microservices, mais comment procéder concrètement ?

Heureusement pour nous, plusieurs des premiers utilisateurs 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 également dans des présentations lors de conférences et des articles de blog. Netflix en est un exemple marquant. En tant que directeur de l'ingénierie Web puis architecte Cloud, Adrian Cockcroft a supervisé la transition de l'entreprise d'un modèle de développement traditionnel avec 100 ingénieurs produisant une application monolithique de location de DVD vers une architecture de microservices avec de nombreuses petites équipes responsables du développement de bout en bout de centaines de microservices qui fonctionnent ensemble pour diffuser du divertissement numérique à des millions de clients Netflix chaque jour. Aujourd’hui Technology Fellow chez Battery Ventures, Cockcroft est un éminent évangéliste des microservices et des architectures cloud natives, et siège au conseil consultatif technique de NGINX.

Dans une série d'articles de blog en deux parties, nous présenterons les principaux points à retenir de deux conférences données par Cockcroft l'année dernière, lors de la première conférence annuelle NGINX en octobre et lors d'un Silicon Valley Microservices Meetup quelques mois plus tôt. (Les enregistrements vidéo complets valent également la peine d’être visionnés.)

• Cet article définit l’architecture des microservices et décrit certaines bonnes pratiques pour en concevoir une.
• Adoption des microservices chez Netflix : Lessons for Team and Process Design explique pourquoi et comment adopter un nouvel état d'esprit pour le développement de logiciels et réorganiser vos équipes autour de celui-ci.

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 qui ont des contextes délimités .

Le couplage lâche signifie que vous pouvez mettre à jour les services indépendamment ; la mise à jour d'un service ne nécessite pas de modifier les autres services. Si vous disposez d'un ensemble de petits services spécialisés mais que vous devez toujours les mettre à jour ensemble, ce ne sont pas des microservices car ils ne sont pas faiblement couplés. Un type de couplage que les gens ont tendance à négliger lorsqu’ils passent à une architecture de microservices est le couplage de base de données, où tous les services communiquent avec la même base de données et la mise à jour d’un service signifie modifier le schéma. Vous devez diviser la base de données et la dénormaliser.

Le concept de contextes délimités vient du livre Domain Driven Design d'Eric Evans. Un microservice avec un contexte correctement délimité est autonome aux fins du développement logiciel. Vous pouvez comprendre et mettre à jour le code du microservice sans rien savoir du fonctionnement interne de ses homologues, car le microservice et ses homologues interagissent strictement via des API et ne partagent donc pas de structures de données, de schémas de base de données ou d'autres représentations internes d'objets.

Si vous avez développé des applications pour Internet, vous connaissez déjà ces concepts, en pratique sinon de nom. La plupart des applications mobiles communiquent avec un certain nombre de services back-end pour permettre à leurs utilisateurs de faire des choses comme partager sur Facebook, obtenir des itinéraires depuis Google Maps et trouver des restaurants sur Foursquare, le tout dans le contexte de l'application. Si votre application mobile était étroitement liée à ces services, alors avant de pouvoir publier une mise à jour, vous devriez parler à toutes leurs équipes de développement pour vous assurer que vos modifications ne vont rien casser.

Lorsque vous travaillez avec une architecture de microservices, vous pensez aux autres équipes de développement internes comme à ces backends Internet : comme des services externes avec lesquels votre microservice interagit via des API. Le « contrat » communément accepté entre les microservices est que leurs API sont stables et compatibles avec les évolutions futures. Tout comme il est inacceptable que l’API de Google Maps change sans prévenir et de telle manière qu’elle casse ses utilisateurs, votre API peut évoluer mais doit rester compatible avec les versions précédentes.

Bonnes pratiques pour la conception d'une architecture de microservices

Cockcroft décrit son rôle d'architecte cloud chez Netflix non pas en termes de contrôle de l'architecture, mais comme une découverte et une formalisation de l'architecture qui a émergé au fur et à mesure que les ingénieurs de Netflix la construisaient. L’équipe de développement de Netflix a établi plusieurs bonnes pratiques pour la conception et la mise en œuvre d’une architecture de microservices.

Créer un magasin de données distinct pour chaque microservice

N’utilisez pas le même magasin de données back-end dans tous les microservices. Vous souhaitez que l’équipe de chaque microservice choisisse la base de données la mieux adaptée au service. De plus, avec un seul magasin de données, il est trop facile pour les microservices écrits par différentes équipes de partager des structures de base de données, peut-être au nom de la réduction de la duplication du travail. Vous vous retrouvez dans une situation où, si une équipe met à jour une structure de base de données, d’autres services qui utilisent également cette structure doivent également être modifiés.

La séparation des données peut rendre la gestion des données plus compliquée, car les systèmes de stockage distincts 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 effectue la gestion des données de base (MDM) en fonctionnant en arrière-plan pour rechercher et corriger les incohérences. Par exemple, il peut examiner chaque base de données qui stocke les identifiants des abonnés, pour vérifier que les mêmes identifiants existent dans chacune d'elles (il n'y a pas d'identifiants manquants ou supplémentaires dans une base de données). Vous pouvez écrire votre propre outil ou en acheter un. De nombreux systèmes de gestion de bases de données relationnelles (SGBDR) commerciaux effectuent ce type de vérifications, mais ils imposent généralement trop d'exigences en matière de couplage et ne sont donc pas évolutifs.

Maintenir le code à un niveau de maturité similaire

Gardez tout le code d’un microservice à un niveau de maturité et de stabilité similaire. En d'autres termes, 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é, en laissant le microservice existant en place. [Éditeur – C'est ce que l'on appelle parfois le principe d'infrastructure immuable .] De cette façon, vous pouvez déployer et tester de manière itérative le nouveau code jusqu'à ce qu'il soit exempt de bugs et d'une efficacité maximale, sans risquer 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 à nouveau s'ils remplissent réellement une seule fonction ensemble, ou s'il existe d'autres gains d'efficacité liés à leur combinaison. Cependant, d'après l'expérience de Cockcroft, il est beaucoup plus courant de se rendre compte que vous devez diviser un microservice parce qu'il est devenu trop gros.

Effectuez une build distincte pour chaque microservice

Effectuez une build distincte pour chaque microservice, afin qu'il puisse extraire les fichiers de composants du référentiel aux niveaux de révision qui lui conviennent. Cela conduit parfois à une situation dans laquelle différents microservices récupèrent un ensemble de fichiers similaire, mais à des niveaux de révision différents. Cela peut rendre plus difficile le nettoyage de votre base de code en mettant hors service les anciennes versions de fichiers (car vous devez vérifier plus attentivement qu'une révision n'est plus utilisée), mais c'est un compromis acceptable pour la facilité d'ajout de nouveaux fichiers lorsque vous créez de nouveaux microservices. L'asymétrie est intentionnelle : vous voulez que l'introduction d'un nouveau microservice, d'un nouveau fichier ou d'une nouvelle fonction soit facile et non dangereuse.

Déployer dans des conteneurs

Le déploiement de microservices dans des conteneurs est important car cela signifie que vous n'avez besoin que d'un seul outil pour tout déployer. Tant que le microservice est dans un conteneur, l’outil sait comment le déployer. Peu importe le contenant. Cela dit, Docker semble être très rapidement devenu le standard de facto pour les conteneurs.

Traiter les serveurs comme 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 besoin de vous soucier d’eux individuellement. Votre seule préoccupation est qu'il y en ait suffisamment pour produire la quantité de travail dont vous avez besoin, et vous pouvez utiliser la mise à l'échelle automatique pour ajuster les nombres vers le haut et vers le bas. Si l’un cesse de fonctionner, il est automatiquement remplacé par un autre. Évitez les systèmes « flocon de neige » dans lesquels vous dépendez de serveurs individuels pour exécuter des fonctions spécialisées.

L’analogie de Cockcroft est que vous devez considérer les serveurs comme du bétail et non comme des animaux de compagnie. Si vous avez une machine en production qui exécute une fonction spécialisée, que vous connaissez par son nom, et que tout le monde est triste quand elle tombe en panne, c'est un animal de compagnie. Au lieu de cela, vous devriez considérer vos serveurs comme un troupeau de vaches. Ce qui vous importe, c’est le nombre de litres de lait que vous obtenez. Si un jour vous remarquez que vous obtenez moins de lait que d’habitude, vous identifiez les vaches qui ne produisent pas bien et vous les remplacez.

L'architecture de diffusion de Netflix est basée sur NGINX

Netflix est un utilisateur de longue date de NGINX Open Source et est devenu le premier client de NGINX, Inc. après sa création en 2011. En effet, Netflix a choisi NGINX comme cœur de son infrastructure de diffusion, Open Connect , l’un des plus grands réseaux de diffusion de contenu (CDN) au monde. Avec la capacité de traiter des milliers, et parfois des millions, de requêtes par seconde, NGINX et NGINX Plus sont des solutions optimales pour une diffusion HTTP haute performance et permettent à des entreprises comme Netflix d'offrir des expériences numériques de haute qualité à des millions de clients chaque jour.

Enregistrements vidéo

Livraison rapide
nginx.conf 2014, octobre 2014

Migration vers les microservices, partie 1
Rencontre sur les microservices de la Silicon Valley, août 2014

Migration vers les microservices, partie 2
Rencontre sur les microservices de la Silicon Valley, août 2014