Monolithique

En termes simples, une architecture monolithique est une architecture dans laquelle l'intégralité de la base de code, des fonctions et des algorithmes réside dans une seule unité ou un seul projet.

Bien que monolithique soit une approche légèrement plus traditionnelle dans le développement de logiciels, cela ne signifie pas qu'elle n'est plus utilisée. L'architecture monolithique serait toujours idéale pour les projets plus simples car ils sont plus faciles à construire et à déployer.

Avantages :

• Plus facile à développer et à déployer.
• Moins susceptibles de faire face à des problèmes de latence car la communication avec d'autres services est moindre.
• Les développeurs doivent se concentrer uniquement sur un composant.

• Le composant étroitement couplé rend difficile l'intégration de bonnes conceptions et principes logiciels. De plus, un petit changement pourrait effectivement faire tomber l'ensemble du composant.
• De petits changements nécessitent le déploiement de l'ensemble du composant, ce qui pourrait être contre-intuitif lorsqu'on essaie de réduire les coûts.
• Moins flexible pour adopter de nouvelles technologies en raison de la nature de l'architecture elle-même.

À l'autre bout de la ligne, nous avons des microservices. Les microservices sont essentiellement de petites unités d'opérations ou de services qui fonctionnent indépendamment mais ensemble pour former une plus grande part du gâteau. Bien qu'ils fournissent des services légers faiblement couplés, ils apportent un niveau de complexité à l'architecture. Des exemples de tels incluent la gestion des demandes/appels entre les services et la gestion des bases de données utilisées par chaque service.

Avantages

• Poids léger facilitant le ramassage, la gestion et le déploiement.
• Le couplage lâche signifie que même si un service tombe en panne, il n'affecte pas les autres services, à moins que le service qui s'est arrêté fasse partie d'un cas d'utilisation plus large nécessaire.
• Peut faire évoluer horizontalement une seule unité si elle fait face à une charge d'appels plus importante uniquement sur un service particulier.

• Le système distribué augmente la complexité car il y a plus de services.
• Coûteux car une plus grande utilisation du réseau est nécessaire pour maintenir la latence de la communication entre les différents composants.
• Le débogage d'un cas d'utilisation unique peut s'avérer difficile car le flux de travail traverse différents composants, ce qui rend plus difficile l'identification de la cause première des problèmes.

Il n'y a pas d'architecture unique qui serait utilisée dans tous les projets logiciels. En fin de compte, cela dépend de divers facteurs tels que le type de projet, la complexité du projet, les cas d'utilisation du projet et parfois même le budget.

Je suppose qu'une règle empirique est que si vous prévoyez que le projet sera plus simple avec des fonctions simples même à long terme, une approche monolithique serait idéale. Sinon, si vous prévoyez un besoin d'évoluer ou même d'adopter une nouvelle technologie, les microservices seraient la meilleure option.