We are evaluating Temporal to orchestrate multiple API calls that form a logical “workflow / business operation” in a large system that is mostly based on micro-services.
However, there is one question that we don’t seem to have a clear answer for. Who “owns” the workflows written using Temporal? The idempotent APIs exposed by individual system are clearly owned by the individual systems themselves. What about the workflows?
Do we need a separate “workflow” team who owns these workflows?
Do we analyze which system is most affected by the workflow and make them the owner of that particular workflow?
When does a series of API calls become a workflow and needs to be treated differently? (with 20/20 hindsight everything can be architected perfectly, but that doesn’t hold true for systems that are built incrementally over time, and under pressure of delivery).
Do we need a separate “workflow” team who owns these workflows?
No. Think about workflows as services. So each team owns their own workflows the same way they own other microservices.
Do we analyze which system is most affected by the workflow and make them the owner of that particular workflow?
The team that owns the business logic of that workflow should own it. For example, if the workflow implements the order processing the workflow should be owned by the team that owns the order processing logic.
When does a series of API calls become a workflow and needs to be treated differently? (with 20/20 hindsight everything can be architected perfectly, but that doesn’t hold true for systems that are built incrementally over time, and under pressure of delivery).
It becomes workflow when you need to guarantee that the series of the API calls completes in the presence of various failures. Temporal doesn’t require that the whole system uses it. You can migrate the small part of the system to Temporal initially.
Thanks for your reply @maxim A few follow-up questions:
what would your recommendation be about system-specific activities? should each system build and maintain interfaces (wrt Java) for idempotent activities? using these activity interfaces other teams can build workflows.
so, workflow owned by the team that owns the overall business logic, whereas idempotent activities (and activity workers) owned by the team that own the corresponding system
As a corollary to my previous point, does this mean, that for an org that has completely transitioned to temporal, team do not really need to expose REST/HTTP microservices for internal consumption. They can expose Activity interfaces and maintain their own Activity workers?
Yes, you are 100% correct. All cross-service communication can be done through Temporal in certain scenarios. At this point, we recommend such implementation if all activities and workflows share the same namespace. We are working on enabling clean cross namespace calls in the future.