We talk a lot about microservices in IT, but we talk comparatively less about the reason microservices are valuable... It isn't that the technology is cool; rather, it's that the use of microservices allows us to build systems with compatible but heterogeneous building blocks. Have a microservice that performs credit checks? Written in C#? And the order service that utilizes the credit checks is written in Python? It doesn't matter, because it all just works together.
In the workflow world, we frequently assume that we'll be able to consume any service we need as a microservice, but we don't often design our workflows such that they can then be called by other systems. To make matters worse, our workflow management systems themselves often make this difficult, if not impossible. This is the workflow industry's "Top of the World" problem; we expect to be able to consume other resources as microservices but don't often design our workflows such that they can be consumed in the same manner. In a world where microservices make things more compatible, this Top of the World problem does the opposite.
If we turn this on its head and begin to design our workflows as consumable microservices, where feasible, we can create a whole new category of callable microprocesses... microservices that themselves contain orchestrated microservices. Every building block becomes a building block in and of itself. (Kudos to one of our current prospects that uses this term and this approach. And thanks for the inspiration!)
In keeping with this, the open-source world and what we've deemed the "lightweight workflow" world provide capabilities that make it possible to build these microprocesses. The three most popular, related open-source BPM/workflow platforms - Activiti, Camunda BPM and Flowable - all support the straight-through processing/request-reply paradigm out of the box. In other words, you can orchestrate collections of services and their supporting steps and return composite results to the calling thread. Take this process definition from Flowable, for example:
Figure 1
All four of the activities in this diagram - "Gather Opportunity Details", "Calculate Risk vs. Profit Opportunity", "Long/Short Paired Equities" and "Capture Investment Details in IMS" - are microservices endpoints. As such, they are all called synchronously via request/reply, and our orchestration - the workflow - can combine the responses and return them to any application that starts an instance of the process definition.
While this is just one design pattern that your workflow engine should support, it is an important one. If your workflow engine doesn't support it, you may not be able to avoid the Top of the World problem in designing your process solutions. For assistance in selecting the right platform for your organization, and ideally one that doesn't immortalize the Top of the World problem, please contact us at info@summit58.co.
Addendum
Camunda Zeebe's upcoming 0.22.0 release will introduce a feature that is very intriguing in this context, and that is Zeebe's new "Awaitable Workflow outcomes" feature (link). With Flowable, Activiti and Camunda, in order to support a request-reply model, any workflow has to call out to microservices endpoints; with Zeebe, it's possible to orchestrate a process model that supports the request/reply paradigm while having external subscribers call in to complete each work task. Unfortunately, Zeebe doesn't allow you to call out in its current iteration, so this means you have to decide which of the two capabilities is more important when making a workflow platform selection. By the way, in case you're wondering, the workflow itself looks the same:
Figure 2
(The differences are solely due to Flowable's and Camunda's slightly divergent renderings of BPMN 2.0.) The workflow models may look the same, but the underlying differences in implementation between Flowable/Camunda/Activiti and Zeebe may mean the world to an architect looking to meet his or her company's orchestration requirements.