Je voulais depuis longtemps écrire un article sur le thème de l'architecture des microservices, mais deux choses m'arrêtaient : plus je plongeais dans le sujet, plus il me semblait que ce que je sais est évident, et ce que je ne sais pas. Je ne sais pas, il faut étudier et étudier. D’un autre côté, je pense qu’il y a déjà de quoi discuter auprès d’un large public. Les avis alternatifs sont donc les bienvenus.
La loi de Conway et les relations entre entreprise, organisation et système d'information
Je me permettrai encore une fois de citer :
« Toute organisation qui conçoit un système (au sens large) recevra une conception dont la structure reproduit la structure des équipes de cette organisation. »
— Melvyn Conway, 1967
À mon avis, cette loi est plus susceptible de porter sur la faisabilité de l'organisation d'une entreprise que directement sur le système d'information. Laissez-moi vous expliquer avec un exemple. Disons que nous avons une opportunité commerciale assez stable avec un cycle de vie si long qu'il est logique d'organiser une entreprise (ce n'est pas une faute de frappe, mais j'aime beaucoup ce terme que j'ai volé). Naturellement, le système de support de cette entreprise correspondra organisationnellement et procéduralement à cette activité.
Orientation métier des systèmes d'information
Laissez-moi vous expliquer avec un exemple. Disons qu’il existe une opportunité commerciale de créer une entreprise de vente de pizza. Dans la version V1 (appelons-la pré-information), l'entreprise était une pizzeria, une caisse enregistreuse et un service de livraison. Cette version a vécu longtemps dans des conditions de faible variabilité environnementale. Puis la version 2 est venue la remplacer, plus avancée et capable d'utiliser en son cœur un système d'information métier avec une architecture monolithique. Et ici, à mon avis, il y a tout simplement une terrible injustice par rapport aux monolithes - l'architecture prétendument monolithique ne correspond pas au modèle économique du domaine. Oui, si tel était le cas, le système ne serait pas du tout capable de fonctionner - en contradiction avec la même loi de Conway et avec le bon sens. Non, l'architecture monolithique est tout à fait cohérente avec le modèle commercial à ce stade du développement commercial - je parle bien sûr du stade où le système a déjà été créé et mis en service. C’est un fait absolument merveilleux que quelle que soit l’approche architecturale, la version 3 de l’architecture orientée services et la version N de l’architecture microservices fonctionneront aussi bien. Quel est le piège?
Tout coule, tout change, ou les microservices sont-ils un moyen de lutter contre la complexité ?
Avant de continuer, examinons quelques idées fausses sur l'architecture des microservices.
Les partisans de l'utilisation d'une approche microservice soutiennent souvent que diviser un monolithe en microservices simplifie l'approche de développement en réduisant la base de code des services individuels. À mon avis, cette affirmation est complètement absurde. Sérieusement, l'interaction évidente au sein d'un code monolithique et homogène semble compliquée ? Si tel était vraiment le cas, tous les projets seraient initialement construits sous forme de microservices, alors que la pratique montre que la migration d'un monolithe vers des microservices est beaucoup plus courante. La complexité ne disparaît pas ; elle passe simplement des modules individuels aux interfaces (qu'il s'agisse de bus de données, de RPC, d'API et d'autres protocoles) et aux systèmes d'orchestration. Et c'est difficile !
L’avantage d’utiliser une pile hétérogène est également discutable. Je ne prétendrai pas que cela est également possible, mais en réalité cela se produit rarement (en regardant vers l'avenir - cela devrait arriver - mais plutôt comme une conséquence plutôt que comme un avantage).
Cycle de vie du produit et cycle de vie du service
Jetez un autre coup d’œil au diagramme ci-dessus. Ce n'est pas un hasard si j'ai noté le cycle de vie décroissant d'une version distincte d'une entreprise - dans les conditions modernes, c'est l'accélération de la transition d'une entreprise entre les versions qui est décisive pour son succès. Le succès d'un produit est déterminé par la rapidité avec laquelle les hypothèses commerciales sont testées.. Et c’est là, à mon avis, que réside le principal avantage de l’architecture des microservices. Mais allons-y dans l'ordre.
Passons à l'étape suivante de l'évolution des systèmes d'information : l'architecture orientée services de la SOA. Ainsi, à un moment donné, nous avons mis en évidence dans notre produit prestations de longue durée - de longue durée dans le sens où lors du passage d'une version à l'autre d'un produit, il est possible que le cycle de vie du service soit plus long que le cycle de vie de la prochaine version du produit. Il serait logique de ne pas les changer du tout - nous Ce qui compte c'est la rapidité de transition vers la prochaine version. Mais hélas, nous sommes obligés de modifier constamment les services - et ici tout fonctionne pour nous, les pratiques DevOps, la conteneurisation, etc. - tout ce qui nous vient à l'esprit. Mais ce ne sont toujours pas des microservices !
Les microservices comme moyen de lutter contre la complexité... la gestion des configurations
Et ici, nous pouvons enfin passer au rôle déterminant des microservices : il s'agit d'une approche qui simplifie la gestion de la configuration des produits. Plus en détail, la fonction de chaque microservice décrit exactement la fonction commerciale à l'intérieur du produit selon le modèle de domaine - et ce sont des choses qui ne vivent pas dans une version éphémère, mais dans une opportunité commerciale à long terme. Et la transition vers la prochaine version du produit se produit littéralement inaperçue - vous modifiez/ajoutez un microservice, et peut-être juste le schéma de leur interaction, et tout à coup vous vous retrouvez dans le futur, laissant derrière vous des concurrents en pleurs qui continuent de sauter entre les versions de leurs monolithes. Imaginez maintenant qu'il existe un volume assez important de microservices avec des interfaces et des capacités métier prédéfinies. Et vous venez construire la structure de votre produit à partir de microservices prêts à l'emploi - simplement en dessinant un schéma, par exemple. Félicitations, vous disposez d'une plateforme et vous pouvez désormais attirer des affaires par vous-même. Rêves Rêves.
résultats
- L'architecture du système doit être déterminée par le cycle de vie de ses composants. Si un composant réside dans une version de produit, cela ne sert à rien d’augmenter la complexité du système en utilisant une approche microservice.
- L'architecture des microservices doit être basée sur le modèle de domaine, car l'opportunité commerciale est le domaine qui a la plus longue durée de vie
- Les pratiques de livraison (pratiques DevOps) et l'orchestration sont parmi les plus importantes pour l'architecture des microservices - car l'augmentation du taux de changement des composants impose des exigences accrues en matière de rapidité et de qualité de livraison.
Source: habr.com