Voxxed Days Microservices est un événement centré exclusivement sur les Microservices. Durant cette seconde édition, deux jours de conférences et un jour d’atelier (en option) auront lieu à Paris du 21 au 23 octobre 2019.
Les lecteurs d'InfoQ peuvent profiter d'une promo de 20% avec le code VXDMS19_COM_INFOQFR lors de l'inscription.
InfoQ s'est entretenu avec Bernd Rucker au sujet de sa session intitulée "Complex event flows in distributed systems".
Bonjour Bernd, dis-nous qui tu es et qu'est-ce qui t'a conduit vers les microservices ?
Nos clients. Au cours des dernières années, ils ont de plus en plus adopté ce style architectural - et se posaient bien sûr des questions à ce sujet. J'ai ensuite constaté de nombreux malentendus sur la manière de mettre en œuvre des processus métier ou des workflows de bout en bout dans ces architectures de microservices, alors que les utilisateurs essayaient d'éviter les erreurs commises avec BPM et SOA. Cela m'a amené à réfléchir à l'ensemble ce sujet et cela m'a enthousiasmé - ce qui a conduit à la publication de deux articles et à plus de 100 exposés dans le monde entier.
De quoi parles-tu à Voxxed Days Microservices ?
Je vais parler de certains malentendus.
Par exemple : la tendance est aux architectures événementielles. Qui est super ! Mais les gens croient souvent que ces architectures sont totalement découplées, ce qui n’est tout simplement pas vrai. Si deux composants communiquent, ils sont couplés. Le couplage par notification d'événements inverse "juste" le sens de la dépendance, ce qui peut être agréable dans certains cas, dans d'autres non. Ainsi, si vous implémentez des processus métier qui couvrent plusieurs microservices en fonction d'événements, vous obtenez une chaîne d'événements, qui est un terrain risqué. Je veux expliquer cela plus en détail en utilisant un exemple concret et aussi expliquer comment parvenir à un bon équilibre entre orchestration et chorégraphie.
Lorsque nous pensons à un orchestrateur dans une architecture Microservices, nous pensons à un point d’échec central gérant toute la logique métier et déléguant des tâches aux microservices. Comment vois-tu l'orchestration dans une architecture Microservices ?
C'est exactement une conception du marché qui n'est pas vraie. Orchestration signifie que vous demandez à quelqu'un d'autre de faire quelque chose pour vous, donc un microservice appelle d'autres microservices. Comme nous sommes dans des systèmes distribués, nous devons établir une communication distante entre les microservices. Ceci est complexe, vous devez par exemple attendre qu'un message ou qu'un service homologue soit disponible. Et vous pourriez même avoir besoin de mettre en œuvre des transactions compensatoires, car vous ne pouvez pas simplement annuler des appels distants, mais séparez les appels «undo». Les moteurs de workflow peuvent vous aider à implémenter cette logique.
Et la dernière génération de moteurs de workflow est assez légère et peut être intégrée à votre microservice lui-même. La logique d’orchestration fait donc partie d’un seul microservice. Donc, il n’y a rien de central !
Pour que cela soit clair, je parle parfois de «l'orchestration locale» et je recommande clairement d'éviter les «monolithes de BPM» dans les environnements de microservice (j'ai écrit à ce sujet par exemple ici .
Ne jetez pas le bébé avec l'eau de bain et l'orchestration en tant que concept simplement parce que vous optez pour l'autonomie et la décentralisation !
Bon, à bientôt alors
Mes coordonnées
Twitter : http://twitter.com/berndruecker/
Blog : https://blog.bernd-ruecker.com/
LinkedIn : https://de.linkedin.com/in/bernd-ruecker-21661122
GitHub : http://github.com/berndruecker
Voyez-les tous sur ma page d'accueil : https://berndruecker.io/