I saw mention of using flowable for microservice orchestration in the latest blog post about the performance numbers for 6.3.0. See https://blog.flowable.org/2018/03/05/flowable-6-3-0-performance-benchmark/
Is there anyone who uses flowable for this in production? I am interested in the architecture as I was starting to ponder this option myself in the last while. My thoughts are still immature.
Hi,
Yes Flowable is used for microservice orchestration. We’ve seen Flowable being used embedded in a microservice for example, but also as a separate container to orchestrate the micro services in the environment. With our improved support for Spring Boot for version 6.3.0 and the ability to run the engines separate or together this should keep all options open to use Flowable like is needed for your use case.
Best regards,
Tijs
I imagine flowable quite capable in using REST tasks to communicate with different micro services and so orchestrate them into a coherent whole and this is what I have in mind when I use the term orchestration. So for example building a camel integration as a separate spring boot/docker process rather than have it run in the same JVM as flowable.
I guess my core interest is in what people who have done this use for service discovery and how they manage that in the design for processes. For example using the HTTP task you can communicate with a REST (loose definition of it) service, but one puts the url and port in at design time, and this probably needs to be less fragile and more flexible.
But then service discovery becomes an extra layer and would take 2 HTTP tasks, one for discovery and one for the actual call to complete one function. eg. HATEOAS REST where links are returned from main resource pointing to others along with media types.
Or one would have a configuration service that adds global configuration to each process on start, but here is fragility as changes only take affect on new processes, or one has to replace many, and some might be running at the time.
These are the things I hoped others have maybe already tackled in one or other fashion and have some titbits to share…
We’re kind of doing this now, however, all of our microservices are using the Netflix framework so they all sit behind a Zuul gateway and use Eureka as the discovery service. In that type of deployment you would route all your REST calls to the gateway and let it take care of the service discovery. In that way you’re orchestrations in Flowable wouldn’t need to be concerned with discovery. They would just need to be pointed to the main gateway supporting the environment (i.e. dev, test, prod …).
For what it’s worth, discovery only happens once when the services come online and register with the discovery service rather than having to happen with each call.
Thanks Dan, this is the type of thing I was hoping to hear. I have been meaning to look into Netflix OSS.
Did a bit of searching about the current state of things and it seem Zuul 2 is going async (rxJava) and Spring cloud seem to have no plans of supported version 2, so that is rather interesting. Spring cloud gateway itself possibly an option.
Another option I want to investigate more deeply is a pure kubernetes setup where you use DNS and tags.
See here…