tliron
commented
1 month ago Well, we're not specifically excluding generic workflow engines. Orchestrators can parse (and validate!) and do what they need to do with the complete service topology. However, we should at least give examples of how to do these things in the spec. I do think it's misleading that we include a very rudimentary workflow language. Even if we say that it's not required to use it, users get confused by what seems to be promotion of this grammar. We had the same problem with the Simple Profile, and agreed that it's best to remove it in order to avoid the suggestion that it's required.
By the way, it's not just about workflow engines (which I personally recommend avoiding; it's a miserable paradigm). We also consider declarative engines (Kubernetes, Terraform, etc.), and scripting platforms (Ansible). I have examples for all of this in Puccini.
That said, we should improve the interface operations/notifications to be a more useful membrane for defining orchestrator interaction. We've done a lot of work on this in the ad hoc committee and it will likely appear in TOSCA 2.1.
TOSCA 1.0 had the possibility to use BPMN and BPEL as workflow languages. The reason was: Workflow engines already exist. For instance, workflows can contain a "human task" asking for an approval. An example can be a license for an instance of an Oracle Dabase. Maybe also the use of a certain cloud provider. (Compliance rules is the overall keyword here)
BPMN engines such as Camunda already have implementations for that: https://docs.camunda.io/docs/components/best-practices/architecture/understanding-human-tasks-management/
BPMN also offers advanced concepts such as fault handling and compensation handling.
Thus, people already having a workflow system in place should not be forced to use or map from another workflow language.
I found it very good that TOSCA 1.0 had "plug points" for workflows. That one could specify: Hey, here is my workflow in language X and pack this together with TOSCA. (And that there were was the idea of "profiles" allowing certain workflow languages.)
Workflow engines based on BPMN can scale nearly indefinitely, offer monitoring, intelligence such as heat maps. I don't think, that TOSCA orchestrators will ever be able to cover the full useful spectrum of workflow engines.
TL;DR:
Thus, I propose to offer arbitrary workflow languages again and introduce some profiles. The "basic" TOSCA workflow language can IMHO stay for now as it works for some setups.