Il semble que le pic de battage médiatique pour les microservices soit derrière. Nous ne lisons plus les articles «Comment j'ai transféré mon monolithe vers 150 services» plusieurs fois par semaine. Maintenant, j'entends souvent des pensées raisonnables: "Je ne déteste pas le monolithe, je me soucie juste de l'efficacité." Nous avons même observé plusieurs migrations des microservices vers le monolithe . Lorsque vous passez d'une grande application à plusieurs services plus petits, vous devrez résoudre plusieurs nouveaux problèmes. Nous les énumérons aussi brièvement que possible.

Installation: de la chimie de base à la mécanique quantique

La configuration de la base de données de base et de l'application avec le processus d'arrière-plan était un processus assez clair. Je publie un fichier Lisezmoi sur Github - et souvent après une heure, au plus, quelques heures, 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 le tout premier jour. Mais si nous nous aventurons dans les microservices, le temps de lancement initial prend son envol. Oui, nous avons maintenant un Docker orchestré et un cluster de machines K8, mais pour un programmeur débutant, tout cela est un ordre de grandeur plus compliqué. Pour de nombreux juniors, c'est un fardeau d'une complexité vraiment inutile.

Le système n'est pas facile à comprendre.

Arrêtons-nous un instant sur notre junior. Avec les applications monolithiques, en cas d'erreur, il était facile de le suivre et de procéder immédiatement au débogage. Nous avons maintenant un service qui communique avec un autre service qui met en file d'attente quelque chose sur le bus de messages qui traite un autre service - puis une erreur se produit. Nous devons rassembler toutes ces parties afin de finalement découvrir que le service A est en cours d'exécution dans la version 11, et le service E attend déjà la version 12. Ceci est très différent de mon journal consolidé standard: vous devez utiliser un terminal / débogueur interactif pour passer par le processus étape par étape. Le débogage et la compréhension par essence sont devenus plus difficiles.

Si vous ne pouvez pas déboguer, nous les testerons peut-être

L'intégration et le développement continus 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 nécessitent que les tests réussissent et soient examinés avant l'enregistrement. Ce sont d'excellents processus qui ne peuvent être abandonnés; ils sont devenus un grand changement pour de nombreuses entreprises. Mais maintenant, pour vraiment tester le service, je dois augmenter la version de travail 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 enseigner à notre système CI comment élever tous ces systèmes pour vérifier que tout fonctionne vraiment. C'est probablement trop d'effort, nous allons donc tester chaque partie isolément: je suis sûr que nos spécifications sont assez bonnes, les API sont propres, et l'échec du service est isolé et n'affectera pas les autres.

Tous les compromis ont une bonne raison. Non?

Il existe de nombreuses raisons de passer aux microservices. J'ai vu qu'ils le font pour une plus grande flexibilité, pour les commandes de mise à l'échelle, pour les performances, pour fournir une meilleure stabilité. Mais en réalité, nous avons investi des décennies dans les outils et les pratiques de développement de monolithes, qui continuent de se développer. Je travaille avec des professionnels de différentes technologies. Nous parlons généralement de mise à l'échelle car ils sont confrontés aux limites d'un seul nœud de base de données Postgres. La plupart des discussions portent sur la 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 comment de plus en plus d'ingénieurs se disent satisfaits de leur application monolithique. De nombreux microservices en bénéficieront, et les avantages l'emporteront sur les nids de poule sur le chemin de migration. Mais personnellement, donnez-moi, s'il vous plaît, mon application monolithique, une place sur la plage - et je suis complètement heureux.