I see (at least) four roles related to the âuseâ of TOSCA:
We can expand this list to many, many more when thinking of the broader business and industry use cases.
I'm OK with the charter as is, but I agree that in the actual spec we need to be specific about roles. Now that we take profiles more seriously we are indeed reworking the spec for the two different kinds of design roles (topology designers vs. profile designer).
The reason I'm OK with the charter is that the bottom line for all this technology -- cloud and automation -- is business: reducing operational costs while providing customers with what they need. The key words are efficiency, flexibility, agility. "Easy" is not altogether useful. And "simple" ... not useful at all for me.
I'm personally not afraid of the word "complex" in this context. A complex problem wants solutions that match its complexity toe to toe. I'm more afraid of abstractions that attempt to hide away complexity, effectively passing the buck to another part of the system and leading to integration nightmares.
Â
I see the distinctions missing in some discussions â for example about âintentâ. In my world, the designers do not have any intent of their own, designers just
create the templates that satisfy the intents of the deployers on behalf of the end-users.
Good point. I will just point out that the word "intent" is often used as a technical synonym for "declarative". But, it's often worth taking a step back and reminding ourselves what we're intending to achieve vs. what we are able to declare and are declaring. The two words are different.
This is exactly where I get lost in the "substitution mapping" discussions. I think we sometimes lose track of the actual real-world problems and get caught up in our own grammatical webs.