1. Why Do We Need a (Plan) Portability API? Gerd Breiter Frank Leymann Thomas Spatzier

2. TOSCAs Goal Provide the ability to create portable descriptions of Cloud applications and their operational behavior – The TOSCA Charter says about the latter: TOSCA will facilitate this goal by enabling the interoperable description of...the operational behavior of these services (e.g., deploy, patch, shutdown)... TOSCA will also enable the association of that higher-level operational behavior with cloud infrastructure management. 1

3. What is Out of Scope The charter says explicitly whats out of scope: –...The interface definitions of a service container.... But the proposed (Plan) Portability API is not an interface of the container The (Plan) Portability API is an interface that must be available in a TOSCA environment to allow portable operational behavior of Cloud Applications Thus, the (Plan) Portability API is not functionality to deal with the container itself In this sense, the (Plan) Portability API is in scope 2

4. Why This Problem Now? We focused on initial deployment of Cloud applications since starting the TOSCA TC Initial deployment can be done via two very different approaches: the declarative approach and the imperative approach – See next… SugarCRM can be deployed in a declarative way – But more general operational behavior cannot be derived declaratively – Even for SugarCRM, the operational behavior after initial deployment can in general not be derived in a declarative manner In general, operational behavior requires an imperative approach An imperative approach needs explicit access to state information of an already deployed application, as well as state information of its ingredients (instances of node types, relationship types etc). 3

5. Declarative Approach Defining the management behavior of a cloud service focuses on description of the desired results – Via requirements, capabilities – Is dependent on crisply defining semantics of relationship types, lifecycle operations etc E.g. Hosted_On vs Connects_To vs Depends_On Thus, management actions to be performed will be derived automatically! – Orchestrations don't have to be defined explicitly, but the effects otherwise achieved by orchestrations will be achieved implicitly Thus, a declarative approach provides information about what orchestration problem is to be solved This is similar to SQL: You specify WHAT data you need, not HOW to retrieve them (latter is needed for IMS/DB, most OO-DBMS, files,…) 4

6. Imperative Approach Defining the management behavior of a cloud service requires specifying each of the steps to be performed in an orchestration as well as the order in which these steps must take place (the plans) Thus, you must explicitly specify how particular orchestration problems (even provisioning or decommissioning) are solved – In contrast to specifying what you want as in the declarative approach – The use of process languages comes with the advantages of graphical modeling tools for orchestrations, advanced features of robustness, parallelism etc. – Note, that using a process language (in contrast to the use of scripting languages, for example) is not the characterizing aspect of an imperative approach but the explicit specification of orchestration is This is similar to IMS/DB, e.g.: You must specify HOW to navigate through hierarchical data structures, HOW to cut out which data,... 5

7. N1N1 N2N2 N3N3 N4N4 N5N5 N6N6 R R T4T4 T4T4 T5T5 T5T5 T6T6 T6T6 TRTR TRTR T2T2 T2T2 + T3T3 T3T3 T1T1 T1T1 + T O Derive From Declarative Approach: There is No Miracle Certain management actions can be automatically derived from the topology – E.g. plans can be generated, or a generic topology interpreter dynamically derives management action, or... – Again, this requires precisely defined semantics of types and interfaces

8. Declarative - Imperative +Simplicity +No requirement for additional middleware ¬Restricted support of management behavior ¬Only straightforward orchestration features ¬Hard to support complex topologies ¬Precise definition of semantics required +Support of any management behavior +Advanced orchestration features ¬Additional skills required ¬Additional middleware required ¬Increased maintenance effort 7

9. In Practice......a combination of both approaches is likely Use declarative approach for straightforward management actions like initial deployment, decommissioning Use imparative approach for more complex actions like selective patches, version upgrades, user/license management,... 8

10. The Key Problem Behind the API A step in a plan invokes the operation of a node template This operation has some effects on the real world – E.g. allocation of a set of IP Addresses These effects must be known at a later point in time, e.g. within other plans run at a later point in time How can a plan get aware of the effects achieve by former plans that invoked node type operations? T N op effects invokes 9

11. Solution: First Attempt The operation invoked (to be more precise: the corresponding implementation artifact) gathers all the data it needs to know from proprietary interfaces within the proprietary environment T N op effects invokes Implementation Artifact Implementation Artifact ? ? ? ? 10

12. Suitability of This Solution This solution results in highly complex implementation artifacts! Implementing an operation becomes tightly coupled with a particular environment and the proprietary interfaces offered there Often, an operation requires data about effects produced by several other operations before, i.e. the retrieval of this data becomes significantly complex To simplify the development of implementation artifacts, such logic should be separated (i.e. split out) 11

13. Solution: Second Attempt Build a plan in such a way that the data required by a node type operation invoked by a task is retrieved by a separate task (pre-Task) This pre-Task knows where to retrieve the data within a particular environment – E.g. from a local CMDB T pre- T N op effects invokes ? ? 12

14. Suitability of This Solution This solution results in non-portable plans! – The pre-Task accesses proprietary interfaces to retrieve data about former effects of plans Thus, operational behavior of Cloud Applications is not achieved: A conflict with TOSCA goals! 13

15. Solution: Third Attempt A standardized API (a Plan Portability API) is made available that allows to retrieve effects of former operations The pre-Task is bound to proper functions of this API Tpre-T N op effects invokes Plan Portability API State of Instances of service templates 14

16. Suitability of This Solution The tasks within a plan are no longer dependent on proprietary interfaces to access information of effects of operations Remaining Problem: How is the information about effects achieved made available to the API? 15

17. Complete Solution The effects achieved by an operation are often reflected by the return data of the operation Thus, this return data is passed to a post-Task of the task bound to the operation, and this post-Task uses the Plan Portability API to store this data From then on, the effects achieved by an operation is available in the environment in a portable manner! Tpre-T post- T N op effects invokes Plan Portability API State of Instances of service templates 16

18. Summary The (Plan) Portability API is not an API providing functions of the container itself – Thus, it seems to be in scope in compliance with the TOSCA charter Without the (Plan) Portability API portability of operational behavior of Cloud Applications is not given – Thus, we will miss the goals set in the TOSCA Charter! The (Plan) Portability API is a necessary and integral aspect of TOSCA 17