Further Reading#

Articles#

• If you do microservices correctly, you don’t need a workflow engine or BPMN – Great blog post from 2015. It’s a Google Translate link, the original is in German: Wer Microservices richtig macht, braucht keine Workflow Engine und kein BPMN

• Refactor from Monolith Workflow to Micro-Workflows – As far as I can tell, the author of this blog post coined the term “microworkflow”.

• Orchestration vs choreography for microservice workflows – find a quote from this blog post below.

Quotes#

No shiny “workflow platform” can solve the problem of mega-workflows being a maintenance nightmare, and a shady place where the responsibilities of the parties are not clear - as everybody claims - the workflow is it’s own thing, but then again there is no team responsible for such workflow. So I think tool matters less. The process is important. Same way we are splitting the monolith into bounded contexts in DDD, or into micro-services from process/org structure perspective, mega workflows spanning many such microservices better be split as well, with very clear boundaries around micro-workflows, and clearly defined interfaces between them.

Kiril Chilingarashvili on LinkedIn

One problem with orchestration is that it tends to give rise to complex infrastructure. A centralised orchestrator service needs to implement a range of concerns, including control flow, routing, connectivity, retries, data transformation, monitoring and reporting. This can give rise to runaway complexity over time as integration logic accumulates in a central integration platform.

Ben Morris, see “Orchestration vs choreography for microservice workflows” above.

In reactive systems one should try to avoid orchestration as it moves you away from being reactive towards telling other components what work to perform.

Kris Kater on LinkedIn