Il semble que l'apogée de l'engouement pour les microservices soit derrière nous. Nous ne lisons plus plusieurs fois par semaine des articles intitulés « Comment j'ai migré mon monolithe vers 150 services ». Maintenant, j'entends plus souvent des réflexions sensées : « Je ne déteste pas le monolithe, je me soucie juste de l'efficacité ». Nous avons même observé plusieurs migrations . En passant d'une grande application à plusieurs services plus petits, vous devrez résoudre plusieurs nouveaux problèmes. Énumérons-les le plus brièvement possible.
Configuration : de la chimie de base à la mécanique quantique
Configurer une base de données de base et une application avec un processus d'arrière-plan était un processus assez clair. Je publie le readme sur Github — et souvent, dans une heure, au maximum quelques heures, tout fonctionne, et je commence un nouveau projet. Ajouter et exécuter du code, du moins pour l'environnement initial, se fait le premier jour. Mais si nous nous aventurons dans les microservices, le temps de lancement initial s'envole. Oui, nous avons maintenant Docker avec orchestration et un cluster de machines K8, mais pour un programmeur débutant, tout cela est beaucoup plus compliqué. Pour beaucoup de juniors, c'est un fardeau qui représente une véritable complexité inutile.
Le système est difficile à comprendre
Prenons un moment pour réfléchir à notre junior. Avec des applications monolithiques, lorsqu'une erreur se produisait, il était facile de la suivre et de passer immédiatement au débogage. Maintenant, nous avons un service qui communique avec un autre service, qui met quelque chose dans une file d'attente sur le bus de messages, qui traite un autre service — et c'est là qu'une erreur survient. Nous devons rassembler toutes ces pièces pour finalement découvrir que le service A fonctionne avec la version 11, tandis que le service E attend déjà la version 12. Cela diffère fortement de mon journal consolidé standard : je dois utiliser un terminal interactif/débogueur pour parcourir le processus étape par étape. Le débogage et la compréhension sont devenus essentiellement plus difficiles.
Si nous ne pouvons pas déboguer, peut-être que nous les testerons
L'intégration continue et le développement continu deviennent désormais monnaie courante. La plupart des nouvelles applications que je vois, avec chaque nouvelle version, créent et exécutent automatiquement des tests et exigent que les tests réussissent et soient examinés avant de s'engager. Ce sont d'excellents processus dont on ne peut pas se passer, ils ont constitué un grand changement pour de nombreuses entreprises. Mais maintenant, pour vraiment vérifier le service, je dois mettre en place une version fonctionnelle complète de mon application. Vous vous souvenez de ce nouvel ingénieur avec un cluster K8 de 150 services ? Eh bien, maintenant nous allons apprendre à notre système CI comment mettre en œuvre tous ces systèmes pour vérifier que tout fonctionne réellement. Cela risque d'être trop d'efforts, donc nous allons simplement tester chaque partie de manière isolée : je suis sûr que nos spécifications sont assez bonnes, que l'API est propre, et qu'une panne de service est isolée et n'affectera pas les autres.
Tous les compromis ont une bonne raison. N'est-ce pas ?
Il existe de nombreuses raisons de passer aux microservices. J'ai constaté que cela est fait pour plus de flexibilité, pour la mise à l'échelle des équipes, pour la performance, afin d'assurer une meilleure résilience. Mais en réalité, nous avons investi des décennies dans des outils et des pratiques de développement de monolithes, qui continuent d'évoluer. Je travaille avec des professionnels sur différentes technologies. En général, nous parlons de mise à l'échelle, car ils rencontrent les limites d'un seul nœud de base de données Postgres. La plupart des discussions portent sur .
Mais je suis toujours curieux d'en apprendre davantage sur leur architecture. À quel stade de la transition vers les microservices se trouvent-ils ? Il est intéressant de voir de plus en plus d'ingénieurs dire qu'ils sont contents de leur application monolithique. Pour beaucoup, les microservices seront bénéfiques, et les avantages l'emporteront sur les obstacles rencontrés lors de la migration. Mais personnellement, donnez-moi, s'il vous plaît, mon application monolithique, un endroit sur la plage – et je suis complètement heureux.
Source : habr.com
