👨‍🏫 😡 ↕️ Microservices: qu'est-ce que c'est, pourquoi et quand devez-vous les implémenter 📊 💂 👩🏻

Je voulais écrire un article sur le sujet de l'architecture des microservices pendant longtemps, mais deux points s'arrêtaient tout le temps - plus j'avançais dans le sujet, plus il me semblait que ce que je sais était évident, et que je ne savais pas, je devais encore étudier et étudier. D'un autre côté, je pense qu'il y a déjà de quoi spéculer sur un large public. Les opinions alternatives sont donc les bienvenues.

Conway Law et la relation entre l'entreprise, l'organisation et le système d'information

Encore une fois, je me permets de citer:

«Toute organisation qui conçoit un système (au sens large) recevra une conception dont la structure copie la structure des équipes de cette organisation»
- Melvyn Conway, 1967

À mon avis, cette loi est plus probablement liée à l'opportunité d'organiser une entreprise, plutôt que directement au système d'information. Je vais vous expliquer avec un exemple. Supposons que nous ayons une opportunité commerciale suffisamment stable avec un cycle de vie d'une durée telle qu'il est logique d'organiser une entreprise (ce n'est pas une faute de frappe, mais j'aime vraiment le terme que j'ai retiré) Naturellement, le système de soutien de cette entreprise sera organisationnel et processus cohérent avec cette entreprise .

Systèmes d'information d'orientation commerciale

Je vais vous expliquer avec un exemple. Supposons qu'il existe une opportunité commerciale d'organiser une entreprise de pizza. Dans la version V1 (appelons-la pré-informative), l'entreprise était une pizzeria, une caisse, un service de livraison. Cette version a vécu longtemps dans des conditions de faible variabilité du monde environnant. Puis vint la version 2, plus avancée et capable d'utiliser le système d'information comme base pour une entreprise à l'architecture monolithique. Et ici, à mon avis, il y a simplement une terrible injustice en ce qui concerne les monolithes - l' architecture soi - disant monolithique ne correspond pas au modèle commercial du domaine. Oui, s'il en était ainsi, le système n'aurait pas pu fonctionner du tout, contrairement à la même loi de Conway et au bon sens. Non, l'architecture monolithique est pleinement compatible avec le modèle commercial à ce stade du développement commercial - bien sûr, je veux dire le stade où le système est déjà créé et mis en service. C'est un fait absolument remarquable que, quelle que soit l'approche architecturale, l'architecture orientée services de la version 3 et l'architecture de microservices de la version N fonctionneront également bien. Quel est le piège?

Tout coule-t-il, tout change-t-il ou les microservices sont-ils un moyen de gérer la complexité?

Avant de continuer, nous examinerons certaines idées fausses concernant l'architecture de microservice.

Les partisans de l'approche microservice disent souvent que la division d'un monolithe en microservices simplifie l'approche de développement en réduisant la base de code des services individuels. À mon avis, cette déclaration est totalement absurde. Sérieusement, l'interaction évidente au sein d'un monolithe et d'un code homogène semble-t-elle compliquée? Si cela était vrai, tous les projets seraient initialement construits en tant que microservices, tandis que la pratique montre que la migration d'un monolithe vers les microservices est beaucoup plus courante. La complexité ne disparaît nulle part, 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 de systèmes d'orchestration. Et c'est dur!

L'avantage d'utiliser une pile hétérogène est également douteux. Je ne dirai pas que cela est également possible, mais se produit rarement dans la réalité (regarder vers l'avenir - cela devrait être le lieu d'être - mais plutôt comme une conséquence plutôt qu'un avantage).

Cycle de vie du produit et cycle de vie du service

Jetez un autre coup d'œil au tableau ci-dessus. Ce n'est pas par hasard que j'ai constaté la diminution du cycle de vie 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 cruciale pour son succès. Le succès d'un produit est déterminé par la vitesse à laquelle il teste ses hypothèses commerciales . Et ici, à mon avis, l'avantage clé de l'architecture de microservices est enterré. Mais allons-y dans l'ordre.

Passons à l'étape suivante de l'évolution des systèmes d'information - vers une architecture SOA orientée services. Donc, à un moment précis, nous avons mis en évidence des services de longue durée dans notre produit- longue durée de vie dans le sens où lors du passage d'une version de produit à l'autre, 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 - la vitesse de transition vers la prochaine version est importante pour nous . Mais hélas, nous sommes obligés d'apporter des changements constants aux services - et ici tout nous convient, et les pratiques DevOps, et la conteneurisation, etc. - tout ce qui nous vient à l'esprit. Mais ce ne sont toujours pas des microservices!

Les microservices comme outil de lutte contre la complexité ... gestion de la configuration

Et ici, nous pouvons enfin passer au rôle déterminant des microservices - c'est une approche qui simplifie la gestion de la configuration des produits. Plus précisément, 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 de courte durée, mais dans une opportunité commerciale de longue durée. Et la transition vers la prochaine version du produit est littéralement imperceptible - vous changez / ajoutez un microservice, et peut-être juste le schéma de leur interaction et vous vous retrouvez soudainement dans le futur, laissant des concurrents pleurer 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 opportunités commerciales prédéfinies.Et vous venez construire la structure de votre produit à partir de microservices prêts à l'emploi - rien qu'en dessinant un diagramme par exemple. Félicitations - vous avez une plate-forme - et vous pouvez maintenant créer votre propre entreprise. Dreams Dreams.

résultats

L'architecture du système doit être déterminée par le cycle de vie de ses composants. Si un composant vit dans la version du produit, il est inutile d'augmenter la complexité du système en utilisant une approche de microservice.
L'architecture de microservice doit être basée sur un modèle de domaine - car l'opportunité commerciale est le domaine le plus pérenne
Les pratiques de livraison (pratiques DevOps) et l'orchestration ont l'une des valeurs les plus importantes pour l'architecture de microservices - parce que l'augmentation du taux de changement des composants impose des exigences accrues sur la vitesse et la qualité de la livraison