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

104

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?

microservices runtime compile-time

— oeil de faucon
source

13

Si A parle à B dans un monolithe au moins, l'interface réelle peut être prouvée compatible (par le biais du typage statique), ce qui la rend plus probable, elle est également correcte. Habituellement, les microservices communiquent sur quelque chose sans ces vérifications de compilation

— Richard Tingle

Si vous étudiez les problèmes liés à l’utilisation de microservices, vous devez lire l’article de Fowler. martinfowler.com/articles/microservices.html Je crois que ce n'est pas simplement un cas de temps de compilation vs exécution, comme le dit @Richard Tingle. Et ne croyez pas vraiment qu’un problème de production est préférable à un problème en développement. Mais les microservices peuvent aider à dimensionner les grands projets de différentes manières. (Et sont exagérés pour la plupart des petits projets)

— Borjab le

2

Ce commentateur est myope. Problème d'exécution => problèmes de production => utilisateurs mécontents => argent perdu.

— Philipp

@ Philippe: C'est le point. Compiler les problèmes de temps causés par un dysfonctionnement organisationnel => personne ne s'en soucie. Les pertes d’argent causées par un dysfonctionnement organisationnel => affectent précisément les responsables de ce dysfonctionnement organisationnel. L'espoir: le dysfonctionnement organisationnel est corrigé plus rapidement.

— Jörg W Mittag

194

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 est~~hilarant~~ dangereusement faux, à moins que la possibilité d’une perte de données ne vous amuse.

— Amon
source

13

@JacquesB Je suis convaincu que le «dysfonctionnement organisationnel» fait référence à l'incapacité de développer un système. La majorité de ma réponse est un contexte illustrant comment on peut arriver à une telle conclusion, mais c’est mon opinion professionnelle et non tirée du tweet.

— amon

10

"monolith qui est clairement divisé en composants" - qu'est-ce que ça veut dire?

10

Et sans parler de la gestion des versions des interfaces (les interfaces évoluant dans le temps).

— Peter Mortensen

12

@mobileink Monolith n'est pas un terme idéal ici car il suggère «pas d'architecture». Mais ce que j'essaie de faire comprendre, c’est un système développé et déployé en tant que système unique, par opposition à une architecture orientée services où des parties du système peuvent être déployées indépendamment. S'il vous plaît éditer le poste si vous connaissez un meilleur terme…

— amon

7

@ amon En entendant le mot Monolith, on n'évoque pas immédiatement l'idée de "pas d'architecture". La plupart des bâtiments sont des monolithes, de même que les grandes pyramides d'Égypte et de nombreux autres éléments. Clairement, ils ont été architecturés et livrés dans leur ensemble. De nombreux systèmes logiciels n'ont pas une bonne architecture. mais le manque de bonne architecture semble être indépendant de la manière dont elles sont déployées. Vous pouvez emprunter une partie de l'échafaudage d'un autre projet et l'appeler architecture (3 niveaux, 2 niveaux, n niveaux, microservice, etc.), mais cela ne garantit pas que vous l'avez bien fait.

— Edwin Buck

215

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.

— Paul Stovell
source

67

+1 C'est beaucoup mieux comme réponse Stack Exchange que comme tweet. :-)

— ruakh

3

La même chose est vraie pour tous les systèmes dynamiques. La frappe dynamique est très utile, mais seulement si vous avez les bonnes personnes. Les "bases de données de forme libre" sont très utiles, mais seulement si vous avez les bonnes personnes. Si vous n'avez pas les bonnes personnes, vous ne faites que déléguer les problèmes, pas les résoudre.

— Luaan

2

Je pense que c'est une tautologie. Quand les gens sont le problème, les problèmes peuvent se manifester partout. Je ne peux pas imaginer livrer une solution fonctionnant sous la forme d'un ensemble de microservices sans tests d'intégration appropriés. Dans ce cas, il n’existe aucun moyen d’expédier une solution avec un flux de travail pris en charge. Si quelqu'un passe à des microservices avec des tests hors flux, en particulier pour masquer des problèmes, c'est le problème. Vous pourriez également envoyer des fichiers binaires non testés / cassés. Il élève le problème des programmeurs de niveau Trooper plus haut, là où il appartient.

— luk32

10

@ luk32 En partie, oui, mais l'essentiel des microservices qui attirent les mauvaises équipes est de faire en sorte que vos compétences et votre déficit de communication passent inaperçus pendant une période plus longue. Ce n'est pas une question d'avoir les problèmes ou pas, c'est quand ils vont arriver

— T. Sar - Réintégrer Monica

18

Très belle réponse. Merci d'avoir confirmé mon opinion de Twitter comme étant totalement inutile pour autre chose que de provoquer les gens.

— Robert Harvey

43

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.

— Jörg W Mittag
source

6

Si vous ne pouvez @ Michael ne vois pas comment leur impact sur la qualité du code, peut - être envisager l' impact - le cas échéant - la direction a sur une partie de la qualité des produits de leur entreprise crée.

— WJL

30

@ Michael: Tout est finalement causé par une gestion de niveau supérieur. La mauvaise qualité du code est-elle causée par des délais impossibles? Qui fixe ces délais? Qui dit à ceux qui fixent ces délais de fixer ces délais? La mauvaise qualité du code est-elle causée par des développeurs incompétents? Qui a embauché ces développeurs incompétents? Qui a embauché ceux qui ont embauché ces développeurs incompétents? Est-ce causé par un outillage inapproprié? Qui achète ces outils? Qui approuve le budget pour acheter ces outils? C'est causé par une architecture stupide? Qui a engagé l'architecte? Qui l'a mis en charge? Ces tweets étaient spécifiquement dans le contexte…

— Jörg W Mittag

13

… Dysfonctionnement organisationnel. Eh bien, ce qui rend la fonction de l' organisation est à peu près L' emploi de la gestion de niveau supérieur. C'est ce que la gestion est .

— Jörg W Mittag

4

Même si cela fonctionnera probablement à long terme, l'idée de résoudre les problèmes de votre entreprise en leur donnant un impact sur les clients ne semble pas correcte.

— Stijn de Witt

1

@ JörgWMittag Je ne pense pas qu'il soit raisonnable de prétendre qu'un mauvais code écrit par de mauvais développeurs est la faute des personnes qui ont embauché ces mauvais développeurs et non les mauvais développeurs eux-mêmes. Cela pourrait en fin de compte être la responsabilité de la direction, mais cela est causé par les développeurs.

— Miles Rout

9

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.

— Kilian Foth
source

9

Cela semble supposer que les applications "monolithiques" sont toujours typées statiquement. Qu'en est-il des langues typées dynamiquement? Et qu'en est-il des interfaces de service statiquement typées?

— JacquesB

1

@JacquesB OTOH, je peux penser à zéro langage compilé dynamiquement typé.

— user253751

2

@JacquesB JavaScript et Python ne sont pas compilés. À moins que vous ne considériez les structures d'interprétation internes comme une cible de compilation, auquel cas chaque langue est compilée.

— user253751

3

@immibis: chaque implémentation ECMAScript existante possède au moins un compilateur. La V8, par exemple, a deux compilateurs et des interpréteurs nuls, elle n'interprète jamais , elle compile toujours en code machine natif binaire. SpiderMonkey a quatre compilateurs, je crois, et un interprète, mais cet interprète n'interprète pas ECMAScript. SpiderMonkey n'interprète jamais ECMAScript, il le compile toujours d'abord en bytecode SpiderMonkey, qu'il peut ensuite compiler en code machine natif binaire. Toutes les implémentations Python, Ruby et PHP existantes ont des compilateurs.

— Jörg W Mittag

12

@LieRyan Vous êtes sérieusement désorienté si vous pensez que l'inférence de type est identique à celle typée dynamiquement et / ou que Haskell est typé dynamiquement.

— Derek Elkins

2

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:

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 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.

— bernie
source