Avantages et inconvénients des microservices

Partie Ⅱ du chapitre trois La Structure de conteneur dans le domaine informatique

TL ; RD

• Avantages des microservices : déploiement indépendant, grande évolutivité, développement et maintenance simples.
• Inconvénients des microservices : tests et déploiement complexes, forte automatisation.

ML’architecture microservice fait référence à un style architectural qui préconise de diviser l’application monolithique en petits services coordonnés, pour fournir aux utilisateurs la valeur terminale. Chaque service exécute un processus spécialisé. Les services communiquent avec des mécanismes de communication légers (généralement une API reposante basée sur HTTP). Ils sont adaptés aux entreprises et publiés indépendamment à l’aide d’outils de déploiement automatisés. Un strict minimum de gestion centralisée gère l’architecture ; plusieurs langues écrivent les services ; des magasins de données distincts conservent les données.

Nouveau dans le commerce ? Essayez des bots de trading de crypto ou copiez le trading

Les microservices décomposent un monolithe en petits services à forte cohésion et faible couplage selon les domaines d’activité. Des processus uniques pour des services distincts sont développés et maintenus par des équipes indépendantes. Les services communiquent avec des mécanismes de communication légers, tels que l’API HTTP RESTful. Rédigés en plusieurs langues, ils sont déployés indépendamment et automatiquement et stockés séparément. Les microservices manifestent une nature décentralisée et distribuée. Saluée comme le cadre technique de la plate-forme intermédiaire à intégrer dans les systèmes informatiques, l’architecture aide à la croissance et à l’innovation rapides des entreprises, s’adaptant à une faible flexibilité et évolutivité, à une itération rapide et à des innovations techniques.

Points forts de l’architecture de microservices

un. Facile à développer et à maintenir : les services sont relativement petits et faciles à comprendre.

b. Déploiement indépendant : la modification d’un service ne nécessite pas la coordination des autres.

c. Évolutivité élevée : chaque service évolue indépendamment les uns des autres en fonction des ressources matérielles.

ré. Adéquation avec la structure organisationnelle : l’architecture s’accorde mieux avec la structure de l’équipe ; les équipes cloisonnées se concentrent sur leurs propres priorités pour une meilleure productivité.

e. Hétérogénéité technologique : détermine la technologie la plus souhaitable pour chaque service ; coûts de garnitures pour un nouvel essai technologique.

F. Exigences distinctes de l’entreprise : l’équilibre entre la décentralisation et le contrôle ou la gouvernance centralisée ; le compromis entre la base de données distribuée et le modèle de données en boucle fermée d’entreprise.

Inconvénients de l’architecture de microservice

un. Les microservices ont toutes les complexités associées du système distribué. Il faut choisir entre les mécanismes de communication inter-processus basés sur le passage de messages ou RPC. Des codes sont écrits pour les défauts et les erreurs de l’informatique distribuée sont médités.

b. Des bases de données séparées sont créées. Les transactions doivent mettre à jour les données détenues par plusieurs services. Les défis s’intensifient pour les développeurs.

c. Les tests sont plus complexes que le monolithe. Des tests similaires forcent le service lui-même ainsi que ses dépendances à démarrer (ou au moins configurent des stubs pour eux).

ré. Les changements interservices rencontrent des obstacles croissants. Même une modification mineure nécessite des plans et une coordination bien entretenus.

e. Le déploiement se déroule en plusieurs étapes. Une application de microservice se compose généralement de nombreux services, chacun ayant plusieurs instances d’exécution. Chaque instance passe par la configuration, le déploiement, la mise à l’échelle et la surveillance, où le déploiement s’effectue dans un environnement hautement automatisé.

Les faits saillants et les revers pour le monolithe et les microservices ne sont pas absolus car la scène ou la demande peut changer. La préférence pour les petits services et la granularité est en corrélation avec l’expérience ainsi qu’avec la situation réelle.

L’image ci-dessus est tirée d’un article intitulé Microservice Premium par Martin Fowler, révélant la relation entre productivité et complexité. À faible complexité, le monolithe génère une productivité plus élevée. À mesure que la complexité entre en jeu, la productivité commence à chuter fortement. A cette époque, seul le découplage des microservices sauve la courbe décroissante.

Les organisations qui conçoivent des systèmes sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations – Melvyn Conway, 1967

Des mots simples ne rendront pas justice à la loi de Conway, qui est condensée en quatre :

La première loi : la communication dicte le design

La deuxième loi : Il n’y a jamais assez de temps pour faire quelque chose de bien, mais il y a toujours assez de temps pour le refaire.

La troisième loi : Il existe un homomorphisme du graphe linéaire d’un système au graphe linéaire de son organisation de conception.

La quatrième loi : les structures des grands systèmes ont tendance à se désagréger au cours du développement, qualitativement plus qu’avec les petits systèmes.

La loi est saluée comme la 1ère loi pour la conception d’architecture logicielle, un recueil de lois dans le monde des affaires. La loi de Conway a fait l’objet d’une publication informatique majeure, puis a été citée par le Homme-mois mythique, la bible dans le domaine informatique. Par conséquent, la loi a d’abord reçu son nom et est devenue virale depuis lors.

*NetX vise à construire l’organisme Web 3. Nous essayons de trouver des solutions confrontées à l’industrie informatique actuelle. Pour ce faire, nous examinerons chaque module de celui-ci pour découvrir les revers. Ensuite, nous nous concentrerons sur la recherche de solutions par le biais d’expériences. C’est un processus évolutif dynamique. Pour obtenir la meilleure solution, nous devons être clairs sur les problèmes et ce sera l’idée principale du chapitre trois. Cela me donne envie de partager mes réflexions et je vous invite à me rejoindre dans cette exploration et à contribuer à l’évolution de NetX.

Série NetX 1.1 | Série NetX 1.2 | Série NetX 1.3 | Série NetX 2.1 | Série NetX 2.2 | Série NetX 2.3 | NetX série 3.1