In my view we would do better to reduce the entry requirements for TOSCA, not add to them. Let's put this is the most practical context: Are we expecting the community (or a software startup) to come up with a robust,
production-ready TOSCA workflow orchestrator? I would not bet on that horse. I think we are better off complimenting existing orchestration solutions by allowing them to do what they do best, on their own terms.
Â
Thatâs a reasonable suggestion that should be considered and discussed in the TC meetings. Letâs plan on putting this on the agenda for one of our future meetings.
This could lead to a ârealâ distinction between a full spec and a âsimple profileâ.
As someone who thinks that the Simple Profile is a non-starter, I don't know if the distinction would be important. There is no orchestrator that implements everything in TOSCA, definitely not based on the Simple Profile types for any actually existing cloud platform. I don't know if there ever will be.
Yes, TOSCA needs to be a proper *language* specification. But when the spec dictates an orchestration architecture it goes beyond "language". Indeed I believe there's confusion in the industry as to what TOSCA really is and what it means to be a "TOSCA orchestrator". This confusion does not benefit adoption.
I am very much hoping that we would be able to separate the Simple Profile from the language specification itself. Then, orchestrators could come with profiles that make sense for their domains. These profiles could use some or all TOSCA language features. Some would make use of workflows and interfaces and artifacts and attributes substitution mapping if those features makes sense for the cloud platform, some might not. They would still be compliant with the *language*, and we would all benefit from that commonality.
As an example, in Puccini I'm experimenting with various example profiles that address real-world use cases. Specifically, the Kubernetes/Istio profile provides a nice TOSCA-based alternative to Helm. But, I can't find a use for workflows in Kubernetes. However, the BPMN profile does allow you to create workflows that can be exported as sub-processes to BPMN middleware. So, it could be possible to import both profiles and allow for a service template that can deploy a complex Kubernetes application, with a service mesh, and then allow workflow extensions to define the relationship of nodes within the service to a BPMN open loop.