J'ai voulu écrire un article sur l'architecture des microservices depuis longtemps, mais deux éléments m'ont constamment freiné : au fur et à mesure que je me plongeais dans le sujet, j'avais de plus en plus l'impression que ce que je savais était évident, et que ce que je ne savais pas nécessitait encore beaucoup d'étude. D'un autre côté, je pense qu'il y a déjà matière à réflexion pour un large public. Donc, les avis alternatifs sont les bienvenus.
La loi de Conway et le lien entre le business, l'organisation et le système d'information
Je me permets une nouvelle fois de citer :
« Toute organisation qui conçoit un système (au sens large) obtiendra un design dont la structure copie celle des équipes au sein de cette organisation. »
— Melvyn Conway, 1967
À mon avis, cette loi se rapporte davantage à la rationalité de l'organisation des affaires, plutôt qu'à un lien direct avec le système d'information. Je vais l'expliquer par un exemple. Supposons que nous avons une opportunité commerciale assez stable, avec un cycle de vie suffisamment long pour justifier la création d'une entreprise (ce n'est pas une faute de frappe, mais j'aime beaucoup ce terme que j'ai emprunté). Naturellement, le système qui soutient ce business sera organisé et procéduralement en adéquation avec celui-ci.
L'orientation business des systèmes d'information
Je vais l'expliquer par un exemple. Imaginons une opportunité commerciale pour organiser une entreprise de vente de pizzas. Dans la version V1 (appelons-la préinformation), l'entreprise se composait d'une pizzeria, d'une caisse et d'un service de livraison. Cette version a eu une longue durée de vie dans des conditions de faible variabilité de l'environnement. Puis est venue la version 2 — plus avancée et capable d'utiliser un système d'information comme base pour un business avec une architecture monolithique. Et là, à mon avis, apparaît une véritable injustice envers les monolithes — soi-disant, l'architecture monolithique ne correspond pas au modèle de domaine d'une entreprise.Si cela en était ainsi, le système ne pourrait pas fonctionner du tout - en contradiction avec la même loi de Conway et le bon sens. Non, l'architecture monolithique correspond entièrement au modèle commercial à ce stade de développement de l'entreprise - je fais bien sûr référence à la phase où le système est déjà construit et opérationnel. Un fait tout à fait remarquable est que, quelle que soit l'approche architecturale, à la fois l'architecture orientée 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ège ?
Tout est en flux, tout change ou les microservices - un moyen de lutter contre la complexité ?
Avant de continuer, examinons certaines idées reçues concernant l'architecture microservices.
Les partisans de l'approche microservices affirment souvent que décomposer un monolithe en microservices simplifie le développement grâce à la réduction de la base de code des services individuels. À mon avis, cette affirmation est complètement absurde. Sérieusement, l'interaction évidente au sein d'un monolithe et d'un code homogène semble-t-elle complexe ? Si c'était 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é ne disparaît pas, elle se déplace simplement de modules individuels vers des interfaces (qu'il s'agisse de bus de données, de RPC, d'API ou d'autres protocoles) et des systèmes d'orchestration. Et cela, c'est compliqué !
L'avantage d'utiliser une pile hétérogène est également douteux. Je ne conteste pas que cela soit possible, mais en réalité, c'est rarement le cas (En avance - cela devrait effectivement exister - mais plutôt comme une conséquence, plutôt qu'un avantage).
Le cycle de vie d'un produit et le cycle de vie d'un service
Regardez à nouveau le diagramme ci-dessus. Je n'ai pas inscrit par hasard le cycle de vie réduisant d'une version d'entreprise - dans les conditions modernes, l'accélération de la transition d'une entreprise entre les versions est déterminante pour son succès. Le succès d'un produit est défini par la rapidité de validation des hypothèses commerciales en son sein. Et c'est ici que, selon moi, se trouve l'avantage clé de l'architecture microservices. Mais avançons étape par étape.
Passons à la prochaine étape de l'évolution des systèmes d'information : l'architecture orientée services SOA. Alors, à un moment donné, nous avons isolé dans notre produit des services durables — durables dans le sens où 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 — ce qui nous importe vraiment, c'est la rapidité de passage à la version suivante. Mais hélas, nous sommes contraints d'apporter des modifications constantes aux services — et ici tout est bon, et les pratiques DevOps, et la conteneurisation, et tout ce qui vient à l'esprit. Mais ce ne sont toujours pas des microservices !
Les microservices comme moyen de lutte contre la complexité… la gestion de la configuration
Et c'est ici que nous pouvons enfin aborder le rôle déterminant des microservices — c'est une approche qui simplifie la gestion de la configuration du produit. En d'autres termes, la fonction de chaque microservice décrit précisément une fonction métier au sein du produit selon le modèle de domaine — et ce sont des éléments qui ne vivent pas dans une version éphémère, mais dans une opportunité commerciale durable. Et le passage à la version suivante du produit se fait littéralement de manière imperceptible — vous modifiez/ajoutez un microservice, ou peut-être simplement le schéma de leur interaction, et vous vous retrouvez soudainement dans le futur, laissant derrière vous des concurrents en larmes qui continuent à sauter entre les versions de leurs monolithes. Maintenant, imaginez qu'il existe un volume suffisant de microservices avec des interfaces et des opportunités commerciales prédéfinies. Et vous arrivez et construisez la structure de votre produit à partir de microservices prêts à l'emploi — en dessinant simplement un diagramme, par exemple. Félicitations — vous avez une plateforme — et maintenant vous pouvez bâtir votre entreprise. Des rêves, des rêves.
Conclusions
- L'architecture du système doit être déterminée par le cycle de vie des composants qui y entrent. Si un composant vit dans le cadre de la version du produit — il n'est pas utile d'augmenter la complexité du système en appliquant une approche microservice.
- L'architecture microservice doit être fondée sur le modèle de domaine — pour la raison que l'opportunité commerciale est le domaine le plus durable.
- Les pratiques de livraison (pratiques DevOps) et l'orchestration ont une importance primordiale pour l'architecture des microservices, car l'augmentation de la rapidité de changement des composants impose des exigences accrues en matière de rapidité et de qualité de livraison.
Source : habr.com
