Il semble que le pic de battage médiatique autour des microservices soit derrière nous. On ne lit plus les posts plusieurs fois par semaine « Comment j'ai déplacé mon monolithe vers 150 services ». Maintenant, j’entends des pensées plus pleines de bon sens : « Je ne déteste pas le monolithe, je me soucie juste de l’efficacité. » Nous avons même observé plusieurs migrations des microservices au monolithe. Lorsque vous passez d'une grande application à plusieurs services plus petits, vous devrez résoudre plusieurs nouveaux problèmes. Énumérons-les le plus brièvement possible.

Cadre : de la chimie fondamentale à la mécanique quantique

La configuration d'une base de données et d'une application de base avec un processus en arrière-plan était un processus assez simple. Je publie le readme sur Github - et souvent au bout d'une heure, quelques heures tout au plus, tout fonctionne, et je démarre un nouveau projet. L'ajout et l'exécution de code, au moins pour l'environnement initial, se font dès le premier jour. Mais si l’on s’aventure dans les microservices, le délai de lancement initial monte en flèche. Oui, nous avons maintenant Docker avec orchestration et un cluster de machines K8, mais pour un programmeur novice, tout cela est beaucoup plus compliqué. Pour de nombreux juniors, il s’agit d’un fardeau qui constitue une complication véritablement inutile.

Le système n'est pas facile à comprendre

Concentrons-nous un instant sur notre junior. Avec les applications monolithiques, si une erreur survenait, il était facile de la retrouver et de passer immédiatement au débogage. Nous avons maintenant un service qui parle à un autre service qui met en file d'attente quelque chose sur un bus de messages qui traite un autre service - et une erreur se produit alors. Nous devons rassembler toutes ces pièces pour finalement découvrir que le service A exécute la version 11 et que le service E attend déjà la version 12. C'est très différent de mon journal consolidé standard : devoir utiliser un terminal/débogueur interactif pour parcourir tout au long du processus étape par étape. Le débogage et la compréhension sont devenus intrinsèquement plus difficiles.

S'il ne peut pas être débogué, nous les testerons peut-être

L'intégration continue et le développement continu deviennent désormais monnaie courante. La plupart des nouvelles applications que je vois créent et exécutent automatiquement des tests avec chaque nouvelle version et nécessitent que des tests soient effectués et examinés avant l'enregistrement. Il s’agit de processus formidables qui ne doivent pas être abandonnés et qui ont représenté un changement majeur pour de nombreuses entreprises. Mais maintenant, pour vraiment tester le service, je dois télécharger une version fonctionnelle complète de mon application. Vous vous souvenez de ce nouvel ingénieur avec le cluster K8 de 150 services ? Eh bien, nous allons maintenant apprendre à notre système CI comment faire apparaître tous ces systèmes pour vérifier que tout fonctionne vraiment. C'est probablement trop d'efforts, nous allons donc tester chaque partie isolément : je suis convaincu que nos spécifications sont suffisamment bonnes, que les API sont propres et qu'une panne de service est isolée et n'affectera pas les autres.

Tous les compromis ont une bonne raison. Droite?

Il existe de nombreuses raisons de passer aux microservices. J'ai vu cela faire pour une plus grande flexibilité, pour faire évoluer les équipes, pour améliorer les performances, pour offrir une meilleure durabilité. Mais en réalité, nous avons investi des décennies dans des outils et des pratiques pour développer des monolithes qui continuent d’évoluer. Je travaille avec des professionnels de différentes technologies. Nous parlons généralement de mise à l'échelle car elles se heurtent aux limites d'un seul nœud de base de données Postgres. La plupart des conversations portent sur mise à l'échelle de la base de données.

Mais je suis toujours intéressé à en savoir plus sur leur architecture. À quelle étape de la transition vers les microservices se trouvent-ils ? Il est intéressant de voir davantage d'ingénieurs se dire satisfaits de leur application monolithique. De nombreuses personnes bénéficieront des microservices, et les avantages compenseront les obstacles du chemin de migration. Mais personnellement, s'il vous plaît, donnez-moi ma candidature monolithique, une place sur la plage - et je suis complètement content.

Source: habr.com