Microservices - Que signifie déployer et mettre à niveau indépendamment?
Dans cet article , il est mentionné (soulignement le mien):
... le style architectural des microservices est une approche pour développer une seule application en tant que suite de petits services, chacun s'exécutant dans son propre processus et communiquant avec des mécanismes légers, souvent une API de ressource HTTP. Ces services sont construits autour de capacités commerciales et déployables indépendamment par des machines de déploiement entièrement automatisées.
Ma compréhension est que si le microservice 1 a une dépendance temporelle de construction avec le microservice 2, alors ce n'est pas un microservice.
En ce qui concerne le microservice 1 et le microservice 2, si la prochaine version du microservice 2 a une nouvelle fonctionnalité qui est consommée par la prochaine version du microservice 1, lors d'un appel API HTTP spécifique, que signifie le microservice 1 mis à niveau indépendamment? Parce que la prochaine version du microservice 1 a une dépendance (maven deploy (not build) dependency in Java) sur la prochaine version du microservice 2.
Cette caractéristique s'oppose à un monolithe et signifie que vous n'avez pas besoin de déployer deux services côte à côte.
Dans le cas d'un monolithe, si vous souhaitez déployer un changement dans une partie, vous devez déployer le monolithe entier . Cela signifie que vous avez essentiellement trois problèmes:
Supposons que vous êtes prêt à déployer votre modification, mais l'autre équipe travaillant sur une autre partie du monolithe effectue une modification importante pour l'une des fonctionnalités, et leur code ne peut pas être déployé dans son état actuel. Pour cette raison, vous ne pouvez pas déployer vos modifications en production pour le moment .
Toute sortie nécessite alors une communication entre les équipes. La communication entre équipes est exactement ce que les microservices essaient d'éviter.
Le déploiement d'un monolithe est assez complexe. Une complexité plus élevée entraîne un risque plus élevé de casser quelque chose en production, ce qui signifie que l'équipe serait encline à se déployer moins fréquemment.
Dans le cas de services indépendants, vous pouvez déployer un seul service dès maintenant, sans communiquer avec d'autres équipes. Ils peuvent faire une refactorisation importante, ou ils peuvent déployer eux-mêmes certains changements dans la production, ou ils peuvent être en vacances pour les quatre prochaines semaines. Vous ne vous en souciez pas, car votre service est déployable indépendamment .
Considérez ces services comme étant développés par différentes entreprises. Par exemple, vous pouvez utiliser Amazon AWS. Quand Amazon publie une nouvelle fonctionnalité, (1) il ne vous demande pas la permission de le faire, et (2) il ne vous oblige pas à publier la nouvelle version de votre application en même temps qu'elle ne libère la nouvelle fonctionnalité. Amazon fait les versions à son rythme, et vous le faites à la vôtre.
Remarque: cette réponse est basée sur Microservices par Eberhard Wolff. Si vous êtes intéressé par plus de détails, vous pourriez être intéressé par la lecture du livre.
Un déploiement véritablement indépendant signifie que vous pouvez mettre à niveau l'un ou l'autre service dans n'importe quel ordre et rester dans un état de fonctionnement. Évidemment, ne pas avoir de dépendances du tout est idéal, mais quelque peu impraticable. Si vous avez des dépendances entre les microservices, vous pouvez toujours les déployer indépendamment:
Dans votre exemple, le microservice 2 peut être mis à niveau à tout moment, à condition qu'il conserve la compatibilité descendante.
Le microservice 1 peut également être mis à niveau à tout moment, à condition qu'il vérifie la compatibilité du microservice 2 et désactive sa nouvelle fonctionnalité ou se replie de manière appropriée si ses nouvelles dépendances ne sont pas encore disponibles.
Cette deuxième méthode semble un peu… inutile. Pourquoi ne pas simplement éviter les tracas et mettre à niveau le microservice 2 en premier? J'admets que c'est généralement ce que j'essaie de faire, mais la mise à niveau du microservice 1 présente d'abord quelques avantages imprévus.
Tout d'abord, cela améliore la gestion des erreurs et le dépannage plus tard si le microservice 2 rencontre des problèmes et doit être annulé. Deuxièmement, ce sont souvent les clients qui ont une meilleure idée de ce à quoi devrait ressembler cette nouvelle interface. J'ai constaté que faire les clients en premier peut parfois minimiser les allers-retours pour obtenir la bonne interface. Troisièmement, il permet le déploiement sur des systèmes de test avec un microservice en boîte ou prototype 2, pour obtenir un retour rapide avant d'engager trop de ressources pour développer la nouvelle fonctionnalité sur le microservice 2.
En d'autres termes, vous faites des efforts supplémentaires pour éviter de vous retrouver dans une situation où vous devez basculer un commutateur et mettre à niveau chaque service interdépendant en même temps. Ces mises à niveau spectaculaires comportent de nombreux risques.
Pour moi, cela est important car vous pouvez publier des modifications par petits lots et gérer les régressions d'intégration beaucoup plus facilement.
Avec un monolithe, vous modifiez une zone de fonctionnalité, construisez et déployez le tout et espérez que tout se passe bien. Avec les services indépendants, il est beaucoup plus facile de déployer de petits morceaux et de s'assurer qu'ils continuent à bien jouer.
Disons que vous avez le service A qui gère quelque chose, et que la v1 est actuellement en production. Tous les consommateurs utilisent l'API v1. Vous introduisez des fonctionnalités mises à jour sous une API v2. Vous maintenez la compatibilité descendante sur l'API v1 et pouvez libérer "silencieusement" l'API v2, et aucun de vos services consommateurs n'a besoin d'être connu ou soigné. Le service A prend désormais en charge les API v1 et v2, et vos autres consommateurs peuvent alors commencer la migration vers les appels S1.v2.
Avec des monolithes complexes, il s'agit d'un processus très difficile et dangereux, en particulier lorsque vous exécutez plusieurs applications différentes sur une base de code partagée dans un environnement d'entreprise. Alors que les microservices nécessitaient beaucoup plus de discipline dans de nombreux domaines, il vous permet d'effectuer vos `` grands changements de système '' en petits morceaux et sans tous les facteurs externes qui font des mises à jour complexes de monolithes un véritable ours.
Nous pouvons quelque peu le comparer au refactoring du code ... lorsque nous refactorisons le code, nous avons tendance à le faire en petits morceaux à la fois, vérifiez pour s'assurer qu'ils fonctionnent, puis empaquetez le tout. J'ai tendance à trouver une utilisation pratique des microservices est similaire, mais au niveau des composants à la place: nous pouvons faire de petites mises à jour de divers composants sans rien casser, et quand tout fonctionne sûrement bien, les anciennes API et leurs implémentations peuvent être retirées.
Mis à part les avantages souvent vantés de ne nécessiter aucune connaissance extérieure, l'équipe de service possédant entièrement le service, aucune dépendance interservices, etc., cette capacité à effectuer des versions complexes en petites étapes en raison de l'indépendance est un avantage pratique important de travailler avec des architectures de microservices.