Étape 2 : Organisez vos équipes de manière appropriée

Jusqu'à présent, il pouvait sembler que la mise en place de microservices était essentiellement une affaire technique. Il faut 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, etc. Vous devrez appréhender de nombreux nouveaux concepts, mais la chose la plus importante à ne pas ignorer, c'est que vous devrez restructurer la façon dont vos équipes sont organisées.

La loi de Conway est bien réelle et peut être observée dans tous les types d'équipes. Si une équipe de développement logiciel est organisée avec une équipe de back-end, une équipe front-end et une équipe opérationnelle travaillant indépendamment, elle livrera aveuglément des monolithes front-end et back-end distincts à l'équipe opérationnelle pour les mettre en production. Ce type de structure n'est pas approprié pour les microservices, car chaque service doit être considéré comme son propre produit qui doit être livré indépendamment des autres.

Au lieu de cela, vous devriez créer des équipes DevOps plus petites qui possèdent toutes les compétences nécessaires pour développer et maintenir les services dont elles sont responsables. Cette organisation des équipes présente des avantages importants. Tout d'abord, vos développeurs ont une meilleure compréhension de l'impact de leur code en production. Cela les aide à produire de meilleures versions et réduit le risque de voir des problèmes livrés aux clients. Ensuite, les déploiements deviennent une seconde nature pour chaque équipe, car elles travaillent ensemble sur des améliorations du code ainsi que l'automatisation du pipeline de déploiement.

Étape 3 : fractionnez le monolithe pour développer une architecture de microservices

Lorsque vous avez identifié les limites de vos services et compris comment restructurer vos équipes, vous pouvez commencer à fractionner votre monolithe afin de créer des microservices. Voici les points clés à prendre en compte à ce moment-là.

Veillez à ce que communication entre les services reste simple grâce aux API REST

Si vous n'utilisez pas déjà une API RESTful, c'est le moment idéal pour l'adopter. Comme l'explique Martin Fowler, vous souhaitez avoir « des points d'ancrage intelligents et des pipes stupides ». Cela signifie que le protocole de communication entre vos services doit être aussi simple que possible, et uniquement transmettre les données, sans les altérer. La magie opère dans les points d'ancrage eux-mêmes : ils reçoivent une demande, la traitent et émettent une réponse en retour.

Les architectures de microservice s'efforcent de maintenir la simplicité afin d'éviter un couplage étroit des composants. Dans certains cas, vous pouvez utiliser une architecture orientée événement grâce à des communications asynchrones basées sur des messages. Mais encore une fois, vous devriez vous pencher sur des services de file d'attente de messages de base tels que RabbitMQ et éviter d'ajouter de la complexité aux messages transmis sur le réseau.

Divisez les données en contextes ou domaines de données définis

Les apps monolithiques utilisent une base de données unique pour toutes leurs fonctionnalités métier. À mesure qu'un monolithe est fractionné en microservices, cette base de données unique peut ne plus être judicieuse. Une base de données centrale peut devenir un goulot d'étranglement pour l'évolution du trafic. Si un service particulier accède à la base de données avec une charge élevée, il peut interrompre l'accès à la base de données d'autres services. En outre, une base de données unique peut se transformer en goulot d'étranglement de collaboration pour plusieurs équipes qui tentent de modifier simultanément le schéma. Cela peut nécessiter la fragmentation de la base de données ou l'ajout d'outils de stockage de données supplémentaires pour répondre aux besoins de données des 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. Cette planification de schéma peut être effectuée à l'aide de contextes définis, qui sont un modèle de design orienté domaine. Un contexte défini délimite un système autonome, notamment ce qui peut entrer et sortir de ce système.

Dans ce système, lorsqu'un utilisateur accède à une commande, vous pouvez afficher les informations client dans le tableau, qui peut également être utilisé pour remplir la facture gérée par le système de facturation. Cela peut sembler logique et simple, mais avec les microservices, les services doivent être découplés afin que les factures soient accessibles même si le système de commande est en panne. En outre, ils vous permettent d'optimiser ou de faire évoluer le tableau des factures indépendamment des autres. Chaque service peut finir par avoir sa propre base de données pour accéder aux données dont il a besoin.

Cela introduit de nouveaux problèmes, car des données seront inévitablement dupliquées dans différentes bases de données. Les contextes définis peuvent identifier la meilleure stratégie pour gérer les données partagées ou dupliquées. Vous pouvez adopter une architecture orientée événements afin de faciliter la synchronisation des données entre plusieurs services. Par exemple, vos services de suivi de facturation et de livraison peuvent être à l'écoute des événements émis par le service de compte lorsque des clients mettent à jour leurs informations personnelles. À la réception de l'événement, ces services mettront à jour leur base de données en conséquence. Cette architecture orientée événement permet de maintenir la simplicité du service de compte, car elle n'a pas besoin de connaître les autres services dépendants. Elle indique simplement au système ce qu'elle a fait et les autres services écoutent et agissent en conséquence.

Vous pouvez également choisir de conserver toutes les informations relatives aux clients dans le service de compte et de ne conserver qu'une référence de clé étrangère dans votre service de facturation et de livraison. Ces services interagissent alors avec le service de compte pour obtenir les données pertinentes sur le client, au lieu de dupliquer les enregistrements existants. Puisqu'il n'y a pas de solution universelle pour ces problèmes, vous devrez examiner chaque cas spécifique pour déterminer la meilleure approche.

Développez votre architecture de microservices pour les pannes

Nous avons vu les grands avantages des microservices par rapport à une architecture monolithique. Ils sont plus petits et spécialisés, ce qui les rend faciles à comprendre. Ils sont dissociés, ce qui signifie que vous pouvez remanier un service sans crainte d'endommager les autres composants du système ou de ralentir le développement des autres équipes. Ils offrent également plus de flexibilité à vos développeurs qui peuvent choisir différentes technologies si nécessaire sans être contraints par les besoins d'autres services.

En bref, disposer d'une architecture de microservices facilite le développement et la maintenance de chaque capacité métier. Mais les choses se compliquent lorsque vous regardez l'ensemble des services et la manière dont ils doivent interagir pour exécuter des actions. Votre système est maintenant distribué avec plusieurs points de défaillance, et vous devez y faire face. Vous devez prendre en compte non seulement les cas où un service ne répond pas, mais également être en mesure de gérer des réponses réseau plus lentes. La reprise d'activité suite à une panne peut également s'avérer difficile à certains moments, car vous devez vous assurer que les services qui sont remis en route ne sont pas saturés par les messages en attente.

Quand vous commencez à extraire des capacités de vos systèmes monolithiques, assurez-vous que vos designs sont conçus dès le début en pensant aux possibles défaillances.

Mettez l'accent sur la surveillance pour faciliter les tests de microservices

Les tests constituent un autre inconvénient des microservices par rapport à un système monolithique. Une application développée en tant que base de code unique n'a pas besoin de grand-chose pour que son environnement de test soit opérationnel. Dans la plupart des cas, vous devrez démarrer un serveur back-end couplé à une base de données pour pouvoir exécuter votre suite de tests.

Dans l'univers des microservices, tout n'est pas aussi simple. Les tests unitaires seront encore assez similaires à ceux du monolithe et cela ne devrait pas vous sembler compliqué. Cependant, lorsqu'il est question d'intégration et de tests système, les choses se compliquent. Vous devrez peut-être démarrer plusieurs services à la fois, disposer de différentes bases de données opérationnelles, et votre configuration peut nécessiter des files d'attente de messages dont vous n'aviez pas besoin avec votre monolithe. Dans cette situation, effectuer des tests fonctionnels devient beaucoup plus coûteux, et le nombre croissant de pièces mobiles rend très difficile la prédiction des différents types de défaillances potentielles.

La surveillance permet d'identifier les problèmes rapidement et de répondre en conséquence. Vous devrez comprendre les bases de référence de vos différents services et réagir non seulement lorsque ces services tombent en panne, mais aussi lorsqu'ils se comportent de façon inattendue. L'un des avantages de l'adoption d'une architecture de microservices est que votre système doit être résilient à une défaillance partielle. Par conséquent, si vous commencez à observer des anomalies dans le service de suivi de livraison de notre app Pizzup, ce ne sera pas aussi grave que s'il s'agissait d'un système monolithique. Notre app doit être conçue de manière à ce que tous les autres services répondent correctement et permettent à nos clients de commander des pizzas pendant que nous restaurons le suivi en direct.

Adoptez la livraison continue pour réduire les frictions de déploiement

Livrer manuellement un système monolithique en production est un effort fastidieux et risqué, mais réalisable. Bien sûr, nous ne recommandons pas cette approche et encourageons chaque équipe de développement à adopter la livraison continue pour tous les types de développement, mais au début d'un projet, vous pouvez effectuer vos premiers déploiements vous-même via la ligne de commande.

Cette approche n'est pas durable lorsque vous disposez d'un nombre croissant de services qui doivent être déployés plusieurs fois par jour. Par conséquent, dans le cadre de votre transition vers les microservices, l'adoption de la livraison continue est essentielle afin de réduire les risques d'échec de livraison, et de 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. Pratiquer la livraison continue signifie également que votre service a réussi les tests d'acceptation avant d'être déployé en production. Bien sûr, des bugs surviendront, mais au fil du temps, vous développerez une suite de tests robuste qui devrait augmenter la confiance de votre équipe dans la qualité des livraisons.