For this reason our orchestrator has two modes of operation â fasttrack and transactional, where the former can rely on state being held in the collaborating
systems and the ongoing event-patterns, while the latter persists more process-state (at the cost of some performance), enabling it to pick up correctly after an interruption of complex activity. My experience is that fasttrack orchestration can best be described
as driving without a safety-belt â you can get away with it unharmed in really many cases, but it can become very messy in some other situations.
Â
For these reasons, I tend to see the centrifuge picture as a special case that works really well in some, e.g. cloud native, environments, but the flow-based
Orchestration Function is a necessary evil in most realistic production scenarios. That special cloud native case should definitely be supported, but I am not convinced that we can in general do away with a flow-based Orchestration Function any time
soon.
Thanks Peter, this distinction between "language" and "function" is quite useful. Although I would emphasize that we are talking about more than just syntax here and even more than just grammar -- we are talking about what's sometimes called the "semantic" of the language.
So, as I tried to emphasize: my two slides are intentionally made to be polar extremes. I expect that in the near future and even in the far future there will be a mix of modalities and paradigms. The key word is "heterogenous": we deal with heterogeneous workloads, heterogeneous platforms, heterogeneous tools, and heterogeneous orchestrators. If TOSCA has value as a "glue" language it should be able to model and express and stitch together this smorgasbord.
TOSCA is declarative. I don't think any of us doubt that. But semantics come into play when we look at what exactly we declare. We can declare an "operation", but if it's going to take part in a workflow then it's hard to call that a declaration of intent. And I think that's absolutely fine: TOSCA should be able to describe modalities that are spatial, temporal, hierarchical, circular, etc. The power of the basic graph-oriented topology is that so many of our systems can be understood as graphs. A network is a graph. A workflow is a graph (directed-acyclic-graph, specifically). In some cases we have hierarchical dependency graphs. Even more powerful is the fact that the graph edges are first-class citizens in TOSCA, which allows us to imbue relationships with rich domain-specific semantics. A relationship can be a link, a dependency, a subscription, a session, etc. And we even allow events (interfaces) on relationships.
A useful example for this discussion could be
Argo Workflows. What it does is essentially enable DAG-style workflows on top of Kubernetes. And, yes, it does this declaratively. You can declare
workflows, steps, and complete DAGs -- as Kuberentes resources. This is arguably not a purely cloud-native feature, but it is undoubtedly declarative.
So to put it in your terms: TOSCA is a declarative language, but it targets many functions. If TOSCA is optimized for just one function -- as it is up to TOSCA 1.3 -- then we are making it that much harder to be used in the multi-functional environments that are the reality of cloud right now.