Bonjour, Habr. En ce moment, OTUS ouvre les inscriptions pour un nouveau groupe de cours. . À l'approche du début du cours, je souhaite partager avec vous mon article d'auteur.
Introduction
Le choix d'un style architectural est l'une des décisions techniques fondamentales lors de la création d'un système d'information. Dans cette série d'articles, je propose d'examiner les styles architecturaux les plus populaires pour la construction d'applications et de répondre à la question de savoir quand un style architectural particulier est le plus approprié. Au fil de cette exposition, j'essaierai de créer un fil logique expliquant l'évolution des styles architecturaux, des monolithes aux microservices.
Un peu d'histoire
Si vous essayez de poser la question aux développeurs : « À quoi servent les microservices ? », vous obtiendrez les réponses les plus variées. Vous entendrez que les microservices améliorent la scalabilité, simplifient la compréhension du code, améliorent la résilience, et parfois, vous entendrez qu'ils permettent de « nettoyer le code ». Retournons à l'histoire pour comprendre quel but a conduit à l'apparition des microservices.
En résumé, les microservices tels que nous les comprenons actuellement sont apparus de la manière suivante : en 2011, James Lewis, en analysant les travaux de diverses entreprises, a remarqué l'émergence d'un nouveau modèle appelé « micro-app », qui optimisait le SOA en termes d'accélération du déploiement des services. Peu après, en 2012, lors du sommet architectural, ce modèle a été renommé en microservice. Ainsi, l'objectif initial de l'implémentation des microservices était d'améliorer le fameux time to market.
Les microservices étaient à la mode en 2015. D'après certaines études, aucune conférence ne se passait sans une présentation sur le thème des microservices. De plus, certaines conférences étaient exclusivement consacrées aux microservices. À présent, de nombreux projets commencent avec ce style architectural, et si un projet contient des tonnes de code hérité, il y a sûrement une migration active vers les microservices.
Malgré tout ce qui précède, un nombre encore relativement faible de développeurs peut définir le terme « microservice ». Mais nous en parlerons un peu plus tard...
Monolithe
Le style architectural qui est opposé aux microservices est le monolithe (ou « tout en un »). Parler du monolithe n'a probablement pas de sens, donc je vais tout de suite énumérer les inconvénients de ce style architectural, qui ont suscité un développement ultérieur des styles architecturaux : taille, couplage, déploiement, évolutivité, fiabilité et rigidité. Ci-dessous, je vous propose de découvrir chacun des inconvénients séparément.
Taille
Le monolithe est très grand. Il communique généralement avec une très grande base de données. L'application devient trop complexe pour qu'un seul développeur puisse la comprendre. Seules les personnes ayant passé beaucoup de temps avec ce code peuvent travailler efficacement sur le monolithe, tandis que les nouveaux développeurs passeront énormément de temps à essayer de le comprendre, sans garantie de succès. En général, il y a toujours un certain senior « conditionnel » qui connaît le monolithe relativement bien et qui corrige les erreurs des nouveaux développeurs pendant un an ou un an et demi. Naturellement, ce senior conditionnel constitue un point de défaillance unique, et son départ peut mener à la perte du monolithe.
Couplage
Le monolithe représente une « grosse boule de boue » (big ball of mud), dont les modifications peuvent entraîner des conséquences imprévisibles. En modifiant une partie, on peut endommager au passage une autre partie du monolithe (comme l'expression « on se gratte l'oreille et on se fait mal ailleurs »). Cela est dû au fait que les composants du monolithe ont des interrelations très complexes et, surtout, non évidentes.
Déploiement
Le déploiement d'un monolithe, en raison des relations complexes entre ses composants, est un processus long avec ses propres rituels. Ces rituels ne sont généralement pas complètement standardisés et se transmettent « de bouche à oreille ».
Scalabilité
Les modules du monolithe peuvent avoir des besoins en ressources conflictuels, ce qui nécessite de trouver un compromis du point de vue matériel. Imaginez que votre monolithe se compose des services A et B. Le service A nécessite beaucoup d'espace sur le disque dur, tandis que le service B exige beaucoup de mémoire vive. Dans ce cas, soit la machine sur laquelle le monolithe est installé doit répondre aux exigences des deux services, soit il faudra désactiver manuellement l'un des services.
Un autre exemple (plus classique) : le service A est beaucoup plus populaire que le service B, donc vous souhaitez avoir 100 instances du service A et 10 du service B. Là encore, il y a deux options : soit nous déployons 100 monolithes complets, soit nous désactivons manuellement certains services B sur quelques-uns d'entre eux.
Fiabilité
Puisque tous les services sont regroupés, si le monolithe tombe, tous les services tombent également. En réalité, ce n'est peut-être pas si mal, du moins il n'y aura pas de pannes partielles dans un système distribué, mais d'un autre côté, à cause d'une erreur dans une fonction utilisée par 0,001 % des utilisateurs, vous pourriez perdre tous les utilisateurs de votre système.
Rigidité
En raison de la taille du monolithe, il est difficile de passer à de nouvelles technologies. En conséquence, il devient essentiel de conserver ce senior conditionnel. La pile technologique choisie au début du projet peut devenir un blocage qui empêche le développement du produit.
Conclusion
La prochaine fois, nous parlerons de la façon dont les gens ont tenté de résoudre les problèmes mentionnés en passant aux composants et à l'architecture orientée services.
Lire aussi :
Source : habr.com
