Comment le passage aux microservices crée-t-il un problème d'exécution?
Ce qui suit le commentateur écrit :
Les microservices font passer votre dysfonctionnement organisationnel d'un problème de compilation à un problème d'exécution.
Cette commentateur développe sur le problème en disant:
Fonctionnalité pas bug. Problème d'exécution => problèmes de prod => retour d'information plus fort et plus rapide sur le dysfonctionnement aux responsables
Maintenant, je obtenez cela avec microservices vous:
- potentiellement augmenter la latence de votre débit - ce qui est une préoccupation de production et d'exécution.
- augmentez le nombre d '"interfaces réseau" dans votre code où il pourrait y avoir des erreurs d'exécution possibles lors de l'analyse.
- peut potentiellement faire des déploiements bleu-vert. Ceux-ci pourraient être bloqués par des asymétries d'interface (voir interfaces réseau). Mais si les déploiements bleu-vert fonctionnent, c'est plus une préoccupation d'exécution.
Ma question est: Qu'est-ce que cela signifie que le passage aux microservices crée un problème d'exécution?
J'ai un problème. Utilisons les microservices! Maintenant, j'ai 13 problèmes distribués.
La division de votre système en composants encapsulés, cohésifs et découplés est une bonne idée. Il vous permet d'aborder différents problèmes séparément. Mais vous pouvez parfaitement le faire dans un déploiement monolithique (voir Fowler: Microservice Premium ). Après tout, c'est ce que OOP enseigne depuis de nombreuses décennies! Si vous décidez de transformer vos composants en microservices, vous ne gagnez aucun avantage architectural. Vous gagnez une certaine flexibilité concernant le choix de la technologie et éventuellement (mais pas nécessairement!) une certaine évolutivité. Mais vous avez la garantie de maux de tête résultant de (a) la nature distribuée du système, et (b) de la communication entre les composants. Le choix des microservices signifie que vous avez d'autres problèmes si pressants que vous sont prêts à utiliser des microservices malgré ces problèmes.
Si vous ne parvenez pas à concevoir un monolithe proprement divisé en composants, vous ne pourrez pas non plus concevoir un système de microservices. Dans une base de code monolithique, la douleur sera assez évidente. Idéalement, le code ne se compilera tout simplement pas s'il est horriblement cassé. Mais avec les microservices, chaque service peut être développé séparément, éventuellement même dans différentes langues. Aucun problème dans l'interaction des composants ne deviendra apparent jusqu'à ce que vous intégriez vos composants, et à ce stade, il est déjà trop tard pour réparer l'architecture globale.
La source de bogues n ° 1 est la discordance d'interface. Il peut y avoir des erreurs flagrantes comme un paramètre manquant, ou des exemples plus subtils comme oublier de vérifier un code d'erreur, ou oublier de vérifier une condition préalable avant d'appeler une méthode. La saisie statique détecte ces problèmes le plus tôt possible: dans votre IDE et dans le compilateur, avant le code s'exécute jamais. Les systèmes dynamiques n'ont pas ce luxe. Il n'explosera pas tant que ce code défectueux ne sera pas exécuté.
Les implications pour les microservices sont terrifiantes. Les microservices sont intrinsèquement dynamiques. Sauf si vous passez à un langage de description de service formel, vous ne pouvez pas vérifier l'exactitude de l'utilisation de votre interface. vous devez tester, tester, tester! Mais les tests sont coûteux et généralement non exhaustifs, ce qui laisse la possibilité que des problèmes puissent encore exister dans la production. Quand ce problème deviendra-t-il apparent? Seulement lorsque ce chemin défectueux est pris, au moment de l'exécution, en production. L'idée que les problèmes de prod entraîneraient une rétroaction plus rapide est hilarante dangereusement faux, à moins que vous ne soyez amusé par la possibilité de perte de données.
Le premier Tweet était le mien, je vais donc en parler:
Supposons que vous ayez 100 développeurs travaillant sur une application monolithique. C'est trop de personnes pour communiquer efficacement entre elles, donc l'entreprise doit travailler dur pour les diviser en équipes plus petites et créer de bons modèles de communication entre elles. Lorsque l'organisation est "dysfonctionnelle", les équipes ne se parlent probablement pas, elles ne sont pas alignées sur un objectif plus large, elles sont en désaccord sur les priorités, etc. - en conséquence, cela leur prend une éternité pour expédier quelque chose. C'est un "problème de temps de compilation" dans le sens où le dysfonctionnement est évident avant la production du logiciel. Le projet est probablement une marche vers la mort ou ne sera jamais expédié ("compiler").
Je pense que beaucoup de gens sont attirés par les microservices et y vont, non pas à cause des avantages techniques/architecturaux inhérents, mais parce que cela leur permet d'ignorer le dysfonctionnement organisationnel. Au lieu d'essayer d'aligner 100 développeurs, ils espèrent pouvoir disposer de minuscules équipes travaillant en silos, chacune concentrée sur son propre petit micro service. Si vous êtes dans une organisation aussi dysfonctionnelle, c'est tellement attrayant: cela vous donne une bien plus grande permission d'éviter les gens que vous n'aimez pas, de ne pas communiquer.
Malheureusement, cela devient un "problème d'exécution" car une fois que le logiciel est en cours de production, une bonne communication devient tout aussi importante. Les problèmes avec l'organisation - les équipes et la façon dont elles sont alignées et communiquent - se manifestent au "moment de l'exécution".
Le point de mon Tweet était: si ce que vous avez est un problème personnes, une nouvelle architecture ne va pas aider. Cela ne fera que retarder les effets du problème. Je pense que l'attrait des microservices pour de nombreuses personnes est l'espoir qu'il résoudra comme par magie ces problèmes de personnes.
Ma question est: Qu'est-ce que cela signifie que le passage aux microservices crée un problème d'exécution?
Ce n'est pas ce que disent ces tweets! Ils ne disent rien sur le déplacement vers les microservices, ni sur les problèmes création. Ils disent seulement quelque chose sur problèmes de déplacement.
Et ils mettent une restriction contextuelle à leurs affirmations, à savoir que votre organisation est dysfonctionnelle.
Donc, ce que le premier Tweet dit essentiellement est deux choses:
- "si votre organisation est incapable de concevoir des systèmes complexes sans microservices, elle ne pourra pas par magie concevoir des systèmes complexes avec des microservices" et
- "les problèmes causés par cette incapacité qui apparaissent maintenant pendant la compilation, c'est-à-dire pendant le développement, apparaîtront ensuite pendant l'exécution, c'est-à-dire en production" (techniquement, ils pourraient également apparaître pendant les tests, mais rappelez-vous, la citation se limite aux organisations dysfonctionnelles, qui ont probablement un régime de test inférieur aux normes)
Le deuxième Tweet dit que le fait que les problèmes ne se manifestent qu'en production, c'est-à-dire là où les clients les voient, est une fonctionnalité, pas un bug, car lorsque les clients se plaignent que cela a tendance à être entendu à différents endroits que lorsqu'une construction se brise, à savoir dans des endroits qui sont capables de faire quelque chose pour le dysfonctionnement organisationnel (par exemple, une gestion de haut niveau). Étant donné que le dysfonctionnement organisationnel est généralement un échec de la gestion de haut niveau, cela signifie que les clients insatisfaits réfléchissent mal sur ceux qui sont en fin de compte responsables de cette insatisfaction, tandis que la faible qualité du code causée par des échecs de gestion de niveau supérieur ne reflète généralement mal que les développeurs, qui sont , cependant, pas en faute et incapable de faire quelque chose.
Ainsi, le premier Tweet dit que les microservices déplacent les problèmes causés par une mauvaise gestion du moment de la compilation, où seuls les développeurs les voient, à l'exécution, où les clients les voient. Le deuxième Tweet dit que c'est une bonne chose, car alors, les problèmes blessent ceux qui en sont responsables.
Il crée un problème d'exécution par opposition à un problème de temps compilation -.
Une application monolithique est difficile et coûteuse à compiler. Mais une fois qu'il est compilé, vous pouvez être raisonnablement sûr qu'aucune incompatibilité extrêmement stupide entre les composants n'existe, car le système de type peut les détecter. La même erreur dans un système de microservices peut ne pas apparaître jusqu'à ce que deux composants spécifiques en fait interagissent d'une manière spécifique.
Tant dans les systèmes monolithiques que dans les microservices, vous devez définir des interfaces entre les sous-systèmes. Les interfaces doivent être bien conçues, bien documentées et aussi stables que possible. C'est la même chose qu'en POO.
Si votre organisation n'est pas en mesure de le faire, les microservices ne résoudront pas non plus le problème. Dans les microservices, vous disposez d'interfaces Web publiques. Vous devez donc même consacrer plus d'efforts à la conception d'interfaces.
Si l'interface n'est pas conçue correctement, vous obtiendrez deux types de problèmes d'exécution:
- Si l'interface n'est pas utilisée correctement, vous obtiendrez une erreur au moment de l'exécution, pas au moment de la compilation.
- L'appel d'une interface Web est assez lent, vous pouvez donc rencontrer des problèmes de performances.
Je pense que la production de problèmes d'exécution n'est pas la bonne façon de communiquer les problèmes organisationnels à ceux qui sont responsables.