Micro service orchestration clarification

[Karthick]

Quick question. We have 4 microservices which are exposing APIs and Kafka today. And an orchestration is being done via a centralized orchestrator as of today.

We are looking at temporal to help us with orchestration of flows across the 4 microservices that we have.

Just wanted to see which is the right approach.

1. Keep the 4 services as it is and just replace the orchestration service to be a temporal based workflow engine - which will have activities as part of workflow and these activities would invoke the 4 existing services vis APIs

2. Make the 4 services also to be aware of Temporal so the activities are directly implemented in these 4 services and they pick the request from activity task queue directly from temporal server.

With Option 1 - I feel that there would be too many i/o operations when invoking an activity from workflow. Workflow – GRPC–> Temporal Server → Task Queue → Activity Worker → Rest call to microservice and gets the response. Response would again go through the same path but backwards to go back to workflow (please correct me if I am not). But the advantage with option 1 is that the existing microservices know nothing about temporal and can work as it is today

With Option 2, I feel the i/o comes down but all services in architecture is aware and consume tasks from task queues directly from temporal

Can you please let me know what’s the preferred approach here?

[maxim]

How to let one workflow interact with multiple microservices

All of the scenarios are feasible and were used by different users of Temporal. Here are some reasons to choose one over another. I could first implement rest interfaces in each service that trigger the necessary steps and then implement activities that call these endpoints at some central place. I would then create a workflow calling these actions and register it with a worker, running in a separate service. This approach has a very serious drawback in the lack of flow control between the …

[Karthick]

Thanks @maxim . I take it that the preferred option is #2. We should look for #1 only if our hands are tied and cannot really plug a service to temporal for whatever set of reasons may be.

[Karthick]

One quick follow up pls. So far, I generally define an activity interface containing an activity method (via annotations) and invoke my activity method from workflow - which does the GRPC magic internally.

In option 2 - if the activities are hosted on other microservices. How do I invoke those methods please?

Should I use untyped stub for activity and post the request as opposed to getting a strongly typed activity interface and calling a method?

[tihomir]

You can use untyped workflow stub if you want, but you can also use strongly typed approach by defining an activity interface that matches the one you want to invoke, and then set the appropriate task queue in ActivityOptions (note this works cross-temporal-sdks as well, see sample here)

[Karthick]

Thanks. Will check it out.