[workflow] Proposal: Serverless Workflow WG Scope

[salaboy]

As presented in San Diego, the scope of the group has been the definition of a vendor-neutral Workflow Language for Serverless Applications.

As stated in the main README file of the group:

“The goal of the Serverless Workflow sub-group is to come up with a standard way for users to specify their serverless application workflow, as well as help, facilitate portability of serverless applications across different vendor platforms.
Serverless Workflow is a vendor-neutral and portable specification that meets these goals.”

While this is a big effort in itself, having just a language will not promote cloud providers to implement it, we need to define how the language and the concepts defined in the group will be mapped to actual implementations in the existing CNCF ecosystem.

As stated in workflow Proposal: Confusing Terms and Scope of Workflow WG · Issue #127 · cncf/wg-serverless · GitHub, the lack of clear scope and how the current language will be handled by different vendors is causing confusion, hence this proposal.

Proposal

The scope of the group should be changed to cover two main angles:

• Workflow Language (well-scoped for the first iteration)
• How cloud providers can integrate with Workflows, meaning which standard APIs/Contracts should Cloud Providers implement in order to integrate with workflows.

By covering these two points we will promote (as a group) the use of the vendor-neutral language as well as how cloud providers can understand these workflows.

In a Kubernetes world, the integration with the ecosystem can be done by defining a new concept (CRD) “Workflow” that Kubernetes can understand and then manage and monitor the lifecycle of each Workflow.

By providing this new concept, each cloud provider can understand that there is a new Workflow available and then do whatever is necessary to deploy, execute and monitor these Workflows.
The “Workflow” concept itself can include a reference to the workflow definition and metadata that can be used as an envelope for the definition itself.

The “Workflow” concept becomes part of a Standard API which is vendor-neutral as well as the Workflow Definition Language.

An initial proposal is provided in this PR:
#131

Feedback is more than welcome.

[tsurdilo]

@salaboy can this issue be closed as #131 is merged ?

[salaboy]

@tsurdilo I would like to include a description in the group motivation as well.. is it ok if I send a PR there?
I accept suggestions, comments or thoughts about the phrasing in this PR:
#147

[salaboy]

@tsurdilo to close that part of the scoping proposal, I would like to add a section describing the file that was merged inside the infra folder. If you are ok with that I will send a PR with that section.

[salaboy]

@tsurdilo let's close this one as well.. I think that I will create a separate one, more specific if we need more.