Hi Bernd, tell us who you are and what lead you into microservices?
Our customers. Over the last years they adopted that architectural style more and more – and of course had questions around it. Then I saw a lot of misunderstandings around how to implement end to end business processes or workflows in these microservices architectures – as people tried to avoid mistakes made with BPM and SOA. That got me into thinking about that whole topic and I got quite enthusiastic about it – which actually lead to a couple of articles and more than 100 talks around the world.
What will you be talking about at Voxxed Days Microservices?
I will be talking about these misunderstandings.
For example: There is a big trend towards event-driven architectures. Which is great! But people often believe that these architectures are totally decoupled, which is simply not true. If two components communicate, they are coupled. Coupling by event-notification “just” turns the direction of the dependency around, which might be nice in some cases, in some not. So if you implement some business process which spans multiple microservices purley by events, you get an event-chain, which is risky terrain. I want to explain that in more detail using a concrete example and also talk about how to achieve a good balance of orchestration and choreography.
When we think of an orchestrator in a Microservices architecture, we think of a central point of failure handling all the business logic and delegating tasks to microservices. How do you see orchestration in a Microservices architecture ?
This is exactly one conception in the market that is not true. Orchestration means that you tell somebody else to do something for you, so one microservice calling other microservices. As we are in distributed systems we have to do remote communication between microservices. This is complex, so for example you have to wait for a message or for a peer service to become available. And you might even need to implement compensating transactions, as you can’t simply rollback remote calls, but do separate “undo” calls instead. Workflow engines can help you implement this logic.
And the latest generation of workflow engines is pretty lightweight and can be embedded into your microservice itself. So the orchestration logic is part of a single microservice. So it is nothing central at all!
To make that clear I sometimes talk about “local orchestration” and I clearly recommend to avoid “BPM monoliths” in microservice environments (I wrote about that for example here .
Don’t throw out the baby with the bathwater and ditch orchestration as a concept simply because you go for autonomy and decentralization!
Good, see you soon then
#choreography #orchestration #workflow
My contact information
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
See all of them on my homepage: https://berndruecker.io/