Hi Chris,
Great questions. There is a limit to what more, I can disclose. Looking up patents
with my name can give some information.
-
Could you please explain what you mean by compositional graph grammar vs. just a graph ?
A Graph Grammar corresponds to a Topology, like a BNF grammar corresponds to a program
written in the language defined by that grammar.
A BNF grammar for a programming language defines a class of texts that are syntactically
valid for that language. You add a static semantics (type-checking, etc. to further constrain valid programs). A BNF grammar is not fully compositional, because you cannot add new production rules without modifying existing rules, but the BNF language itself
could easily be modified to become fully compositional.
Furthermore, you usually want the language to have a denotational semantics adding
a production to the graph should not alter the semantics of existing constructs. The DSD language is compositional you can incrementally add new production rules to the service grammar, that allow you to express more complex services (more topologies).
Example: Rule/trigger-based programming is compositional, because you can keep adding
more rules that would fire under certain conditions. But it is not denotational, because adding one rule could completely alter the meaning of existing rules. Basically, such a non-denotational rule-base gives you something akin to the proverbial Aprils
fool conditional comefrom construct
https://en.wikipedia.org/wiki/COMEFROM -
What is it about TOSCA in your opinion that makes it not Turing-complete (as opposed to a compositional graph grammar?)
TOSCA is not trying to be a programming language (aka Turing-complete). Speculatively,
I guess you might be able to make substitutions recursive, and so claim Turing completeness, but that is not a recommended use of TOSCA. Graph Grammars by themselves are not a programming language either that would be like claiming that BNF is a programming
language. So of course there is more to that
-
What do you mean by completely declarative ? In my opinion, any declarative language requires a tool that turns declarations into the imperative sequence of
steps that must be taken to realize those declarations. If that tool has built-in knowledge about the set of entities that can be used in those declarative descriptions (e.g., Kubernetes), then nothing further is required. However, now that we have removed
the Simple Profile types from the TOSCA language, TOSCA no longer has any built-in knowledge about anything, and every type is a custom type. This means that imperative support must be provided to implement those custom types. Fortunately, the TOSCA
language includes imperative features that support this. The fact that TOSCA is both declarative and imperative is one of the very important differentiators of TOSCA, in my opinion:
o
Service designers use TOSCA as a declarative language, using types defined in the various TOSCA profiles
o
Profile designers use TOSCA as an imperative language by defining interfaces, operations, notifications, and artifacts that implement the types in their profiles
TOSCA, HOT and DSD are the same family, equally declarative, as Tal pointed out.
The languages are declarative in the sense that an _expression_ in that language does
not say: First do this, then that . You can add artifacts etc, that allows an orchestrator to create a plan/playbook/process/ to deploy the service, but the orchestrator could also derive how to
undeploy the same service, or modify it. So the language itself does not imply the direction of actions, only policies for creating actions after being given a direction. Compare to imperative languages like C++/Java/Workflows. There is no way to reverse
the actions of such languages. Functional languages are not reversible, but logic languages Prolog are (unless you use cuts ! ), so they can be used declaratively. The fact that there are policies/artifacts/interfaces/operations/etc that guide the translation
from declarative to sets of actions does not make these languages less declarative in their essence.
By the way, I am aware of the reversible programming research topic, but that is
something different.
I would also like to come back to some of my earlier comments:
-
We continue to talk about cloud-native orchestration without actually ever defining that term. In order to have productive discussions, we need clear definitions
about terminology.
Here is an initial shot at a definition:
The orchestration can be cloud-native if and only if:
1.
The orchestrator itself is cloud-native
2.
Every part of a service can be created/deleted/configured/reconfigured on
a cloud-native sub-system by sending a declarative configuration to that sub-system
3.
Any order of pushing declarations to sub-systems has the same effect (temporal
symmetry)
4.
Any required coordination between the sub-systems is handled by communication
directly between the sub-systems, and does not require mediation by the orchestrator
5.
Optionally (?): The orchestrator is informed by each sub-system about its
state, allowing the orchestrator to represent snapshots of the end-to-end state of the service
6.
Optionally (?): If the orchestrator is informed about deviations from the
desired end-to-end service configuration in a sub-system, it may react by pushing additional configurations to the sub-systems
Tal, please improve.
What I may be getting wrong here is that there is still a hierarchy of the orchestrator
and the sub-systems , but could there be an architecture of peer-orchestrators, where each orchestrator would appear as a sub-system to the other orchestrators? But in such an architecture, could the peer-orchestrators have conflicting objectives so they
might start fighting by perceiving the configurations pushed by other orchestrators as conflicting with their own objectives?
-
The same holds for the moving from the inside out (the centrifuge concept) vs. moving from the top down . I believe Tal wanted to position these as two very different
orchestration concepts, but I must admit I m not entirely clear on the core distinction between these two. Is the centrifuge concept an implementation of the Operator pattern (where declarative descriptions are converted into more fine grain declarative
descriptions) or am I missing the point? If so, I have previously suggested decompose and delegate as a way to describe the same concept. If this is what the centrifuge concept represents, then I agree that this is a must-have feature. But I believe this
feature should be used for decomposing abstract representations into concrete descriptions that can actually be orchestrated, not as the orchestration functionality itself. Either way, I believe it would be helpful to better describe these concepts.
This is for Tal.
/Peter