Untitled

C'est toujours drôle de lire sur ce sujet.
La seule fois où j'ai travaillé avec des microservices, c'était dans une très petite équipe qui en possédait un grand nombre.
Les services communiquaient via AMQP, n'utilisant presque jamais de modèles requête/réponse. L'architecture a été conçue principalement à des fins opérationnelles : la capacité d'augmenter et de réduire, d'isoler les erreurs et de restaurer les services individuellement. Tous étaient conservés dans un monorepo et gérés comme une seule version.

Tout va bien ? Je me demande si j’ai réussi à défier à la fois les partisans et les opposants des microservices. 😅
Pour moi, c'était effectivement un plaisir de travailler dans ce contexte. L’équipe s’est occupée à la fois des opérations et du développement, nous n’avons donc produit aucune « douleur de l’ombre » sur les autres équipes. Le déploiement était ennuyeux. Les parties prenantes étaient plutôt satisfaites des résultats.

Le vrai problème, c’est quand les gens voient les choses comme tout ou rien. Tout comme les monolithes peuvent être modulaires, les services peuvent avoir un certain niveau de couplage. En tant qu’architecte, votre rôle n’est pas de suivre un livre à la lettre, mais de comprendre quelles parties d’une architecture offrent quelles propriétés, puis de décider, dans votre contexte, ce qui a de la valeur et ce qui ne l’est pas.