{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Microservices : qu'est-ce que c'est, pourquoi et quand les adopter","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

J'ai voulu \u00e9crire un article sur l'architecture des microservices depuis longtemps, mais deux \u00e9l\u00e9ments m'ont constamment frein\u00e9 : au fur et \u00e0 mesure que je me plongeais dans le sujet, j'avais de plus en plus l'impression que ce que je savais \u00e9tait \u00e9vident, et que ce que je ne savais pas n\u00e9cessitait encore beaucoup d'\u00e9tude. D'un autre c\u00f4t\u00e9, je pense qu'il y a d\u00e9j\u00e0 mati\u00e8re \u00e0 r\u00e9flexion pour un large public. Donc, les avis alternatifs sont les bienvenus.
\n<\/a><\/noindex><\/p>\n

La loi de Conway et le lien entre le business, l'organisation et le syst\u00e8me d'information<\/h2>\n

\nJe me permets une nouvelle fois de citer :<\/p>\n

\u00ab Toute organisation qui con\u00e7oit un syst\u00e8me (au sens large) obtiendra un design dont la structure copie celle des \u00e9quipes au sein de cette organisation. \u00bb
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

\u00c0 mon avis, cette loi se rapporte davantage \u00e0 la rationalit\u00e9 de l'organisation des affaires, plut\u00f4t qu'\u00e0 un lien direct avec le syst\u00e8me d'information. Je vais l'expliquer par un exemple. Supposons que nous avons une opportunit\u00e9 commerciale assez stable, avec un cycle de vie suffisamment long pour justifier la cr\u00e9ation d'une entreprise (ce n'est pas une faute de frappe, mais j'aime beaucoup ce terme que j'ai emprunt\u00e9). Naturellement, le syst\u00e8me qui soutient ce business sera organis\u00e9 et proc\u00e9duralement en ad\u00e9quation avec celui-ci.<\/p>\n

L'orientation business des syst\u00e8mes d'information<\/h2>\n

\n\"Microservices
\n
\nJe vais l'expliquer par un exemple. Imaginons une opportunit\u00e9 commerciale pour organiser une entreprise de vente de pizzas. Dans la version V1 (appelons-la pr\u00e9information), l'entreprise se composait d'une pizzeria, d'une caisse et d'un service de livraison. Cette version a eu une longue dur\u00e9e de vie dans des conditions de faible variabilit\u00e9 de l'environnement. Puis est venue la version 2 \u2014 plus avanc\u00e9e et capable d'utiliser un syst\u00e8me d'information comme base pour un business avec une architecture monolithique. Et l\u00e0, \u00e0 mon avis, appara\u00eet une v\u00e9ritable injustice envers les monolithes \u2014 soi-disant, l'architecture monolithique ne correspond pas au mod\u00e8le de domaine d'une entreprise.<\/b>Si cela en \u00e9tait ainsi, le syst\u00e8me ne pourrait pas fonctionner du tout - en contradiction avec la m\u00eame loi de Conway et le bon sens. Non, l'architecture monolithique correspond enti\u00e8rement au mod\u00e8le commercial \u00e0 ce stade de d\u00e9veloppement de l'entreprise - je fais bien s\u00fbr r\u00e9f\u00e9rence \u00e0 la phase o\u00f9 le syst\u00e8me est d\u00e9j\u00e0 construit et op\u00e9rationnel. Un fait tout \u00e0 fait remarquable est que, quelle que soit l'approche architecturale, \u00e0 la fois l'architecture orient\u00e9e services de la version 3 et l'architecture microservices de la version N fonctionneront aussi bien l'une que l'autre. Quel est le pi\u00e8ge ?<\/p>\n

Tout est en flux, tout change ou les microservices - un moyen de lutter contre la complexit\u00e9 ?<\/h2>\n

\n Avant de continuer, examinons certaines id\u00e9es re\u00e7ues concernant l'architecture microservices.<\/p>\n

Les partisans de l'approche microservices affirment souvent que d\u00e9composer un monolithe en microservices simplifie le d\u00e9veloppement gr\u00e2ce \u00e0 la r\u00e9duction de la base de code des services individuels. \u00c0 mon avis, cette affirmation est compl\u00e8tement absurde. S\u00e9rieusement, l'interaction \u00e9vidente au sein d'un monolithe et d'un code homog\u00e8ne semble-t-elle complexe ? Si c'\u00e9tait vraiment le cas, tous les projets seraient initialement construits en tant que microservices, alors que la pratique montre que la migration d'un monolithe vers des microservices est de loin plus courante. La complexit\u00e9 ne dispara\u00eet pas, elle se d\u00e9place simplement de modules individuels vers des interfaces (qu'il s'agisse de bus de donn\u00e9es, de RPC, d'API ou d'autres protocoles) et des syst\u00e8mes d'orchestration. Et cela, c'est compliqu\u00e9 ! <\/p>\n

L'avantage d'utiliser une pile h\u00e9t\u00e9rog\u00e8ne est \u00e9galement douteux. Je ne conteste pas que cela soit possible, mais en r\u00e9alit\u00e9, c'est rarement le cas (En avance - cela devrait effectivement exister - mais plut\u00f4t comme une cons\u00e9quence, plut\u00f4t qu'un avantage).<\/p>\n

Le cycle de vie d'un produit et le cycle de vie d'un service<\/h2>\n

\nRegardez \u00e0 nouveau le diagramme ci-dessus. Je n'ai pas inscrit par hasard le cycle de vie r\u00e9duisant d'une version d'entreprise - dans les conditions modernes, l'acc\u00e9l\u00e9ration de la transition d'une entreprise entre les versions est d\u00e9terminante pour son succ\u00e8s. Le succ\u00e8s d'un produit est d\u00e9fini par la rapidit\u00e9 de validation des hypoth\u00e8ses commerciales en son sein<\/b>. Et c'est ici que, selon moi, se trouve l'avantage cl\u00e9 de l'architecture microservices. Mais avan\u00e7ons \u00e9tape par \u00e9tape. <\/p>\n

Passons \u00e0 la prochaine \u00e9tape de l'\u00e9volution des syst\u00e8mes d'information : l'architecture orient\u00e9e services SOA. Alors, \u00e0 un moment donn\u00e9, nous avons isol\u00e9 dans notre produit des services durables<\/b> \u2014 durables dans le sens o\u00f9 lors des transitions entre les versions du produit, il y a une chance que le cycle de vie du service soit plus long que le cycle de vie de la version du produit. Il serait logique de ne pas les modifier du tout \u2014 ce qui nous importe vraiment, c'est la rapidit\u00e9 de passage \u00e0 la version suivante<\/b>. Mais h\u00e9las, nous sommes contraints d'apporter des modifications constantes aux services \u2014 et ici tout est bon, et les pratiques DevOps, et la conteneurisation, et tout ce qui vient \u00e0 l'esprit. Mais ce ne sont toujours pas des microservices ! <\/p>\n

Les microservices comme moyen de lutte contre la complexit\u00e9\u2026 la gestion de la configuration<\/h2>\n

\n Et c'est ici que nous pouvons enfin aborder le r\u00f4le d\u00e9terminant des microservices \u2014 c'est une approche qui simplifie la gestion de la configuration du produit. En d'autres termes, la fonction de chaque microservice d\u00e9crit pr\u00e9cis\u00e9ment une fonction m\u00e9tier au sein du produit selon le mod\u00e8le de domaine \u2014 et ce sont des \u00e9l\u00e9ments qui ne vivent pas dans une version \u00e9ph\u00e9m\u00e8re, mais dans une opportunit\u00e9 commerciale durable. Et le passage \u00e0 la version suivante du produit se fait litt\u00e9ralement de mani\u00e8re imperceptible \u2014 vous modifiez\/ajoutez un microservice, ou peut-\u00eatre simplement le sch\u00e9ma de leur interaction, et vous vous retrouvez soudainement dans le futur, laissant derri\u00e8re vous des concurrents en larmes qui continuent \u00e0 sauter entre les versions de leurs monolithes. Maintenant, imaginez qu'il existe un volume suffisant de microservices avec des interfaces et des opportunit\u00e9s commerciales pr\u00e9d\u00e9finies. Et vous arrivez et construisez la structure de votre produit \u00e0 partir de microservices pr\u00eats \u00e0 l'emploi \u2014 en dessinant simplement un diagramme, par exemple. F\u00e9licitations \u2014 vous avez une plateforme \u2014 et maintenant vous pouvez b\u00e2tir votre entreprise. Des r\u00eaves, des r\u00eaves. <\/p>\n

Conclusions<\/h2>\n

<\/p>\n