Mise à l'échelle des monolithes et mise à l'échelle des microservices

L'un des arguments les plus courants pour utiliser les microservices est une meilleure évolutivité. Mais je me demande si cet argument est vraiment valable.

Disons que nous avions une application composée de 10 microservices dont 9 ont chacun deux instances (pour la redondance) et l'une d'entre elles avec 4 instances pour gérer la charge (évolutivité). L'argument pro-microservice est alors que vous pouvez faire évoluer ce miroservice indépendamment des autres services.

Cependant, disons que les 10 microservices étaient des modules dans un seul monolithe et que plusieurs instances (par exemple 22 comme la somme ci-dessus) de ce monolithe ont été déployées. Le système doit être capable de gérer la charge pour la seule pièce critique, car il y a suffisamment d'instances pour le faire. Si les instances contiennent une logique de programme non nécessaire, le seul inconvénient serait que le binaire et la quantité de RAM nécessaire seraient légèrement plus grands. Mais là encore, la différence ne devrait pas être trop grande dans la plupart des cas - du moins pas par rapport au reste de la pile (pensez à Spring Boot). L'avantage d'un monlith à l'échelle serait un système plus simple sans (la plupart) des erreurs d'un système distribué.

Suis-je en train de manquer quelque chose?

microservices

— démon
source

De quelle taille d'un monolithe parlez-vous? Parce que je pense que cela pourrait être plus qu'une quantité "légèrement plus grande" de RAM. Sans parler du temps de déploiement - la correction d'un bogue peut prendre 22 déploiements au lieu de 4. Mais peut-être que votre monolithe est petit et que les déploiements ne prennent pas beaucoup de temps, les migrations de base de données ne prennent pas beaucoup de temps, etc.

— Thomas Owens

Je n'ai pas compté de lignes de code, mais le monolithe aurait plusieurs milliers de lignes de code (pas un système géant). Le point de départ de ma considération était que la taille du code d'application réel est minuscule par rapport aux grands frameworks comme Spring et Hibernate. Le nombre de déploiements pourrait en fait être inférieur à celui des microservices, car si vous aviez 2 instances, vous auriez déjà une redondance de base et plus d'instances seraient pour l'évolutivité.

— Deamon

@deamon Sachez qu'avec l'approche monolithique, aucune partie du code n'est totalement morte sur chaque instance, juste du code rarement utilisé. Maintenant, le code lui-même ne peut consommer qu'une petite quantité de mémoire, mais s'il utilise beaucoup d'objets taillés en mémoire, cette quantité peut augmenter considérablement.

— Frank Hopkins

Notez que le surcoût de base "obtenir le code d'exécution" n'est pas nécessairement aussi important que vous le savez peut-être à partir de vos applications Java où souvent tout le jvm fait partie de l'image du service.

— Frank Hopkins

Réponses:

Le but des microservices n'est pas de réduire la charge du processeur. En fait, en raison de la surcharge de communication et de la répétition de fonctions qui étaient auparavant du code utilitaire global, cela augmente généralement quelque peu la charge du processeur.

Le point d'abolir un monolithe est beaucoup plus pour être en mesure de maintenir, déployer et exécuter un système complexe de fonctionnalité du tout . Une fois que votre système atteint une certaine taille, la compilation, les tests, le déploiement, etc., un monolithe devient tout simplement trop cher pour être réalisable tout en maintenant une disponibilité décente. Avec les microservices, vous pouvez mettre à niveau, redémarrer ou restaurer un système au coup par coup.

Ne vous y trompez pas, nous n'écrivons pas de microservices car c'est intrinsèquement une meilleure solution pour coupler les choses de manière lâche sur des interfaces distantes. En fait, la perte de type fort et de cohérence vérifiant qu'un monolithe pourrait fournir est souvent un inconvénient majeur. Nous le faisons parce que nous devons le faire parce que la complexité a pris le dessus sur nous et tire le meilleur parti d'une situation sous-optimale.

— Kilian Foth
source

D'accord. La raison de passer à une architecture de microservices est principalement politique. La charge répartie, le découplage sont des conséquences et non des causes. Le véritable avantage des microservices est au SDLC et à la Gouvernance. De plus, l'architecture est la réponse logique à un besoin qui, dans la plupart des cas, provient de la stratégie de marché de l'entreprise. Le délai de mise sur le marché est plus court que les architectures monolithiques, de sorte que la société est autorisée à adopter de nouvelles stratégies, à passer de l'une à l'autre en douceur et rapidement

— Laiv

C'est pourquoi il ne faut pas non plus aller directement aux microservices pour les applications moyennes et petites. Les frais généraux et la complexité accrue du système peuvent très bien finir par coûter plus de temps, d'argent et de qualité qu'un système monolithique, à ces échelles.

— T. Sar

«Nous le faisons parce que nous devons le faire parce que la complexité a pris le dessus sur nous et tire le meilleur parti d'une situation sous-optimale.« Oui. Pour moi, ça cloue!

— Thomas Junk

Je dois être en désaccord avec la dernière partie de la réponse. les micro-services sont intrinsèquement meilleurs qu'un monolithe, car ils utilisent plus d'un ordinateur

— Ewan

@ewan Vous pouvez également utiliser plusieurs ordinateurs avec des monolithes.

— Deamon

Vous avez surtout raison. Si vous avez des services rapides qui sont également chargés, vous pouvez tout aussi bien les installer sur toutes les boîtes. Ce n'est pas aussi «agréable» que d'avoir une boîte par service, mais cela permet d'économiser de l'argent.

Pourtant. dès que vous avez un déséquilibre, disons que le service 5 prend 100% du processeur pendant 2 min, vous voulez déplacer ce service dans sa propre boîte afin qu'il ne bloque pas tous les autres services s'il s'exécute.

Si les appels au service 5 expirent en raison de la charge, seules certaines fonctions de votre application échoueront au lieu de toutes.

Maintenant, vous pouvez faire la même chose avec un monolithe bien modularisé. Installez tous les services, mais acheminez uniquement le trafic du service 5 vers l'un d'eux. Sans acheminer le trafic du service 5 vers les autres boîtes.

Mais généralement, les monolithes, de par leur nature même, ne sont pas une collection lâche de services qui se trouvent être installés sur la même boîte. Il y aura des appels en mémoire entre les modules qui entraîneront l'échec de l'application.

— Ewan
source

Les micro-services ont pour but 1) la séparation des préoccupations et 2) la répartition de la charge. Essentiellement, cela nous libère pour offrir le meilleur service de boîte noire possible avec des technologies spécifiques à cette tâche. Nos services peuvent être polyglottes - c'est-à-dire écrits dans différents langages de programmation sur différentes piles. Différentes équipes peuvent travailler sur chaque service sans savoir comment les autres fonctionnent au-delà du contrat de leur API. Ceci, pris dans son ensemble, permet une base de code beaucoup plus simple pour chaque service qui est plus facile à déboguer, à comprendre et à ajuster pour les performances.

— Vendeurs de Lewis A
source

Je suis d'accord en partie. Mon point n'était pas sur les arguments pour les microservices en général, mais sur l'évolutivité. Dans mon cas spécifique, les microservices sont tous écrits dans la même technologie, par exemple. Ainsi, alors qu'il serait possible d'utiliser une technologie différente pour chacun, ce n'est tout simplement pas le cas ici. Je voulais vérifier que je ne manque pas un point important sur l'évolutivité.

— Deamon