OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Thanks Tal, comments in red:
 
From: Tal Liron [mailto:tliron@redhat.com]

Sent: Wednesday, July 24, 2019 8:49 AM
To: Chris Lauwers
Cc: Calin Curescu; tosca@lists.oasis-open.org
Subject: Re: [tosca] Groups - TOSCA Imperative Workflows supporting custom workflow language uploaded
 



On Mon, Jul 15, 2019 at 5:46 PM Chris Lauwers < lauwers@ubicity.com > wrote:




        
I m not sure I agree that Bring Your Own Orchestrator is really the main promise of TOSCA. In fact, I firmly believe that TOSCA very much wants to be a full orchestration
language that allows for native TOSCA orchestration (it s actually in the name
J ). The main promise of TOSCA is that it s technology and platform-independent, which (in theory)
allows for portable service templates.




 


If this is the case, then TOSCA should publish reference implementation code. Right now the spec is riddled with ambiguity.

 
Any ambiguities in the spec should be corrected independent of whether they relate to TOSCA orchestration functionality or other parts of the spec. Having a reference
implementation would be great and would be help, but I don t think that should be a substitute for a proper language specification.





        
That doesn t mean that in practice TOSCA should be used for all (or even most) orchestration tasks. Because of its technology and platform-independent approach, TOSCA is
in fact perfectly positioned to act as an umbrella orchestrator that uses what I call a decompose and delegate approach: decompose high-level service descriptors into smaller components, where each of these components could be orchestrator by their own
(presumable domain-specific) orchestrators. For example, it would be perfectly natural to delegate orchestration of parts of a TOSCA service to Kubernetes or to use Ansible for other components.





The problem is that the spec does not make workflows optional. If an orchestrator would like to advertise itself as TOSCA-compliant then it would be expected to have full support for TOSCA workflows. This would
be a heavy requirement, especially for orchestrator that do not natively have a workflow paradigm.


 


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 .
 
Thanks,
 
Chris

On Wed, Jul 24, 2019 at 12:35 PM Chris Lauwers < lauwers@ubicity.com > wrote: 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.