[workflow] Proposal: Confusing Terms and Scope of Workflow WG

[salaboy]

After checking with different members of the Serverless WG in San Diego, Kubecon and online, it is clear that there are two confusing aspects around this Specification:

1. Scope of the group, currently focused on a language
2. Terms and Nomenclature used in the language

Scope of the group

Looking at other initiatives, we need to make sure that the scope of the Workflow sub group is as scoped as possible to make sure that we can incrementally deliver value to our intended audience.

The current focus until now has been the definition of a new workflow language to avoid provider lock-in. While this is an important effort, we also need to cover how these workflow definitions will be referenced in the infrastructure, and following how Cloud Events have currently defined this group will benefit from having well-defined types for workflows to be understood by other components. I will be working on a PR for a proposal around this as well as a more scoped definition about the subgroup goals and objectives.

Terms and Nomenclature for the Workflow language

Currently, this Specification uses a State Machine nomenclature to specify how a workflow can be constructed, where the main concept used is "states". While this is fine for certain scenarios, using States' nomenclature can lead to wrong assumptions related to more theoretical frameworks such as automata and FSMs (https://en.wikipedia.org/wiki/Finite-state_machine) where certain formalisms need to be applied, which will not apply to all use cases of this specification.
I will be working on a proposal for the group to decide on these new terms to make sure that the specification is as clear as possible and doesn't lead to wrong or complex assumptions about the intentions for the language.

@tsurdilo @cathyhongzhang @mswiderski @berndruecker I will create two PRs, but I wanted to share this before to see if the group understands about the motivation behind these proposals and clarify doubts to everyone else that wants to get involved.

[tsurdilo]

@salaboy looking forward to see what you have in mind. I do have some questions just because they way this issue is written sounds like there are some big foundation issues with what we currently have that need to be addressed..but will wait to see your proposals cause they might answer it all.

[manuelstein]

@salaboy, thank you for starting the issue.
IMHO the workflow spec is in a curious situation that is difficult to paraphrase, so it's good to get a starting point.

Regarding "Scope of the group", today's spec defines the "goals" of a vendor-neutral model and spec that can be implemented stateful and stateless in support of serverless app portability. Today's subgroup readme defines the goal of a standard way to specify workflows and help portability across vendors.
To my surprise I could not find any model reviews, synthesis of existing approaches or even a listing of related work. I noticed some similarities of the current spec with Huawei FunctionGraph which itself seems to borrow some design concepts from Amazon States Language. With some additions already, the spec evolves independently. But to be brief, I don't see how this helps meeting the goals.

In support of "Terms and Nomenclature", I would like to say that I think a proper discussion would help to clearly define what the workflow specification is supposed to specify. If it was a workflow, the term task would be more suitable than state. The design of a state like a workflow task (with nextState transitions and onError transitions) certainly doesn't help. It could be a state machine, but currently, transitions are limited to the output of the action attached to the state. With input/output content handling, data filtering and event passing through the transitions, the spec also describes (part of) the data flow. With new additions (error handling) it's becoming more of a full process model. Maybe if the path was a bit clearer, using the right terminology would be easier.

[salaboy]

@manuelstein I've introduced the reference section.. so we can both populate that with more references: https://github.com/cncf/wg-serverless/blob/master/workflow/spec/references.md

As you can see in #129 that I am suggesting Task instead of State, and correct me if I am wrong but @tsurdilo is ok with that.

[tsurdilo]

@manuelstein @salaboy I don't fully understand why state machine vs workflow is really a big issue. And yes, as far as the name "state" or "task" either is OK with me. We could call it "milestone" even (or do we get into case management with this ;) )

As far as implementations, I would not be concerned about that part so much. What we should be concerned at this point imo is the improve the specification document and add as many examples as possible. Please look at spec-examples.md and point out if you can what is confusing and what you think can be better and how. Things like "this example does X but after reading the documentation I dont see it explained there" would be huge if you can help with that.

I think at this time having concrete things to work on is much more relevant than thinking about implementation details..for all I personally care users can implement this spec as state machines or workflows or if/else statements if they want.

[salaboy]

I totally get @tsurdilo point ... let's write examples where we can show what is actually confusing.. I think that @manuelstein already asked some concrete questions here: #140 that I will try to answer and see if I can understand where the confusion is coming from.

[tsurdilo]

did't see that issue raised yet, very nice! Yes as @salaboy mentioned that is great info to have- thanks!

[cathyhongzhang]

I agree with you that the spec has quite some places that are confusing. Yes, raising specific issues to show where you see the confusion will help make the spec better.

[wanghq]

using States' nomenclature can lead to wrong assumptions related to more theoretical frameworks such as automata and FSMs (https://en.wikipedia.org/wiki/Finite-state_machine) where certain formalisms need to be applied, which will not apply to all use cases of this specification.

Totally agree on this. Here are some examples I usually don't see in a traditional FSM.

• For all the Step Functions (as an example since it uses State Machine) examples I've read, none of the state defined is like a state (locked/unlocked), but all of them are actions/tasks (lock/unlock).
• Most Step Functions states can only transit to one other state except the choice state.
• Some states (within parallel) cannot transit to outside states.
• The parallel state can transit to multiple states.

So we (Alibaba Cloud Function Flow service) use flow/steps to describe the business logic. Here is an example flow (sorry the project readme is in English).

[salaboy]

@wanghq thanks for your feedback, it will be great to get your Alibaba experience here in the group.

In general, the idea of calling a "state" to something like a choice is very overloaded, the same for event.

[tsurdilo]

The naming convention changes regarding workflow control blocks is addressed here: #243