[Multi tenant] Namespace/Domain for workflow and tasks for isolation

[ysaakpr]

Description
We are using zeebe as an end to end orchestrator. but here comes the problem, when there are distributed teams, working parallel on multiple projects, and integrating with zeebe, to orchestrate the tasks, How do we ensure that the task types are not conflicting. One person in the ecosystem can cause damage to the entire workflow, by wrongly defining a task handler, with a same task type.

Whats the thought on this?

[saig0]

Hi @ysaakpr,

thank you for raising this up.
I'm not sure if this is a problem we can address inside Zeebe. It sounds more like an organizational problem. If you want to separate the different clients/teams then you can use different Zeebe clusters.

What would be your expected behavior?

[ysaakpr]

Can we introduce some namespace and namespace authentication, where namespaces can be assigned to teams? Something similar to Kubernetes namespace. And cross namespace access should be possible so that workflows can refer to tasks defined in the other namespaces, like services in Kubernetes. Which avoid running multiple clusters and using one cluster between multiple teams effectively. Just a thought. not sure how technically this fit for the architecture of zeebe.

[saig0]

@ysaakpr, thank you for the insides.

I understand your requirement in the following way:

• a specific worker can only be used from a defined workflow (or a group of workflows)
• or, a specific worker can only be used from workflow instances that have been created by a defined group of users

Is this correct? Any additional requirements?

[ysaakpr]

@saig0, Looks like you mis understood, my bad. Let me explain.

Lets take a situation where multiple teams who using Zeebe, and all of them can add workflows and add new task types.

team-1 defined and bind a taskTypeHandler for type processOrder
team-2 was not aware there exists a processOrder task already, and named their tasktype also as processOrder
team-2 defined and bind a taskTypeHandler for type processOrder

In this case, zeebe get two different handlers registered for the same taskType. Both of them. will be expecting two different processOrder instances, but there is no way as of today to avoid tasktype conflict. As you mentioned it may be an organizational problem. But I think introducing concepts like tasks namespaces, we can always bring some kind of isolation to this, as I mentioned the example of Kubernetes namespace and service in the last comment

I am expecting the following experience by introducing namespace

1. namespace can be owned by teams, and need to be authenticated to create resources in namespace(can be added in future)
2. workflows are always in the context of a namespace,
3. Workflows can refer to tasks which are in another namespace, buy using some dns name mode(tasktype.namespace)

Example of namespaces design we can borrow

1. Rabbitmq vhosts
2. Kubernetes namespaces

[saig0]

@ysaakpr thank you for the clarification! This makes it more clear that is the actual problem.

A workaround without proper namespaces could be a prefix for the job types. So, every job type includes a prefix, for example, the name of the team/client/organization (e.g. team-1-processOrder). In the workflow, the job type can be defined statically (team-1-processOrder) or by reading the prefix from a workflow instance variable (= teamName + "-processOrder").

[ysaakpr]

Exactly, this is what we currently doing, something like this <teamname>.<taskTypeName>

Lots of complexity following this in org-wide, as which is not restricted by the broker. Another approach we thought to do was to wrap the SDK where the team name should be a mandatory option and while binding it binds to . always.

But I found that feature from the zeebe system would be amazing if it can be done. Else we have to create a complete wrapper API around Zeebe, which brings this restriction, which we are planning to do if this is not coming under the scope of Zeebe. Instead of the effort we are putting to create a wrapper if we put on making it as a part of the system, it might help others well.

I believe many similar systems has something similar, Netflix conductor has very similar feature which is called as the domain. two domains are isolated.

[ysaakpr]

Another example is Uber Cadance - Domain
https://cadenceworkflow.io/GLOSSARY.html

domain
Cadence is backed by a multitenant service. The unit of isolation is called a domain. Each domain acts as a namespace for task list names as well as workflow IDs. For example, when a workflow is started, it is started in a specific domain. Cadence guarantees a unique workflow ID within a domain, and supports running workflow executions to use the same workflow ID if they are in different domains. Various configuration options like retention period or archival destination are configured per domain as well through a special CRUD API or through the Cadence CLI. In the multi-cluster deployment, domain is a unit of fail-over. Each domain can only be active on a single Cadence cluster at a time. However, different domains can be active in different clusters and can fail-over independently.

[mrsateeshp]

"lack of support for namespace" is a big issue for us, it is currently preventing us from sharing the platform with multiple tenants.
our issue is with "Message based start task". (i.e. if there are multiple workflows with the a same message type for start event, all of them will be triggered, and there is no way to restrict message correlation to a specific workflow/process_id).
This is a problem for us because we have one generic workflow and small variations of that same workflow for different tenants. so all of them have exactly same message-based-start-task(s).

also we ideally want to segregate orchestrations for the tenants as cleanly as possible(without having to setup new clusters), fiddling with job/message types does not sound like a clean/scalable/error-free solution.

is there any update on current thinking on this issue please?

[morphace]

+1

[npepinpe]

From having done a prototype of this, I would say the majority of the work would fall under the ZPA team. Feel free to object, but in the meantime I moved it to the other project :)

[mmack]

👍