Microservices vs architecture monolithique
J'ai lu des articles sur les microservices et je suis un peu intrigué. On dirait que c'est un concept intéressant. Mais je me demande quels sont les avantages et les inconvénients des microservices par rapport à l’architecture monolithique, et inversement.
Quand les microservices conviennent mieux et où aller avec l'architecture monolithique.
Bien que je sois relativement nouveau dans le monde des microservices, je vais essayer de répondre à votre question de manière aussi complète que possible.
Lorsque vous utilisez l'architecture microservices, le découplage et la séparation des préoccupations sont renforcés. Depuis que vous êtes en train de scinder votre demande.
Il en résulte que votre codebase sera plus facile à gérer (chaque application est indépendante des autres applications pour rester active). Par conséquent, si vous le faites bien, il sera il sera plus facile à l'avenir d'ajouter de nouvelles fonctionnalités à votre application. Tandis qu'avec une architecture monolithique, cela peut devenir une tâche très difficile si votre application est volumineuse (et vous pourrez en déduire qu’elle le sera à un moment donné).
De même le déploiement de l'application est plus facile, puisque vous créez les microservices indépendants séparément et les déployez sur des serveurs distincts. Cela signifie que vous pouvez créer et déployer des services quand vous le souhaitez sans avoir à reconstruire le reste de votre application.
Comme les différents services sont petits et déployés séparément, il est évident plus facile à faire évoluer eux, avec l’avantage de pouvoir mettre à l’échelle des services spécifiques de votre application (avec un monolithique, vous mettez à l’échelle la "chose" complète, même si c'est juste une partie spécifique de l'application qui reçoit une charge excessive).
Cependant, pour les applications qui ne sont pas destinées à devenir trop volumineuses pour être gérées à l'avenir. Il vaut mieux le garder à l'architecture monolithique. Depuis l'architecture de microservices a de sérieuses difficultés impliquées. J'ai déclaré qu'il est plus facile de déployer des microservices, mais cela n'est vrai qu'en comparaison avec les gros monolithes. Avec les microservices, vous avez la complexité supplémentaire de distribuer les services sur différents serveurs situés à différents endroits et vous devez trouver un moyen de gérer tout cela. La création de microservices vous aidera à long terme si votre application devient volumineuse, mais pour les applications plus petites, il est simplement plus facile de rester monolithique.
C'est une question très importante car quelques personnes sont attirées par tout le bourdonnement autour des microservices et il y a des compromis à prendre en compte. Alors, quels sont les avantages et les défis des microservices (par rapport au modèle monolithique)?
Avantages
- Déployabilité : plus de souplesse pour déployer les nouvelles versions d'un service grâce à des cycles de compilation + test + déploiement plus courts. En outre, possibilité d'utiliser des configurations de sécurité, de réplication, de persistance et de surveillance spécifiques à un service.
- Fiabilité : une défaillance de microservice affecte uniquement ce microservice et ses consommateurs, alors que dans le modèle monolithique, une défaillance de service peut entraîner la panne de l'ensemble du monolithe.
- Disponibilité : déployer une nouvelle version d'un microservice nécessite peu de temps d'arrêt, alors que déployer une nouvelle version d'un service dans le monolithe nécessite un redémarrage généralement plus lent de le monolithe entier.
- Évolutivité : chaque microservice peut être mis à l’échelle indépendamment à l’aide de pools, clusters, grilles. Les caractéristiques de déploiement font des microservices un complément idéal pour l’élasticité du cloud.
- Modifiabilité : plus de flexibilité pour utiliser de nouveaux frameworks, bibliothèques, sources de données et autres ressources. De plus, les microservices sont des composants modulaires faiblement couplés, uniquement accessibles via leurs contrats et donc moins susceptibles de se transformer en une grosse boule de boue.
- Gestion : l'application développement l'effort est divisé en équipes plus petites et plus indépendantes.
- Autonomie de conception : l'équipe est libre d'employer différents technologies, cadres et modèles pour concevoir et mettre en œuvre chaque microservice, et peut modifier et redéployer chaque microservice indépendamment
Défis
- Déployabilité : il existe beaucoup plus d'unités de déploiement. Il existe donc des tâches, des scripts, des zones de transfert et des fichiers de configuration plus complexes à superviser pour le déploiement. (Pour cette raison, la livraison continue et DevOps sont hautement souhaitables pour les projets de microservices.)
- Performance : il est plus probable que les services doivent communiquer sur le réseau, tandis que les services du monolithe peuvent bénéficier d'appels locaux. (Pour cette raison, la conception doit éviter les microservices "bavards".)
- Modifiable : les modifications du contrat sont plus susceptibles d’impacter les consommateurs déployés ailleurs, alors que dans le modèle monolithique, les consommateurs sont plus susceptibles de faire partie du monolithe et seront déployé en parallèle avec le service. En outre, des mécanismes destinés à améliorer l'autonomie, tels que la cohérence éventuelle et les appels asynchrones, ajoutent à la complexité des microservices.
- Testabilité : les tests d'intégration sont plus difficiles à configurer et à exécuter car ils peuvent couvrir différents microservices sur différents environnements d'exécution.
- Management : l'effort de gestion opérations augmente car il existe davantage de composants d'exécution, de fichiers journaux et de liens point à point. points d'interactions à surveiller.
- Utilisation de la mémoire : plusieurs classes et bibliothèques sont souvent répliquées dans chaque groupe de microservices et l’empreinte mémoire globale augmente.
- Autonomie d'exécution : dans le monolithe, la logique métier globale est co-localisée. Avec les microservices, la logique est répartie sur plusieurs microservices. Ainsi, toutes choses étant égales par ailleurs, il est plus probable qu'un microservice interagisse avec d'autres microservices sur le réseau - cette interaction diminue l'autonomie. Si l'interaction entre microservices implique la modification de données, la nécessité d'une limite transactionnelle compromet davantage l'autonomie. La bonne nouvelle est que pour éviter les problèmes d'autonomie d'exécution, nous pouvons utiliser des techniques telles que la cohérence éventuelle, l'architecture pilotée par les événements, le CQRS, le cache (réplication de données) et l'alignement des microservices avec les contextes liés à DDD. Ces techniques ne sont pas inhérentes aux microservices, elles ont été suggérées par pratiquement tous les auteurs que j'ai lus.
Une fois que nous avons compris ces compromis , il nous reste une dernière chose à savoir pour répondre à l’autre question: quel est le meilleur, microservices ou monolith? Nous devons connaître les exigences non fonctionnelles (exigences relatives aux attributs de qualité) de l'application. Une fois que vous avez compris l’importance des performances par rapport à l’évolutivité, par exemple, vous pouvez peser les compromis et prendre une décision de conception éclairée.
@Luxo est sur place. Je voudrais juste offrir une légère variation et en apporter une perspective organisationnelle. Les microservices permettent non seulement de découpler les applications, mais peuvent également aider au niveau organisationnel. L'organisation, par exemple, pourrait se diviser en plusieurs équipes, chacune pouvant développer un ensemble de microservices fournis par l'équipe.
Par exemple, dans les grands magasins comme Amazon, vous pouvez avoir une équipe de personnalisation, une équipe de commerce électronique, une équipe de services d'infrastructure, etc. Si vous souhaitez vous lancer dans les microservices, Amazon en est un très bon exemple. Jeff Bezos a confié aux équipes le mandat de communiquer avec les services d'une autre équipe si elles avaient besoin d'accéder à une fonctionnalité partagée. Voir ici pour une brève description.
En outre, les ingénieurs de Etsy et Netflix ont également eu un petit débat à la journée entre microservices et monolithe sur Twitter. Le débat est un peu moins technique, mais peut aussi apporter quelques idées.