Why Do We Need a (Plan) Portability API?

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

2. TOSCA‘s 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. “

3. What is Out of Scope • The charter says explicitly what‘s 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

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).

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_OnvsConnects_TovsDepends_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,…)

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,...

7. Declarative Approach:There is No Miracle  T • 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 Derive From N1 O TR T4 N2 N3 + T5 T2 + T1 R‘ R T6 T3 N4 N5 N6

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

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,...

10. The Key Problem Behind the API op effects N • 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? invokes T

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 ? Implementation Artifact ? ? ? op effects N invokes T

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)

13. Solution: Second Attempt op effects N • 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 invokes pre-T T ?

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!

15. Solution: Third Attempt op effects N • 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 invokes pre-T T Plan Portability API State of Instancesof service templates

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?

17. Complete Solution op effects N • 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! invokes pre-T T post-T Plan Portability API State of Instancesof service templates

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