Thanks Peter and Tal for a very stimulating discussion.
Basically, we made the language define a compositional graph-grammar instead of just a graph. Also, we went a different direction than
TOSCA by making the DSD language Turing-complete while also being completely declarative. I know that we deliberately do not want that with TOSCA. But the graph grammar approach does solve
all the day 2 expressiveness issues that some uses of TOSCA are facing.
I have a couple of questions (primarily looking for clarification of some of your points):
- Could you please explain what you mean by âcompositional graph grammarâ vs. âjust a graphâ?
- What is it about TOSCA in your opinion that makes it not Turing-complete (as opposed to a compositional graph grammar?)
- 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:
- Service designers use TOSCA as a declarative language, using types defined in the various TOSCA profiles
- Profile designers use TOSCA as an imperative language by defining interfaces, operations, notifications, and artifacts
that âimplementâ the types in their profiles
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.
- 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.
Thanks,
Chris
|