Comment le passage à des microservices crée-t-il un problème d'exécution?

Le commentateur suivant écrit :

Les microservices font passer votre dysfonctionnement organisationnel d’un problème de compilation à un problème d’exécution.

Ce commentateur développe la question en disant:

Fonctionnalité pas bug. Problème d'exécution => problèmes de production => un retour d'information plus fort et plus rapide sur le dysfonctionnement aux responsables

Maintenant, je comprends cela avec microservices vous:

• potentiellement augmenter la latence de votre débit - ce qui est un problème de production et d'exécution.
• augmentez le nombre d '«interfaces réseau» dans votre code là où il pourrait y avoir des erreurs d'analyse lors de l'exécution.
• peut potentiellement faire des déploiements bleu-vert. Celles-ci pourraient être bloquées par des inadéquations d'interface (voir interfaces réseau). Mais si les déploiements bleu-vert fonctionnent, il s'agit davantage d'une préoccupation d'exécution.

Ma question est la suivante: que signifie le fait de passer à microservices pour créer un problème d'exécution?

J'ai un problème. Utilisons Microservices! Maintenant, j'ai 13 problèmes distribués.

Diviser votre système en composants encapsulés, cohésifs et découplés est une bonne idée. Cela 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 plusieurs décennies! Si vous décidez de transformer vos composants en microservices, vous ne gagnez aucun avantage architectural. Vous gagnez en flexibilité en matière de choix technologique et éventuellement (mais pas nécessairement!) En matière d'évolutivité. Mais vous avez la garantie de souffrir de maux de tête provenant (a) de la nature distribuée du système et (b) de la communication entre les composants. Le choix de microservices signifie que vous avez d’autres problèmes tellement pressants que vous êtes prêt à utiliser des microservices malgré ces problèmes.

Si vous ne pouvez pas concevoir un monolithe proprement divisé en composants, vous ne pourrez pas non plus concevoir de système de microservice. Dans une base de code monolithique, la douleur sera assez évidente. Idéalement, le code ne sera tout simplement pas compilé s'il est horriblement cassé. Mais avec les microservices, chaque service peut être développé séparément, éventuellement dans différentes langues. Les problèmes d'interaction entre les composants ne deviendront apparents que lorsque vous aurez intégré vos composants. À ce stade, il est déjà trop tard pour réparer l'architecture globale.

La source n ° 1 de bogues est une incompatibilité d'interface. Il peut y avoir des erreurs flagrantes telles qu'un paramètre manquant ou des exemples plus subtils tels que l'oubli de la vérification d'un code d'erreur ou de la vérification d'une condition préalable avant d'appeler une méthode. Le typage statique détecte ces problèmes le plus tôt possible: dans votre IDE et dans le compilateur, avant que le code ne soit exécuté. Les systèmes dynamiques n'ont pas ce luxe. Il ne va pas exploser avant que ce code défectueux soit 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 vérifier aucun type de correction de l'utilisation de votre interface. vous devez tester, tester, tester! Mais les tests sont coûteux et ne sont généralement pas exhaustifs, ce qui laisse la possibilité que des problèmes persistent dans la production. Quand ce problème deviendra-t-il apparent? Uniquement lorsque ce chemin défectueux est pris, au moment de l'exécution, en production. L'idée que les problèmes de produiraient des retours plus rapides esthilarant dangereusement faux, à moins que la possibilité d’une perte de données ne vous amuse.

Le premier tweet était le mien, alors je vais développer:

Supposons que vous avez 100 développeurs travaillant sur une application monolithique. C’est trop de personnes pour communiquer efficacement entre elles. L’entreprise doit donc travailler dur pour les diviser en équipes plus petites et créer de bonnes habitudes 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 ne sont pas d'accord sur les priorités, etc. - en conséquence, il leur faut une éternité pour envoyer quelque chose. C'est un "problème de compilation" dans le sens où le dysfonctionnement est évident avant la production du logiciel. Le projet est probablement une marche de la mort ou ne sera jamais expédier ("compiler").

Je pense que beaucoup de gens sont attirés par les micro-services et y ont recours, non pas pour des avantages techniques / architecturaux, 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 petites é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 personnes 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 production, une bonne communication devient tout aussi importante. Les problèmes avec l'organisation - les équipes et leur alignement et leur communication - se manifestent au "moment de l'exécution".

Le but de mon tweet était: si ce que vous avez est un problème de personnes , une nouvelle architecture ne va pas aider. Cela ne fera que retarder les effets du problème. Je pense que l’attrait des micro-services pour un grand nombre de personnes est l’espoir qu’il va résoudre par magie ces problèmes de personnes.

Ma question est la suivante: que signifie le fait de passer à microservices pour créer un problème d'exécution?

Ce n'est pas ce que disent ces tweets! Ils ne disent rien sur le passage aux microservices , ni sur la création de problèmes. Ils ne parlent que de problèmes changeants .

Et ils ont mis une restriction contextuelle à leurs affirmations, à savoir que votre organisation est dysfonctionnelle.

En gros , le premier tweet dit deux choses:

• "si votre organisation est incapable de concevoir des systèmes complexes sans microservices, elle ne pourra pas, comme 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 tests inférieur à la norme)

Le deuxième tweet indique que le fait que les problèmes ne se manifestent qu’en production, c’est-à-dire lorsque les clients les voient, est une fonctionnalité et non un bogue, car lorsque les clients se plaignent, ils ont tendance à être entendus à des endroits différents de ceux qui se présentent lorsqu’une construction est interrompue, à savoir: dans des endroits où il est possible de faire quelque chose à propos du 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 ont un impact négatif sur ceux qui sont responsables en dernier ressort de cette insatisfaction, alors que la qualité médiocre du code provoquée par des échecs de gestion de niveau supérieur ne reflète généralement que de mauvais Cependant, pas en faute et incapable de faire quelque chose à ce sujet.

Ainsi, le premier tweet indique que les microservices déplacent les problèmes causés par une mauvaise gestion 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 les problèmes affectent donc ceux qui en sont responsables.

Cela crée un problème d'exécution par opposition à un problème de compilation .

Une application monolithique est difficile et coûteuse à compiler. Mais une fois la compilation compilée, vous pouvez être raisonnablement sûr qu’aucune incompatibilité extrêmement stupide n’existe entre les composants, car le système de types peut les intercepter. La même erreur dans un système de microservifs peut ne pas apparaître jusqu'à ce que deux composants spécifiques interagissent réellement d'une manière spécifique.

Dans les systèmes monolithiques et 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, microservices ne résoudra pas non plus le problème. Dans les microservices, vous avez des 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 rencontrerez deux types de problèmes d'exécution:

1. 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.
2. L'appel d'une interface Web est assez lent, vous pouvez donc avoir des problèmes de performances.

Je pense que produire des problèmes d'exécution n'est pas la bonne façon de résoudre les problèmes d'organisation de la communication avec les responsables.