Pourquoi ESB est considéré comme mauvais dans l'architecture des microservices
Dans l'architecture des microservices, les services commerciaux autonomes doivent communiquer directement entre eux. La communication peut être synchrone (orchestration) ou événementielle (chorégraphie). Une passerelle API peut regrouper les API du client (backends pour les frontends). Avec les microservices, nous recherchons deux objectifs ultimes
- Couplage bas
- Haute cohésion
Ce qui garantit un déploiement continu, une mise à l'échelle fine, une adaptation technologique rapide, la réutilisabilité, l'auditabilité, bien plus pour le prix d'une complexité plus élevée.
Cependant, il est fortement déconseillé d'utiliser ESB (Enterprise Service Bus) ou tout autre middleware. Les microservices et les ESB sont souvent considérés comme des solutions rivales. Pourquoi un ESB est-il si mal vu? Tant qu'il n'est utilisé que comme canal de méditation avec des couches de surveillance et d'authentification supplémentaires (pas de logique métier), quel est le problème de son utilisation dans l'architecture de microservice?
J'ai été témoin de deux déploiements ESB dans différentes entreprises, dans les deux cas avec les mêmes objectifs nobles consistant à simplement aider à la surveillance et à l'authentification, offrant un "meilleur" accès aux systèmes hérités. Dans les deux cas, en seulement 1-2 ans, l'ESB est devenu un point de défaillance unique, un goulot d'étranglement pour le changement et généralement un barrage routier pour tous les projets.
Les ESB sont tout simplement trop pratiques pour ne pas les utiliser. Tout d'abord, vous allez simplement ajouter un routage spécial pour un message que vous souhaitez envoyer à un système, puis vous résolvez rapidement de traduire un message xml dans un autre format, car vous le pouvez. Ensuite, vous ajoutez quelques XSLT supplémentaires ou quoi que ce soit à couvrir pour une mise à jour de version qui serait trop coûteuse à réparer dans le système client. Etc...
Avant longtemps, vous aurez la logique métier là-bas. Toutes les équipes devront se coordonner avec l'équipe ESB pour tous les déploiements, les nouveaux messages ou même les changements de formats de message. Il tuera l'indépendance (le couplage bas) de vos équipes.
Le point de l'architecture des Microservices, comme vous l'avez souligné, est d'activer fonctionnement autonome non seulement pour le service, mais pour son équipe également. Cela permet un changement rapide. Idéalement, cela signifierait:
- Évitez tout point de synchronisation avec d'autres équipes, que ce soit pour les tests, le déploiement, la configuration ou le fonctionnement (c'est-à-dire que vous devez aller de manière interfonctionnelle et faire des DevOps, etc.)
- Évitez l'exécution des points de synchronisation avec d'autres services. Cela signifie éviter les appels synchrones quelle que soit la technologie. Vous ne devez faire que tirer et oublier, ne jamais demander de réponse même si la réponse arrive à un moment ultérieur.
- Évitez les dépendances avec d'autres équipes. Cela signifie éviter le partage de code (de code qui a une logique métier ou des objets liés à l'entreprise)
Fondamentalement, vous devriez pouvoir continuer à utiliser votre microservice (et déployer de nouvelles versions) même si le reste de l'entreprise ferme le leur et part en vacances.
Bien sûr, c'est un scénario "idéalisé", mais un ESB va très certainement à l'encontre de tous les objectifs ci-dessus. C'est un point de synchronisation, une dépendance centralisée à la fois au niveau de l'exécution et de l'organisation.